Web 2.0 Under Siege 170
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'"
Re:XSS (Score:5, Informative)
Daniel
Re:XSS (Score:3, Informative)
Duh (Score:3, Informative)
Re:Okay, I'll be the first to ask. (Score:5, Informative)
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
D
Re:Okay, I'll be the first to ask. (Score:2, Informative)
Such an attack previously succeeded on Digg (in the form of a white-hat demonstration of a self-Digging website), but that vulnerability has already been patched. The description of the demo attack, which they also refer to as "session riding," is available here: http://4diggers.blogspot.com/ [blogspot.com]
Re:XSS (Score:2, Informative)
--Anonymous Coward
Re:Okay, I'll be the first to ask. (Score:5, Informative)
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.
They discovered this? (Score:1, Informative)
All AJAX applications transfer data between the webpage in the client's browser and the server. If the data is in XML, the webpage and the XML have to come from the same server. If it's JSON (JavaScript Object Notation), then they do not have to come from the same server. So, if you are sending data that depends on some kind of authentication - don't use JSON.
The JSON vulnerability comes from having your session open too long. Someone navigates to a bad site and it access the active session on the target site. Shorter session timeouts help with this. You can also do some authentication in the XML request as well. And don't use JSON for data that requires authentication.
In short, if you're using AJAX for data that requires authentication, then you need to take some simple precautions.
Re:Where's the problem? (Score:4, Informative)
AJAX really do need sessions. Just think of Gmail. It it a single AJAX session starting when you login, and finishing when you logout or timeout.
If AJAX don't use sessions, it would have to authenticate itself with username and password with each request it made to the server.
An better solution might be to let the AJAX application explicit handle sessions by storing the session id, and sending it in the post part of all it's requests. But that might be a problem with the browsers history, because it would then loose your session id, if you used the back button.
Re:XSS (Score:5, Informative)
Daniel
Re:Where's the problem? (Score:2, Informative)
Store then in javascript? Huh?
It is completely normal -- across the entire industry -- to store session identifiers in cookies. There is nothing special or AJAXy about that.
Re:We've already seen this before (Score:5, Informative)
http://getahead.org/blog/joe/2007/01/01/csrf_atta
Of course, DWR 2.0 will have all this goodness built in.
Detailed report on this problem (no reg required) (Score:3, Informative)
Re:Enough (Score:3, Informative)
vulnerable == cookie && json && !p (Score:3, Informative)
- It uses cookies to store session IDs or other forms of credentials; and
- It sends data from server to browser using "JSON" notation; and
- It doesn't require POST data in each request.
A vulnerable application can be fixed by changing any of these three aspects:
- Stop using cookies, and instead supply the credentials in the request's URL or POST data.
- Don't use JSON, or munge your JSON so that it can't be run directly from within a <script> tag; for example, you could put comments around it in the server and strip them off in your client.
- Have the client send some POST data and check for it on the server (a <script> tag can't send POST data).
My preference, and the strategy that I've used in Anyterm and Decimail Webmail, is to not use cookies. To me it actually seems easier to put the session ID in the request, rather than to mess around with cookies.
The advisory, which explains it all but is a bit waffly at the start, is at http://www.fortifysoftware.com/servlet/downloads/
Re:They discovered this? (Score:1, Informative)
XML is so last week. What's really wrong. (Score:5, Informative)
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" [json.org]. 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. [getahead.org] (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.
Re:Okay, I'll be the first to ask. (Score:5, Informative)
No, that's the vulnerability. This allows other domains to get the data when the applications don't want to share it.
The news here is that the "additional precautions" that most Ajax libraries take are ineffective.
Re:Okay, I'll be the first to ask. (Score:3, Informative)
You're right, they're right. It's from March 12th, 2007 and it's a different issue than the one I mentioned before.
Putting the JSON data into comment tags or Google's while() approach sound like good defense mechanisms.
Also, using auth tokens in addition to cookies can defeat most scenarios as well (just ensure not to return a valid auth token in any replies that don't require a valid auth token already).
Re:Shirky's Law: (Score:3, Informative)
Riiight. Facebook is absolutely secure and immune from security problems [digg.com] and spam [wordpress.com] because of their preventative measures.