Slashdot Mirror

The name of the software is Direct Web Remoting

How can we take this seriously if they don't know the name of the software they are evaluating?

Well, Fortify Software Security Research Group (which I am part of) has recently released a report ( http://it.slashdot.org/article.pl?sid=07/04/02/111 3242 ), where we discuss the new type of vulnerability we named JavaScript Hijacking.

We believe that JavaScript Hijacking is the only type of vulnerability found so far applicable only to Ajax applications. We've also analyzed 12 most widely used Ajax frameworks (DWR, GWT, Microsoft "Atlas", xajax, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit) and determined that all the frameworks that use JSON and/or JavaScript for transferring data (except for DWR 2.0 which was not released at the time) are vulnerable to JavaScript Hijacking.

To summarize, the vulnerability allows an unauthorized party to read confidential data contained in JavaScript messages. The attack works by using a tag to circumvent the Same Origin Policy enforced by Web browsers. Traditional Web applications are not vulnerable because they do not use JavaScript as a data transport mechanism.

Complete report is available here: http://www.fortifysoftware.com/servlet/downloads/p ublic/JavaScript_Hijacking.pdf .

As a side note, DWR 2.0 ( http://getahead.org/dwr/ ) and Prototype 1.5.1 ( http://prototypejs.org/2007/5/1/prototype-1-5-1-re leased ) have been recently released, and do contain fixes that prevent JavaScript Hijacking.

This exploit is different from XSS and is not new. It's called CSRF, Cross-Site Request Forgery. Web developers have known about it for several years. It's tricky to understand and potentially very dangerous, but there are remedies.

Because the problem and remedies are somewhat abstruse, casual or uninformed developers don't always take it into consideration. I'm actually a little surprised that the vast majority of commentators here seem to be unaware of it.

References:
http://getahead.org/blog/joe/2007/01/01/csrf_attac ks_or_how_to_avoid_exposing_your_gmail_contacts.ht ml
http://en.wikipedia.org/wiki/Cross-site_request_fo rgery
http://www.tux.org/~peterw/csrf.txt (from 2001!)

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.

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. :)

Try DWR. We use it in all sorts of places and it works beautifully (logged in now).

Try DWR. We use it in all sorts of places and it works beautifully.