W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [XHR][XHR2] Same-origin policy protection

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 15 Jun 2011 10:15:53 -0700
Message-Id: <A1AEF35E-52C4-435E-90DC-6BF573C39AE7@jumis.com>
Cc: David Bruant <david.bruant@labri.fr>, "public-webapps@w3.org" <public-webapps@w3.org>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
There have been a few requests for an XHR which does not expose session data to the target. I believe IE9 has an interface for this; I know it's been requested on chromium bug list.



On Jun 15, 2011, at 9:18 AM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

> On 6/15/11 6:43 AM, David Bruant wrote:
>> Could someone explain how running in a web browser justify such a
>> difference? For instance, could someone explain a threat particular to
>> cross-origin XHR in web browser?
> 
> Off the top of my head:
> 
> 1)  XHR in the web browser sends the user's cookies, HTTP auth credentials, etc. with the request.  Which means that if you're logged in to some site A, and cross-site XHR to that site is allowed from some other other site B, then B can access all the information you can access due to being logged in to site A.
> 
> 2)  XHR in the web browser gives (at the moment, at least) sites that are outside a firewall that your browser is behind the ability to make requests to hosts that are behind the firewall.
> 
> Item 2 is somewhat of an issue for installed apps as well, of course, but installing an app is a trust decision.  I would imagine browsers could relax some of these restrictions if a similar trust decision is explicitly made for a non-locally-hosted app.
> 
> Item 1 is pretty specific to a web browser; the only way to avoid that issue is to run the app's XHRs in a special mode (effectively treating it as not running in the browser at all).
> 
> -Boris
> 
Received on Wednesday, 15 June 2011 17:16:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT