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.