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

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.
>>
>> 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:40:27 UTC