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.