Thursday, April 24, 2008 At 1:53PM
I was recently asked by a client for some technical countermeasures to consider as they prepare to build an Ajax enabled web application (aside from the more fundamental countermeasures like rigid output encoding and request tokenization to defend against XSS and XSRF respectively). What follows are a few suggestions I provided for implementing “defense in depth” within their Ajax enabled (Web 2.0) application.
Specify the Appropriate Content-Type Response Header
By default, most HTTP responses generated by a web component include a “Content-Type” header value of “text/html” or “text/plain”. These responses are treated by a web browser as HTML and get loaded in the browser DOM.
When rendering responses for Ajax requests, non-HTML content (like XML or JSON) is typically returned, so it is important to specify the correct “Content-Type” HTTP response header. For example, XML messages returned by Ajax calls should have a “Content-Type: text/xml” header. These responses will not be loaded into the browser DOM (based on their content-type), which can potentially thwart XSS attacks in the absence of other controls like proper output encoding.
Require POST Method for Ajax Calls Returning User Data
Any data rendered by an Ajax GET request is potentially susceptible to JavaScript Hijacking if there are no controls specifically designed to thwart the attack (such as an XSRF token).
JavaScript Hijacking attacks rely on use of the <SCRIPT> tag “SRC” attribute, which is unable to make POST requests. As such, accepting only POST requests for Ajax calls that return user (or otherwise sensitive) data is generally a good idea.
Check Content-Type on POST Requests
The browser “same origin” security policy is a key mechanism used to thwart malicious use of the XMLHttpRequest (XHR) object at the browser level. Standard HTML forms are not restricted by the same origin policy, so verifying that Ajax requests are made using the XHR object and not an HTML form can potentially buy some added safety.
Consider the following HTML form, which can be used to forge a JSON post (a similar technique can be used to forge XML requests):
<FORM TARGET="/ajax/dispatcher" METHOD="POST">
<INPUT TYPE="hidden" NAME='{"action": "sendEmail", "recipient": "[email protected]", "messageText": "Hi George! ' VALUE=')"}'>
</FORM>
The results of the above form POST are shown below. As you can see, to the server the request will look like a valid JSON request (which is typically assumed to have been made using the XHR).
{"action": "sendEmail", "recipient": "[email protected]", "messageText": "Hi George! =)"}
By default, POST requests made using the XHR browser object will have a Content-Type header of “application/xml”. A standard HTML form submission will typically have a Content-Type header of “application/x-www-form-urlencoded” or “multipart/form-data”, so checking this value (server-side) can be one way to help ensure the request was not issued via a rogue 3rd party HTML form.
Host 3rd Party Content in a Separate IFrame
When serving up 3rd party content, the developer should anticipate the possibility of embedded malicious script code.
Consider a typical RSS feed. The importance of HTML encoding RSS data elements when being rendered in the page is generally well understood; however certain elements (such as the <link> element) can pose additional challenges.
Normally the <link> RSS element is rendered within the “href” attribute value of an HTML “A” tag. Depending on how the data is encoded, XSS is often still possible since an exploit string such as “javascript:alert(‘XSS’)” will be unaffected by most native HTML encoding mechanism (like the built-in Server.HtmlEncode method in ASP.NET).
In addition to stringent encoding techniques, a good secondary defense-in-depth policy to prevent these attacks is to render all 3rd party content (i.e RSS, JavaScript widgets, etc) in a separate IFrame. Serving un-trusted content within a separate IFrame will not prevent a malicious script from executing, but it will prevent the malicious script from accessing application data via the DOM since the IFrame will have its own DOM context.
This is by no means intended to be a complete list of defensive Web 2.0 suggestions, so feel free to comment with additional thoughts.
Author: Brian Holyfield
©Aon plc 2023
