Machine Learning Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Zakia Bouachraoui

Related Topics: Machine Learning , Cloud Security

Machine Learning : Article

Application Security in AJAX

Mind the Gap

If you have evaluated AJAX (Asynchronous JavaScript and XML) for your next Web application development project, then you probably have read or heard a great deal about AJAX security concerns and the claim that AJAX increases the attack surface for hackers. If you are a skilled security developer, you might wonder whether the AJAX security problem originates in the technologies involved or whether lack of security in AJAX is a misconception. Security threats like SQL injection, cross-site scripting (XSS), message spoofing, and failed input validation existed before in Web applications and have been solved many times since then.

At first glance, it seems that the AJAX security discussion is a retelling of the tale of the emperor's new clothes. At second glance, however, it is obvious that there is a new component in AJAX security - the rich and interactive client. If this smart client really introduces a new security threat to Web applications, then the following questions arise: What can be done today, and what needs to be done in the future, to avoid ÒkillerÓ applications built with AJAX?

The Security Dilemma
Technology alone seldom is the problem. Lack of security in an application arises because of what developers do with the underlying technologies. To build secure Web applications - and this hasn't changed since traditional Web applications - there are two aspects of equal importance to be considered: humans and technology.

The most prevalent philosophy in application security is that security should not be added as an after thought, but should be included by design and default. The latter, however, never seems to happen in this feature-driven Internet technology industry, where new technologies are continuously being born. Two schools of thought exist in security: those who know everything and those who know next to nothing. It appears that because those who know everything are accustomed to handling the shortcomings of a given technology themselves, by devising workarounds or by using third-party security frameworks, it is up to those who know next to nothing to standardize security, making it a reachable goal for everyone.

AJAX is another example of putting security last and features first. AJAX is not a new technology. Instead, it consists of existing technologies such as JavaScript, Cascading Style Sheets (CSS), and Extensible Markup Language (XML) to implement Web 2.0 user interfaces. The technology used for dynamics in AJAX Web-user interfaces is JavaScript. This means, however, that the available Java security features, like the JavaScript sandbox and the same origin policy, are the main security features available in AJAX.

•  Same Origin Policy: The same origin policy prevents scripts that are downloaded from a Website to access properties on a page that is downloaded from another Website. The security of the same origin policy, which ensures that malicious scripts do not hijack other loaded documents or spy on user cookies or key inputs, conflicts with another Web 2.0 wanted functionality: mashup. A mashup is an application page that consumes mixed services to build a composite Web-user interface. This type of application may need to interoperate between page fragments, even if it is downloaded from different servers and domains. Within the AJAX community and the World Wide Web Consortium (W3C), a desire exists to loosen the same origin policy limitation for XMLHttpRequest object (XHR) requests, which, from a security perspective, would require trusted clients that do not exist today.
•  JavaScript Sandbox: JavaScript is contained in the browser execution environment and is not allowed to access either the client file system or the network, except through Hypertext Transfer Protocol (HTTP) requests. All that JavaScript has access to is the memory representation of the displayed browser document, called the document object model (DOM).

In JavaScript, little can be hidden from would-be hackers because all facets within a page are accessible and modifiable in the DOM tree. Exposing JavaScript source on the client, where it can be read or stolen, is not a security problem. If it were, open source software, which does not hide its implementation from viewers, would pose a huge security threat.

Client-side sources are problematic because everything is accessible in the DOM, which means that nothing can be protected on the client. Any security policy that is downloaded and enforced on the client can be read and manipulated. Obscurity is not a substitute for security. In fact, obfuscated JavaScript only helps to lock out wannabe hackers and is otherwise primarily used to increase JavaScript performance through reduced content lengths.

Where AJAX Fits in an MVC Architecture
Modern Web applications that implement the model view controller (MVC) pattern demand a separation of the application presentation from its life cycle and model. AJAX is a presentation layer technology that is used to render interactive Web-user interfaces in rich Internet applications (RIA). As an application developer, you don't write end-to-end business applications in AJAX. Instead, you use a server-side technology to handle the business logic. One of the niceties of AJAX is that it is independent of the server technology business layer. Therefore, AJAX works the same with Java, C, Perl, PLSQL, and .NET back ends. This clean separation between the presentation and business layers is a choice that every application developer should consider. Security should be implemented end-to-end, which means that all parts of the application should follow the same policy and share the same user security context. This also includes database security if databases are involved.

Security in AJAX
Unlike traditional Web applications that have a more or less static user interface, AJAX applications have an active client that uses the browser's native XHR to fetch data from a server. There are two major risks to the browser regarding client-side JavaScript: browser bombing and cross-site scripting attacks:
•  Browser bombing is the client version of a denial of service (DoS) attack. During this type of attack, the client is kept busy with JavaScript processing, such as running endless loops that fill up an array with content. When the client consumes all computing resources, the desktop hangs.
•  Cross-site scripting has two facets. The first one, which was already mentioned, is where a script downloaded from one domain tries to access properties of a page downloaded from another domain. The second facet is where developers fail to validate user input, resulting in a JavaScript that is executed when the user-added input is rendered on a Web page. Imagine a discussion forum that does not encode JavaScript content or check for SQL keywords. A hacker could, for instance, add JavaScript that performs a runtime attachment of an image tag to the page in which the src attribute references a uniform resource locator (URL) on the hacker's server. The script could, for example, append the client's cookies as a request parameter. The application user does not recognize these changes because the HTML does not flag a missing image as an error.

While client-side security protects the end user from the application, application security protects the application from the user. Protection includes enforcement of authentication, authorization, and data privacy.

Though XSS and SQL injection attacks can be handled in AJAX on the client, you should not miss the opportunity to enforce the same policy on the back end in an additional layer of defense. In traditional Web applications, request filters implemented on the HTTP server (or in the application configuration) performed pattern searches using such things as Regular Expressions on the incoming request to detect technology keywords of JavaScript and SQL. In addition, filters were used to replace special characters with their encoded equivalent, such as when replacing < with <. AJAX applications are like traditional Web applications, so the same security design patterns apply to them.

Security design patterns are recommendations of best practices to mitigate the risk of an identified threat. Patterns that exist for Web applications include defense in depth, limited view, least privileged access, checkpoint, and roles.

In addition to best security practices, there exists a sensitive balance between usability, performance, and security that needs to be considered when building AJAX applications. It is easy to risk vulnerabilities simply by annoying end users with too many security-related interruptions when they are working in an application. Such users soon turn into hackers on their mission to find a more convenient way to work with an application. AJAX applications are based on client-side JavaScript and only provide a minimum capability to maintain client-state in cookies and page variables. Unless the AJAX application is built on top of a server-side framework that manages the application state, AJAX applications risk losing state upon page reload and navigation, adding a need to re-request user security credentials.

More Stories By Frank Nimphius

Frank Nimphius is a principal product manager for application development tools at Oracle Corporation. As a conference speaker, Frank represents the Oracle J2EE development team at J2EE conferences world wide, including various Oracle user groups and the Oracle Open World conference.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
navot 10/08/07 04:14:59 AM EDT

I would like to draw your attention to another alternative which is a paradigm shift for AJAX front ends. One should be aware that I am not, and do not pretend to be objective, never the less I believe that one can judge for himself. Visual WebGui is an AJAX frame work that doesn’t expose logic, data or open services on client requests and therefore is not as vulnerable as common AJAX solution. Worth a look at www.visualwebgui.com.

CloudEXPO Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by sharing information within the building and with outside city infrastructure via real time shared cloud capabilities.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.