Web 2.0 Under Siege

Robert writes "Security researchers have found what they say is an entirely new kind of web-based attack, and it only targets the Ajax applications so beloved of the 'Web 2.0' movement. Fortify Software, which said it discovered the new class of vulnerability and has named it 'JavaScript hijacking', said that almost all the major Ajax toolkits have been found vulnerable. 'JavaScript Hijacking allows an unauthorized attacker to read sensitive data from a vulnerable application using a technique similar to the one commonly used to create mashups'"

Comments

Okay, I'll be the first to ask.

[Z0mb1eman]

How is this different from cross-site scripting?

"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."

Re:Okay, I'll be the first to ask.

[daviddennis]

This is much harder to protect against than normal XSS. Why? Because the Ajax does not have to be executed from within the same domain.

Let's say someone wants to attack my site, amazing.com. I browse to their site, remarkable.com, and the exploit code gets loaded into my browser. Remarkable.com can post to amazing.com using AJAX and receive replies as though they were authenticated on my site, because the browser automatically sends the amazing.com cookies with it when accessing an amazing.com URL. It appears to the browser fundamentally as though I was in remarkable.com and then typed the amazing.com URL on to the address bar.

(Of course you could spoof the referer but not from an existing browser session so I think the referer can be relied on in this context.)

If this is so, then it could truly be a throbbing migraine to fix - you would have to use the HTTP referer field to verify that the site calling your Ajax code was valid.

Hope that helps. Not the cheeriest news this morning :-(, but hopefully Prototype will have some kind of fix, and life will go on.

D

Re:Okay, I'll be the first to ask.

[Bogtha]

No, that kind of thing has always been possible since the very first implementation of JavaScript. If you don't need POST, then you can even do it with plain HTML 2.0, no JavaScript.

The problem here is that JSON is a subset of JavaScript and so it is automatically parsed under the local domain's security context when it's included in a document with <script>. There's a few tricks to "hide" it even though it's already been parsed and is sitting in memory, I assume these guys have found a way around that.

Re:Okay, I'll be the first to ask.

[Bogtha]

this only affects AJAX APIs / apps that are designed to be called from other domains.

No, that's the vulnerability. This allows other domains to get the data when the applications don't want to share it.

Bottom line: Don't expose any data / functionality through an API that allows cross-domain XHR unless you add additional precautions.

The news here is that the "additional precautions" that most Ajax libraries take are ineffective.

Re:XSS

[KDan]

I think the very subtle difference is that this time the calls are made using site A's public Ajax API, using site A's authentication token, but are made from a script sitting on site B. The javascript calls return with data from site A, which can then be handled by site B. XSS/JS Injection is more about injecting alien javascript onto site A to make site A call site B with the info it wants.

Daniel

quick!

[mastershake_phd]

Upgrade to Web 3.0, quick!

Mashups?

[Rob T Firefly]

'JavaScript Hijacking allows an unauthorized attacker to read sensitive data from a vulnerable application using a technique similar to the one commonly used to create mashups'

So back when I made the Beastie Boys rap over the Macarena tune, I was really hacking the Web 2.0? And here I thought I was just assaulting eardrums and good taste...

Where's the problem?

[pimterry]

"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."

So essentially it means that the attacker can use the authentication cookie of the user to authenticate them again, and then run javascript with that authentication. But why are AJAX apps storing authentication in cookies? If you need to store authentication (User session id's etc), store them in a variable within the javascript. That'll stay there until a page refresh clears variable status, and how many page refreshes occur with AJAX?

AJAX apps do not need to (and should not!) store user authentication in cookies. Cookies are useful for keeping a continual session open between pages. AJAX needs no continual session. If they don't use cookies, then other sites cannot use that authentication.

Where's the problem? (What am i missing?)

PimTerry

Shirky's Law:

[sakusha]

"Social Software is stuff that gets spammed."

The obvious implication of Shirky's Law is that Web 2.0 services are an attractive nuisance and give spammers and other griefers an incentive to game the system. Any new web service has to account for this and build in extremely high levels of security. Obviously nobody is doing this.

We've already seen this before

[slashkitty]

It was reported as a problem with the google address book. These guys just generalized the problem because they saw it in many places.

It actually could be pretty nasty. I think the only solution is for you to pass authenticated tokens through the url or input parameters (not through cookies).

It might be a good time to use the firefox NoScript plugin if you're not using it already. Only allow javascript on sites you trust.

Re:We've already seen this before

[aron_wallaker]

There are ways to deal with this. Joe Walker, author of Direct Web Remoting (DWR), talks about the GMail problem and ways to solve it:

http://getahead.org/blog/joe/2007/01/01/csrf_attac ks_or_how_to_avoid_exposing_your_gmail_contacts.ht ml

Of course, DWR 2.0 will have all this goodness built in. :)

Re:XSS

[KDan]

Sorry, I was writing this in a rush. I meant site A executes the code that was injected, retrieves the resulting data from site A, and then sends that data over to site B (or some other location). Typically this "data" is stuff like login information...

Daniel

The Biggest WTF...

[Sam Legend]

The biggest WTF is that somebody is still using javascript. Oops. Wrong site...
(Captcha: backtotheweb1.0)

sigh

[CrazyBrett]

This just sounds like a fancy Cross-Site Request Forgery.

I still maintain that the collective blindness to these security issues comes from our absolute refusal to see HTTP requests as function calls. This is partly due to the silly ideology of the REST crowd.

Rephrase the situation as follows and see if this doesn't make you pee your pants: "Any site can instruct your browser to execute an arbitrary function on another site using your authentication credentials."

XML is so last week. What's really wrong.

[Animats]

XML is now so last week. Really l33t web apps use JSON, which is yet another way to write S-expressions like those of LISP, but now in Javascript brackets.

There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb. Some JSON support code "filters" the incoming data before the EVAL, but the most popular implementation missed filtering something and left a hole. Second, there's an attack similar to the ones involving redefining XMLHttpRequest: redefining the Array constructor. (Caution, page contains proof of concept exploit.)

The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable. It's not clear how to allow "mashups" and prevent this. The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.

As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.