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
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 (
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
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.
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
These are my thoughts so far. I welcome your comments.