By Peter Bell

Javascript Highjacking Risk for AJAX Apps?

Posted At : April 2, 2007 3:34 PM | Posted By : Peter Bell
Related Categories: AJAX

I *still* haven't had a moment to fire up JQuery, but this looks like something to check with the AJAX framework guys to confirm if it is an issue and when a patch might be released for your framework of choice . . .

I didn't find the sample attack scenario to be sufficiently detailed to get my head around the actual level of concern this should evoke. Perhaps someone who's played with JS a little more than me might like to comment?

Comments (9) | Print | del.icio.us | Linking Blogs

Comments

[Add Comment]

I guess the point is that with many of the frameworks they don't necessarily check the data in / out after you have logged in and have cookies set. So lets say I visit my ajax powered bank site (which doens't exist, but for example) and log in and get some info etc. Then I go to another naughty site. If my session hasn't timed out with my bank site and the naughty site I am at knows that the bank site is open to the vulnerability it may try to connect to the bank site through ajax type calls using my cookied info and check to see if my session is alive. If so it may be able to get to some data. The naughty site probably has a script that just tries to connect to a variety of known vulnerable sites hoping that one of them hits.

I haven't delved any deeper, but slashdot users were saying it was an issue with JSON and storing the authentication keys in cookies only (not in the json data as well I guess). Of course I could be all wrong on this. Just started looking into it.

# Posted By Joshua Cyr | 4/2/07 5:07 PM

I thought this paragraph summed up what I was thinking right before I read it:

"In an example attack, a victim who has already authenticated themselves to an Ajax application, and has the login cookie in their browser, is persuaded to visit the attacker's web site. This web site contains JavaScript code that makes calls to the Ajax app. Data received from the app is sent to the attacker."

That said, I don't know how plausible a scenario that is, so it doesn't really answer the question of level of concern...

# Posted By Sammy Larbi | 4/2/07 5:12 PM

Thanks for the clarification guys. Will be interesting to keep an eye on . . .

# Posted By Peter Bell | 4/2/07 5:18 PM

A pretty good explanation has been posted to the jQuery mailing list:
http://groups.google.com/group/jquery-en/msg/fb6ee...

Computer Business Review sure know how to stir the pot... We're going to be hearing about this article and the end of the world for weeks to come now :P

P.S. As linked in that post, the original whitepaper is here:
http://www.fortifysoftware.com/servlet/downloads/p...

# Posted By Justin Carter | 4/3/07 7:23 AM

From what I've gathered, there are basically two ways to ensure this doesn't become an issue:

1) Check for referer. If the page making the Ajax call or requesting the data belongs to your site, then let the request go through.

2) Pass CFID & CFTOKEN via your Ajax requests and validate them on the server side. Since an attacker can't, in theory, duplicate the URLToken key pair this would allow you to validate that its a valid session and pass data back or not.

Overall, I think Fortify is completely blowing this one out of proportion and everything I've read reinforces that conclusion. It is an issue to look into but its not as massive an issue as they're making it out to be. They're spreading FUD.

# Posted By Rey Bango | 4/3/07 7:29 PM

Yeah - that seems to be the consensus. Still, worth knowing about . . .

# Posted By Peter Bell | 4/3/07 7:41 PM

Absolutely. i just hate the fear mongering that some of these "security" companies use to freak everyone out. I've spoken to a couple of really top-level JS guys that have all said that this is being blown way out of proportion. The media is also making things worse.

# Posted By Rey Bango | 4/3/07 10:25 PM

Agreed. Fear sells (was papers - now ad views).

# Posted By Peter Bell | 4/3/07 10:32 PM

BTW, just saw this popup on Ajaxian:

http://ajaxian.com/archives/towards-secure-ajax-ma...

points to:

http://www-128.ibm.com/developerworks/library/x-se...

Very interesting read.

# Posted By Rey Bango | 4/3/07 10:43 PM

[Add Comment]