1016491 - Same Origin Policy not applied by data URIs

Status: RESOLVED DUPLICATE of bug 1324406

(Core :: Security, defect)

Description

[László Jánszky]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

I added a HTML containing an XHR GET to a data URI. The XHR was requesting the same host the data URI was defined on. (More info in here: http://stackoverflow.com/a/23895830/607033 )


Actual results:

The browser displayed the response of the cross origin request performed by the XHR.


Expected results:

It shouldn't have displayed the result because of the same origin policy.

According to the web origin concept scripts from the data URI cannot have the same origin as scripts from the webpage. This is because the data URI scheme is clearly different from the HTTP URI scheme, so something defined in a data URI cannot have the same origin as the website on which the data URI was defined. This is security issue, because data URIs can avoid regular javascript filters.

(By chrome this problem is already solved, and by allowing the null origin it is allowed to access the HTTP host from the data URIs.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

> scripts from the data URI cannot have the same origin as scripts from the webpage

Quoting https://html.spec.whatwg.org/multipage/browsers.html#origin :

  For Document objects
...
    If a Document was generated from a data: URL found in another Document or in a script

    The origin is an alias to the origin specified by the incumbent settings object when
    the navigate algorithm was invoked, or, if no script was involved, of the node
    document of the element that initiated the navigation to that URL.

This is, incidentally, what javascript: and about:blank do as well.

The point is, you shouldn't be loading data: URIs you don't trust as documents, just like you wouldn't thus load javascript: URIs.

> because data URIs can avoid regular javascript filters.

Any filter that doesn't treat data: as equivalent to javascript: is just buggy and has been for well over a decade now.

Comment 2

[László Jánszky]

>    The origin is an alias to the origin specified by the incumbent settings object when
>    the navigate algorithm was invoked, or, if no script was involved, of the node
>    document of the element that initiated the navigation to that URL.

So you say that according to the living HTML standard this is the expected behavior, and so chrome violates the rules of that standard? Is this standard accepted among the browser manufacturers?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> So you say that according to the living HTML standard this is the expected behavior, and
> so chrome violates the rules of that standard?

Yep.

> Is this standard accepted among the browser manufacturers?

Chrome developers object to that part of the standard, as you might have noticed.

Comment 4

[László Jánszky]

Okay, I sent a bug report to them with a link to this report and a short description.

Comment 5

[Daniel Veditz [:dveditz]]

The other browsers didn't budge and the spec was changed, so Firefox fixed this.