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

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

From: David Bruant <david.bruant@labri.fr>
Date: Wed, 15 Jun 2011 22:08:58 +0200
Message-ID: <4DF9115A.806@labri.fr>
To: Adam Barth <w3c@adambarth.com>
CC: Charles Pritchard <chuck@jumis.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
Le 15/06/2011 19:39, Adam Barth a écrit :
> The server still needs to opt-in to allowing the web site to read the
> response or you get into trouble with firewalls.  This functionality
> is already available in every modern browser.
> Adam
> On Wed, Jun 15, 2011 at 10:15 AM, Charles Pritchard <chuck@jumis.com> wrote:
>> 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.
As said by Charles, for this one, an option on the XHR object
(.withCredentials?) could allow cross-origin XHR without credentials and
refuse (throw a SECURITY_ERR) to perform cross-origin XHR if their are
credentials without needing a server-side opt-in.

>>> 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.
However, this point is far more tricky and may not have a solution at
the XHR interface level. That's the kind of answer I was looking for.
You wrote "at the moment, at least". Is there some planned change that
could question this?

Thanks all for your responses,

Received on Wednesday, 15 June 2011 20:10:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:20 UTC