[GPC] Wait, what?

Paulo Coimbra paulo.coimbra at owasp.org
Fri Mar 25 16:44:41 EDT 2011



Please keep me in the loop. I propose we put this new field of research also under the umbrella project generically called Cross-Site Request Forgery Project.



- Paulo



Paulo Coimbra,

 <http://www.owasp.org/index.php/User:Paulo_Coimbra> OWASP Project Manager


From: Jim Manico [mailto:jim.manico at owasp.org] 
Sent: sexta-feira, 25 de Março de 2011 20:26
To: Chris Schmidt
Cc: Frederick Donovan; <owasp-leaders at owasp.org>
Subject: Re: Wait, what?




This is interesting stuff. If you don't mind, drop the contents of this email into an OWASP Wiki page and I'll clean it up.

-Jim Manico


On Mar 25, 2011, at 11:11 AM, "Chris Schmidt" <chris.schmidt at owasp.org> wrote:

I’m going to disagree on this point. The term JSONP is JSON with Padding (or JSON Preprended). So basically what you get is


<script src=http://site.com/do_something_cool?callback=parseResponse>


Now, that call can (and often does) do something then returns a response in JSON format, that is it *prepends* the json response (although, wraps is probably a better description) in a function call that the client specifies In the callback parameter. As you know – just including JSON data between script tags *may* compile and run – but does nobody any good without understanding the context of how it is being used, and that context has no business being mixed in with the data. So your response data may be:

[ { name: ‘joe’, acct_number: ‘12345’ } ] 


But what actually comes back is:



When the script is loaded into the javascript runtime, it will call the function you pass in with the data that is the response payload. Just like a standard Ajax callback, only cross-domain!


Now put this into the context of CSRF. Site A (a.com) uses JSONP to perform some ajaxian stuff due to SOP policy issues. They have something that looks like this


<script type=”text/javascript”>

                function parseResponse(data) {

                                document.getElementById(‘name_div’).innerHTML = data[0].name;

                                XHRFactory.dispatchRequest( acctController, { ‘acct’: data[0].acct_number }, displayAcctDetails );



<script type=”text/javascript” src=http://b.com/service/GetUserDetails.jsonp?callback=parseResponse></script>


Site b (b.com) is controlled by the same people who control Site A – so authentication is shared, and the site is trusted. 


Attacker brings up a page and through some recon and enumeration, discovers that several other services exist on b.com. So he builds a page:


<script type=”text/javascript”>

                Function getAccountData(data) {

                                buildNewScriptElement(‘http://b.com/service/TransferFunds.jsonp?callback=wasSuccess <http://b.com/service/TransferFunds.jsonp?callback=wasSuccess&fromAcct=’> &fromAcct=’ + data[0].acct_number + ‘&toAcct=’ + my_swiss_acct  + ‘amt=1000’ );



                Function wasSuccess(data) {

                                If ( data[0].success )

                                                logDeposit(data[0].depositAmount );



<script type=”text/javascript” src=http://b.com/service/GetUserDetails.jsonp?callback=getAccountData></script>


Attacker then entices users of Site A to check out his page – anticipating that most of them will have an authenticated session on Site A. 


This is tremendously more powerful than a traditional CSRF attack as it allows an attacker to craft complex multi-stage attacks that can be completely transparent to the authenticated user. This is also a great deal more than *just* a script include from a remote site, it is code that is the result of an operation – whether that be a lookup (query) or action (update) or delete operation is not important when defining the risk. 


So, as you can see – I am not claiming that JSONP itself is the problem – however, due to the nature of what you can do with JSONP, if controls are not in place (CSRF, Whitelist validation of callback methods, etc) you can have a very powerful attack surface.


For the record – I would love to be proven wrong on this, so feel free to debate!


As I said, I am writing up a blog post on this in all of my spare time (har har har) which I optimistically claimed could be out last night, but more accurately will likely be a this weekend release. There are other risks here (notice the additional controls) that also are not new, and have been covered before. But really this is something that is only going to get more popular with Mash ups and as more sensitive data and operations exist in that space (you know, that online banking widget you put on your iGoogle page) this will become a greater and greater risk. This risk is at the point where Cross site scripting once was. A few people *really* get the problem and understand the risk, but it is not being shared and touted and taught and screamed from the rooftops.            



From: Frederick Donovan [mailto:fred.donovan at owasp.org] 
Sent: Friday, March 25, 2011 11:32 AM
To: Chris Schmidt
Cc: Jim Manico; owasp-leaders at owasp.org
Subject: Re: Wait, what?


JSONP itself does nothing malicious or pose a "security flaw" as the blogger mentioned in 2005. It's just a mechanism of sharing data across sites. He's misusing the term and it's really about developers putting script tags on a page that link to other sites.
For example, if i were to embed a Google map on my page (for office locations or whatever)  I could use an iframe or perhaps set it up to require a script tag on that page that loads everything it needs to.  So the concern in this scenario is putting a script tag on a page that links to google maps - if a hacker can pwn the Google maps page they can replace the script with something malicious, so that everyone who visits the page is pwned in some way. It's XSS, but only if the other site (Google Maps) is pwned.

The author falsely states that it is a browser flaw. Script tags are not a browser flaw. It's the responsibility of the person developing the page to make sure they are linking to a trusted javascript file. The term "JSONP" should not even be used at all. It's just happens to be a technique of how javascript is used, which is irrelevant to the main issue.

Leo and I addressed this at OWASP Summit 08. I thought we had addressed it on the OWASP site already (but apparently not, Chris). 


On Thu, Mar 24, 2011 at 8:16 PM, Chris Schmidt <chris.schmidt at owasp.org> wrote:

My hope is that someone with a bit more time can take this on :)

Sent from my iPwn

On Mar 24, 2011, at 6:13 PM, Jim Manico <jim.manico at owasp.org> wrote:

> Dude: Go to the wiki, make a new page, hit edit and start writing about it! :)
> - Jim
>> That's kind of my point - this isn't exactly *new*, yet OWASP has nothing
>> about the attack, how to solve, or the impacts of the attack
>> -----Original Message-----
>> From: Jim Manico [mailto:jim.manico at owasp.org]
>> Sent: Thursday, March 24, 2011 6:00 PM
>> To: Chris Schmidt
>> Cc: owasp-leaders at owasp.org
>> Subject: Re: Wait, what?
>> Folks have been talking about this since 2005.
>> http://blog.unclehulka.com/2005/12/12/jsonpyoure-joking-right/
>> http://www.google.com/search?q=JSONP
>> - Jim
>>> Looking for references for a vulnerability in an application using
>>> JSONP without any CSRF Protection, I naturally came to the owasp.org
>>> site first - would you believe there is absolutely *nothing* on the
>>> OWASP site about this???
>>> I couldn't believe it, this is a very impactful classification of
>>> attack that makes CSRF 10x more dangerous than it would normally be. I
>>> plan on blogging about the dangers of this scenario and will shoot out
>>> a link as soon as it is up (tonite more than likely) - but I really
>>> think that if anyone else out there has some time and bandwidth to
>>> write up some owasp.org material on the subject, it would be a great
>>> addition to the site and something that could use some attention.
>>> If you have no clue what I am talking about, or generally think I am
>>> full of crap about the seriousness of the attack - I recommend you
>>> watch for my link.
>>> Thanks J


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/global-projects-committee/attachments/20110325/fa0bcba3/attachment-0001.html 

More information about the Global-projects-committee mailing list