If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Bypassing SOP via incorrect MIME type in "data:"




4 years ago
7 days ago


(Reporter: Firstov Mikhail, Unassigned, NeedInfo)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-backlog])


(1 attachment)



4 years ago
Created attachment 794248 [details]
Video with demonstration of this bug

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36

Steps to reproduce:

We have test html page on some host with this html:


<iframe src="data:sometext, <h1>Frame<script>alert(top.document.cookie);</script>">

Actual results:

We have access to page inside the frame, so we can execute js for stealing cookies, for example.

Expected results:

Browser should automatically download file with our incorrect MIME type.
There's really no SOP bypass because all you have to do is change that to "data:text/html," and you can legitimately access the contents.

We may be mishandling the data: protocol for unknown mime types, will have to check the spec on that. It's possible it's correct to fall-back to assuming text/html, though I would have expected text/plain.
Component: Untriaged → Networking
Product: Firefox → Core
From a quick test, if the same data: URL is used in FF's address bar, it runs there as it was text/html... we do see a JS dialog.

In Chrome, the iframe does not execute JS, and if I try the same data: URL in their address bar, the browser downloads it, as would be expected with something that had an unknown MIME type.
The "scary" and unexpected bit here is that Firefox treats data: content as coming from the same origin as that which served it. There's HTML spec support for this position, but we're the only browser that does that. It's an issue for other bugs, but that would be the "security" angle here so I'm going to unhide this bug.

This bug is about the fact that we treat data: URLs with unknown content types as text/html, whereas Chrome appears to treat them as application/octet-stream (i.e. unknown). What does the spec say? I could believe text/plain but text/html seems a dangerous default.
Group: core-security
Nothing actually defines the processing model for data: very well.  A missing content-type is specified to be text/plain, but nothing defines what happens if what you have is not even a content-type at all.

It looks like the data: protocol handler gets the string "sometext" and then tries to SetContentType with it.  SetContentType will be a no-op if the string is missing a '/', among other things, and the default type for an nsBaseChannel is UNKNOWN_CONTENT_TYPE.  That then kicks us into the content sniffer, and there we are.

I think the data channel should check for mContentType being unknown after the set, and if so replace it with application/octet-stream.

Jason, thoughts?
Flags: needinfo?(jduell.mcbugs)
Ever confirmed: true
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.