(Informal) Thoughts on AJAX and Security

by Nitesh Dhanjani

image


I'll be the first to tell you: AJAX does NOT substantially change the typical web application security audit methodology. However, if you are a developer or a security professional, there are a few issues to consider and watch out for. The following is a list of thoughts I created for my own use, but I'd like to share it with you. Note that it is draft, and a work in progress.

1) Cross Domain XMLHttpRequests: Browser security does not allow you to invoke XMLHttpRequest on a resource outside the current domain. This prevents a rogue web application, or an application vulnerable to XSS/JavaScript injection, from making a user's browser invoke XMLHttpRequests to an application outside the current domain.

A rogue application, or an application vulnerable to script injection on the same domain (vulnerable.example.com) may cause users visiting that website to invoke XMLHttpRequests to another application on the same domain (www.example.com).

Case study: Myspace worm. However, these attacks are NOT new to AJAX. It has always been possible to request resources outside the current domain via a simple <IMG SRC="http://example.com/cgi-bin/ouch.cgi?a=b">, and JavaScript code for a while now.

2) Developer Mind-set: One of the main advantages of implementing AJAX is to let the browser do as much work as possible, without enforcing a complete round-trip (re-rendering the entire page.) Unfortunately, many developers take this mentality a bit too far and design their applications such that the browser is trusted to perform input validation, output encoding, and access control checks. This gives rise to attacks we have already seen in the past: SQL injection (input validation), Cross-Site Scripting (output encoding), and improper access control. That said, AJAX in itself does not introduce these vulnerabilities – poorly web applications have been susceptible to these problems long before AJAX.

3) JavaScript Obfuscation: Commercial application vendors regard their source code as their intellectual property, and are likely to want to obfuscate client side code to protect it. AJAX implementations introduce a large amount of client side code so we are likely see a lot of commercial applications implement JavaScript obfuscation. This may be an understandable approach from a legal perspective, but it breaks apart when the intention is to obfuscate security controls. I have come across instances where JavaScript code has been obfuscated to protect home-grown crypto algorithms from being deciphered. It is always easy to reverse-engineer such applications – sometimes it is as simple as using a web application proxy such as Burp to monitor GET and POST requests.

4) Denial of Service: Yes, it is possible for a rogue or vulnerable application to force a user to launch multiple XMLHttpRequests to a target application, but this has been possible before AJAX. Infact, browser domain restrictions make XMLHttpRequests useless in launching such attacks on other domains. Simple tricks like using <IMG SRC="http://example.com/cgi-bin/ouch.cgi?a=b"> nested within a JavaScript loop can do the trick more effectively. If anything, I predict poorly thought out infrastructure and application design is likely to cause AJAX applications to inadvertently DOS themselves due to too frequent XMLHttpRequests.

These are my thoughts so far. I welcome your comments.