Agenda

• 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();
xhr.open("GET", AJAX_call?foo-bar, true);
xhr.onreadystatechange = processResponse;
xhr.send(null);
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