Re: XHR: definition of same-origin

On Aug 29, 2007, at 2:20 AM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>> It would work to specify the rules without specifying how to  
>> determine
>> the origin URI of the XHR completely. However, the rule you mention
>> would not work as is. For instance two textually identical data: URLs
>> should not be considered to constitute a same origin for scripting
>> purposes (though for XHR it doesn't matter).
>
> Could you elaborate on why scripts running in data:X should be denied
> access to data:X? Clearly they already have complete access to every-
> thing in X through parsing their own location's URL and they cannot do
> anything beyond accessing that information if you grant access.

I mentioned that this doesn't affect XHR which only offers read access  
to a new instance of the resource. But having scripting access to an  
existing copy of the resource displayed in another frame or window  
could potentially allow you to do the following things, which should  
be disallowed:

(a) Find out that another frame has a specific exact URL from the fact  
that a different resource with an identical URL can access it. If the  
resource is a template with some variable information filled in, the  
variable information can be determined by brute force guessing.

(b) Modify the other resource; if it is embedded in another page this  
could lead to a phishing attack or similar.

Both of these would depend on the data: URL already having contents  
that could be subverted to access a different frame containing the  
same resource.

The situation would be even worse if you also allow access to data:  
URLs from parent frames with a different URL, as is done for  
about:blank. In this case you could inject script into the data: URL  
frame from the outside, and therefore do attacks (a) or (b) regardless  
of the original contents of the data: URL.

> Per-haps you meant accessing data:X from http:Y should be allowed?

The usual practice is to to disallow access to data:X from anything  
else and vice versa when scripting is involved. Another possibility  
would be to let the origin of data: URL frames be that of the parent  
or opener as with about:blank, but in that case it is necessary to  
prevent navigating frames with parents of a different origin to data:  
URLs, and to prevent a frame from navigating itself to a data: URL if  
it has a parent or opener with a different origin to prevent various  
attack scenarios.

For XHR no such restriction is strictly necessary, but it does make  
things conceptually simpler if the same-origin rule can be the same  
for scripting access to another frame and for XHR access to a resource.

Regards,
Maciej

Received on Wednesday, 29 August 2007 22:23:18 UTC