This presentation was by Lars Ewe, CTO of Cenzic on AJAX applications and trying to explore the different implications of running AJAX in your environment.  My notes are below:


  • What is AJAX?
  • AJAX and Web App Security
  • AJAX and Test Automation
  • Vulnerability Examples: XSS, CSRF, & JavaScript Hijacking
  • AJAX Best Security Practices
  • Demo
  • Q&A

What is AJAX?

  • Asynchronous JavaScript And XML
  • AJAX allows for a new generation of more dynamic, more interactive, faster Web 2.0 applications
  • AJAX leverages existing technologies, such as DHTML, CSS< DOM, JSON, and the (a)synchronous XMLHTTPRequest (XHR)
  • Not just a set of technologies, but a new Web application development approach and methodology
  • XHR allows for (a)synchronous server requests without the need for a full page reload
  • XHR “downstream” payload can be
    • XML, JSON, HTML/JavaScript snippets, plain text, serialized data, basically pretty much anything…
  • Responses often get further processed using JavaScript and result in dynamic web page content changes through DOM modifications

AJAX Code Example

xhr = new XMLHttprequest();"GET", AJAX_call?foo-bar, true);
xhr.onreadystatechange = processResponse;
function processResponse() {
if (xhr.readyState == 4) {
if (request.status == 200) {
response = xhr.responseText;

XHR and the Same Origin Policy

  • Same origin policy is a key browser security mechanism
    • To prevent any cross-domain data leakage, etc
    • With JavaScript it doesn’t allow JavaScript from origin A to access content/data from origin B
    • Origin refers to the domain name, port, and protocol
  • In the case of XHR, the same origin policy does not allow for any cross-domain XHR requests
    • Developers often don’t like this at all!

Common Cross Domain Workarounds

Cross-domain access is often still implemented by various means, such as:

  • Open / Application (server-based) proxies
  • Flash & Java Applets (depending on crossdomain.xml)
    • Ex: FlashXMLHttpRequest by Julien Couvreur
  • RESTful web service with JavaScript callback and JSON response
    • EX: JSONscriptRequest by Jason Levitt

AJAX Frameworks

  • AJAX frameworks are often categorized as either “Client” or “Proxy/Server” framework
  • “Proxy/Server” frameworks sometimes result in unintended method/functionality exposure
  • Beware of any kind of “Debugging mode” (Ex: Direct Web Remoting (DWR) debug=true)
  • Remember: Attackers can easily “fingerprint” AJAX frameworks
  • Beware of JavaScript Hijacking
    • Don’t use HTTP GET for “upstream”
    • Prefix “downstream” JavaScript with “while(1);”

AJAX and Web App Security

  • AJAX potentially increases the attack surface
    • More “hidden” calls mean more potential security holes
  • AJAX developers sometimes pay less attention to security, due to it’s “hidden” nature
    • Basically the old mistake of security by obscurity
  • AJAX developers sometimes tend to rely on client side validation
    • An approach that is just as flawed with or without AJAX
  • Mash-up calls/functionality are often less secure by design
    • 3rd party APIs (Ex: feeds, blogs, search APIs, etc) are often designed with ease of use, not security in mind
    • Mash-ups often lack clear security boundaries (who validates, who filters, who encodes/decodes, etc)
    • Mash-ups often result in untrusted cross-domain access workarounds
  • AJAX sometimes promotes dynamic code (JavaScript) execution of untrusted response data

AJAX / Web 2.0 and Test Automation

  • Spidering is more complex than just processing ANCHOR HREF’s; various events need to be simulated (Ex: mouseover, keydown, keyup, onclick, onfocus, onblur, etc)
  • Timer events and dynamic DOM changes need to be observed
  • Use of non-standard data formats for both requests and responses make injection and detection hard to automate
  • Page changes after XHR requests can sometimes be delayed
  • In short, you need to have browser like behavior (JavaScript engine, DOM & event management, etc)

Cross-Site Scripting (XSS)

  • AJAX is changing the game a little bit since the script tag may already be there, just need to look for JSON or JavaScript snippets to inject yourself into

Cross-Site Request Forgery (CSRF)

  • Want to send a token for AJAX requests as well

JavaScript Hijacking

  • Attacker code (override Array constructor)
  • Render the JavaScript on the wire useless to anyone who doesn’t have access to the code itself
  • The attacker cannot sanitize the JavaScript since they do not have access to the code

AJAX Best Security Practices

Pretty much all the usual Web app security best practices apply:

  • Analyze and know your security boundaries and attack surfaces
  • Beware of reliance on client-side security measures
  • Assume the worst case scenario for all 3rd party interations
    • 3rd parties can inherently not be trusted!
  • Be extremely careful when circumventing same origin policy
  • Avoid/limit the use of dynamic code/eval()
  • Beware of JavaScript Hijacking
  • Implement anti-CSRF defenses