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
