How Secure is Your AJAX?

If you've been following the news, you no doubtfully have heard about the latest AJAX Vulnerability to be found (Read the eWeek article).  The article, and linked whitepaper by Fortify Software, talk about the vulnerability, but do not in my opinion give a good idea of the threat level or indicate how widespread this vulnerability may be.  Almost like your local evening news teases, the missing details tend to create fear and panic.  While I think a little fear is a good way to make developers more security conscious, I think we can all be more productive when we put emotions to the side, and examine the facts.

Technical Details

The attack is a variant of Cross Site Request Forging, but uses <script> tags instead of the usual <img>.  The script tag is embedded into a malicious page, and the src attribute is set to a url residing outside of the malicious site. 

For example, consider the following tag
<script type="text/javascript" src="http://www.yourbank.com/accountbalance" mce_src="http://www.yourbank.com/accountbalance"></script>

This tag would be embedded into joe hacker's site.  Upon visiting this site, your browser would attempt to load the script from the location above.  Just like in a CSRF attack, this vulnerability hinges upon http GET.  If you're not familiar with the difference between GET and POST, briefly GET places all parameters into the URL, POST does not.

To narrow the scope of affected sites even more, the URL used in the script tag must return a JSON formatted string in order for this attack to work.  Additionally, the vulnerability is stuck in a sandbox where it can only read data in the JSON formatted string - meaning the only thing vulnerable is the JSON string.  If you have sensitive data in this string, it can be 'read' by the hacker.

Are You At Risk?

To do a little risk assessment, ask yourself the following questions - Does a URL exist for my site that returns a JSON formatted string?  If so, does the JSON string returned by this url contain sensitive data?  If you answered yes to both of these, I think you already know.. you're at risk.  And like CSRF, don't be fooled into thinking that you're secure simply because you require the user to login.. the mechanism used for the attack leverages the browser's feature of automatically sending cookies with the request.  If the user has a persistent cookie, the browser will be kind enough to automatically authenticate his request using the cookie.

Protect Yourself

The first lesson here is simple.. use HTTP GET for Dynamic Web Applications with extreme caution.  XSRF and Javascript Hijacking both revolve around HTTP GET.  XSRF requires an application which performs an action based on an HTTP GET.  The RFC for HTTP1.1 actually notes that GET should not be used to perform an action - and rightfully so.  Javascript Hijacking is XSRF evolved - it doesn't leverage a HTTP GET that performs an action, but instead has the ability to read the response of the HTTP GET even though the content is coming from a different site. 

Persistent cookies are user friendly, but are security nightmares.  Because the browser always matches a request with any stored cookies, persistent cookies are extremely dangerous.  By shortening the life of a login, you limit the window of opportunity for a hacker.

If for one reason or another you MUST use GET, and you MUST return a JSON formatted string containing sensitive data, be sure to encode your string or put additional characters in the beginning of the string.  Since the vulnerability can only work if the data returned by the special URL is an actual JSON string, you can protect yourself by encapsulating this string.  Additional characters can easily be removed by your code, and also closes the threat window.

Want To Know More?

If you happen to be in the lower Alabama region next weekend, stop by the Alabama Code Camp.  I'm going to be there speaking on April 14th on ASP.NET Security, with a focus on AJAX. 

* Update:  For those of you using ASP.NET AJAX Extensions, check out Scott Gu's post explaining how ASP.NET already has safeguards in place to protect you.