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)

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



> 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:
> Enjoy,
> Brian

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to