Secure Coding mailing list archives

JavaScript Hijacking


From: stefano.dipaola at wisec.it (Stefano Di Paola)
Date: Mon, 02 Apr 2007 11:11:24 +0200

Brian,

i don't know if you read it but me and Giorgio Fedon presented a paper
named "Subverting Ajax" at 23rd CCC Congress. 
(4th section XSS Prototype Hijacking)
http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf

It described a technique called Prototype Hijacking, which is about
overriding methods and attributes by using contructors and prototyping.
It was described how to override XMLHttprequest object, but it was
stated that it could be applied to every prototype. 

If you didn't read it, please read it and add some reference to your
paper.
If you read it:
- i think we deserve at least reference to our paper.
- even if you covered JSON hijacking, the technique is the same and the
name (Javascript Hijacking) is quite similar.

Regards,

Stefano

I've been getting questions about Ajax/Web 2.0 for a few years now.  Most of
the time the first question is along these lines: "Does Ajax cause any new
security problems?"  Until recently, my answer has been right in line with
the answers I've heard from other corners of the world: "No."

Then I've gone on to explain that Ajax doesn't change the rules of the game,
but it does tilt the playing field.  For example:
  - By splitting your code between a client and a server, you increase
    you opportunity for misplacing input validation logic and access
    control checks.
  - Dynamic testing tools tend to have a harder time with Ajax apps.

Now my story has changed.  We've found a new type of vulnerability that only
affects Ajax-style apps.  We call the attack "JavaScript Hijacking".  It
enables an attacker to read confidential information from vulnerable sites.
The attack works because many Ajax apps have given up on the "x" in Ajax.
Instead of XML, they're using JavaScript as a data transport format.

The problem is that web browsers don't protect JavaScript the same way they
protect HTML, so a malicious web site can peek into some of the JavaScript
returned from a vulnerable Ajax app.  We've looked at a lot of Ajax
frameworks over the past few weeks, including Google's GWT, Microsoft Atlas,
and half a dozen open source frameworks.  Almost all of them make it easy
for developers to write vulnerable code.  Some of them *require* developers
to write vulnerable code.

Our write-up on the problem, along with our proposed solution, is here:
    
http://www.fortify.com/servlet/downloads/public/JavaScript_Hijacking.pdf

Enjoy,
Brian



Current thread: