Last Comment Bug 1016491 - Same Origin Policy not applied by data URIs
: Same Origin Policy not applied by data URIs
Status: UNCONFIRMED
DUPEME
:
Product: Core
Classification: Components
Component: Security (show other bugs)
: 29 Branch
: x86_64 Windows 7
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-27 11:12 PDT by László Jánszky
Modified: 2014-09-27 19:35 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image László Jánszky 2014-05-27 11:12:45 PDT
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 User image Boris Zbarsky [:bz] (still a bit busy) 2014-09-26 20:03:16 PDT
> 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 User image László Jánszky 2014-09-27 06:04:03 PDT
>    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 User image Boris Zbarsky [:bz] (still a bit busy) 2014-09-27 18:48:44 PDT
> 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 User image László Jánszky 2014-09-27 19:35:28 PDT
Okay, I sent a bug report to them with a link to this report and a short description.

Note You need to log in before you can comment on or make changes to this bug.