Blocking of top-level navigation to data URLs seems broken
Categories
(Core :: DOM: Security, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | fixed |
People
(Reporter: annevk, Assigned: sstreich)
References
Details
(Whiteboard: [domsecurity-active])
Attachments
(1 file)
As far as I can tell the intent of bug 1403814 was that you cannot navigate a top-level to a data URL (except if the user entered it), but you can download one (which also uses navigation, but doesn't end up replacing the document and changing the address bar).
However, window.open("data:,Hello"); still works. As does data:text/html,<a href=data:,test>test</a>, but not data:text/html,<a href=data:text/html,test>test</a>.
I have not found a way to exploit this, but this does create a weird situation where with Cross-Origin-Opener-Policy you can create a popup with a different origin and still hold a reference to it.
|
||
Updated•5 years ago
|
|
|
||
Comment 1•5 years ago
|
||
(In reply to Anne (:annevk) from comment #0)
However,
window.open("data:,Hello");still works.
Hey, Anne I just also tested that behavior. Using 'data:,' with no explicit content-type results in a contentType of 'text/plain' which we explicitly allow listed within Bug 1415612.
Any objections? Or what was your reasoning that this should also be blocked? Or do you want all data: URIs to be blocked?
FWIW, currently we allow list all plain text types.
|
Reporter | |
Comment 2•5 years ago
•
|
||
My preference would be to allow downloads, but not allow the creation of documents. I suspect that's how Chrome is handling this, though double checking would be good. Alternatively we could force the effect of Cross-Origin-Opener-Policy on a data URL response perhaps which would at least ensure you cannot have a reference to the browsing context containing such a document.
(If we could disallow all that would also be good, but I suspect we need to allow downloads as Chrome does that.)
|
|
||
Comment 3•5 years ago
|
||
(In reply to Anne (:annevk) from comment #2)
My preference would be to allow downloads, but not allow the creation of documents.
Isn't that the behavior we have anyway? There is the test browser_test_data_download.js which tests <a href="data:text/html,<body>data download</body>" download="data-foo.html" id="testlink">download data</a>
So in my opinion we should be good here, or am I missing something?
|
|
Reporter | |
Comment 4•5 years ago
•
|
||
Well, window.open("data:,Hello"); creates a document. text/plain doesn't mean that there's no document object and no scriptable surface.
|
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 7•5 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:sstreich, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 9•5 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Updated•5 years ago
|
Description
•