1211282 - XSS using location

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

Attachment: child.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

Steps to reproduce:

1. open new window.
2. new window has script 「opener.location = "javascript:alert(location)";」


Actual results:

Alert occurred (Is this UXSS?)


Expected results:

block script (like Chrome)

Comment 1

[Jun (Request needinfo for comment, I ignore other updates)]

Sorry this may be not valid.

Comment 2

[Jun (Request needinfo for comment, I ignore other updates)]

I need bit more research on this. Making it inaccessible for now.

Comment 3

[Jun (Request needinfo for comment, I ignore other updates)]

Attachment: new.html

Open the new.html and click the link. You will get an alert. If you change the script in child.html to below, it also works.

window.location="data:text/html;base64,PHNjcmlwdD5vcGVuZXIuYWxlcnQob3BlbmVyLmxvY2F0aW9uKTwvc2NyaXB0Pg==";

However both of them does not work in Chrome. What's the reason? Errors are below.

opener.location="javascript:alert(location)"
Blocked a frame with origin "null" from accessing a frame with origin "null". Protocols, domains, and ports must match.

window.location="data:text/html;base64,PHNjcmlwdD5vcGVuZXIuYWxlcnQob3BlbmVyLmxvY2F0aW9uKTwvc2NyaXB0Pg=="
Uncaught SecurityError: Blocked a frame with origin "null" from accessing a frame with origin "null".  The frame requesting access has a protocol of "data", the frame being accessed has a protocol of "file". Protocols must match.

However it does only work in File:// (till now). Please let me know is it still valid bug or this is spec.

Comment 4

[:Gijs (he/him)]

I'm pretty sure all this is is principal inheritance for data and js URIs working the way it's supposed to, but I defer to bholley or other DOM/sec folks to confirm.

Comment 5

[Bobby Holley (:bholley)]

Are you running these in separate domains? If these new.html and child.html were loaded from separate origins, this would indeed be UXSS. But if you're just loading them locally in the same directory over a file:// URI, then they'll end up same-origin.

The different you're probably seeing with chrome is the slight variations in file:// URI policy between the browsers. In Firefox, child windows over file:// inherit the origin of the parent, which doesn't seem to happen in Chrome. I'd be pretty surprised if the spec said much if anything about security behavior with file:// URIs.

Can you confirm whether you see anything suspicious when the two frames are actually loaded on separate domains? If you don't have access to a webserver, you can simulate this in Firefox by putting them in unrelated directorys /home/you/foo/new.html and /home/you/bar/child.html.

Comment 6

[Jun (Request needinfo for comment, I ignore other updates)]

Thanks for quick review.

I've simulated cross origin by your suggestion and both of them did not work. But to clarify my report, please see below live PoC.

http://szabist.web.fc2.com/loop.html

Go to above link and click on the link. Below is what Chrome says.

Uncaught SecurityError: Blocked a frame with origin "null" from accessing a frame with origin "http://szabist.web.fc2.com".  The frame requesting access has a protocol of "data", the frame being accessed has a protocol of "http". Protocols must match.

But Firefox gives an alert with opener's location.
I think Chrome has the point because script from protocol "data" is accessing data which has protocol "http". Isn't it SOP bypass?

I think Firefox checks navigator of the window. If it's same-origin with opener then Firefox will let it access opener even though protocol with "data" is accessing "http".

Why I though this is because I tried to farther navigate loops.html to "data" from another opener or child with different origin but failed to access "http".

Comment 7

[Boris Zbarsky [:bzbarsky]]

> I think Firefox checks navigator of the window. 

No, Firefox gives a document loaded from data: the origin of the thing that loaded it.  So the origin of the "data:" document has an "http:" origin.  This is longstanding and well-documented behavior, dating back to the original implementation of data: 
in Gecko well over a decade ago.

Comment 8

[Jun (Request needinfo for comment, I ignore other updates)]

Hi, :bz

It's you again making me loser :p I'll find another stage(bug) to fight with you again :p BTW, thank you for the info.

Comment 9

[:Gijs (he/him)]

Is there a reason not to resolve as worksforme and mark non-sec-sensitive at this point?

(I looked for dupes and couldn't find something that was generic enough)

Comment 10

[Matt Wobensmith [:mwobensmith][:matt:]]

Intended behavior and not a bug. Resolving and unhiding.