1339344 - address bar spoofing in firefox via.bookmark

Status: RESOLVED INVALID

(Firefox :: Address Bar, defect)

Description

[:Wester]

Attachment: poc.zip

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

Steps to reproduce:

1.Add a bookmark,its link is below here:

javascript:z=window.open();z.document.write('fake '+document.domain+'!!!<br>cookie is: '+document.cookie);

2.Visiting any website,such as https://google.com,then click that bookmark

3.You will find that firefox open a newtab,the website you visit has been faked success!

4.macOS version:10.12.3 firefox version:51.0.1


Actual results:

firefox open a newtab with the same link you are visiting in address bar.


Expected results:

open a newtab with link "about:blank",just like chrome.

Comment 1

[Andrew McCreight [:mccr8]]

Gijs, do you know who could look into this? Thanks.

Comment 2

[:Gijs (he/him)]

(In reply to Andrew McCreight [:mccr8] from comment #1)
> Gijs, do you know who could look into this? Thanks.

I don't know anybody who's not crazy busy already. Also not convinced this is more than sec-low - if you run script and you can convince the URL bar to show the same domain you're running the script on for the window you then doc.write to, you achieve what, exactly? It'd be different if this worked if you used window.open to open a different-domain URL and you could show that domain's URL + security status.

That said, it's surprising we don't update the location bar state. Not sure what's going on. Somewhat reminiscent of bug 1247968, so maybe Samael can help. Not sure what's up with bug 1247968 either.

Otherwise, Marco, Olli, Boris and me are probably the main people I would look at if we wanted to poke at this more.

Re-pinging you so this doesn't get dropped (though if we do decide on sec-low maybe it should be opened up and de-prio'd for now).

Comment 3

[Boris Zbarsky [:bzbarsky]]

> That said, it's surprising we don't update the location bar state.

Update it from what?

What's going on here is that the opened tab starts as about:blank.  Then document.open() is called on it (implicitly via the document.write call).  Per spec, https://html.spec.whatwg.org/multipage/webappapis.html#opening-the-input-stream step 23 sets the url of that document to the url of the document that called open() (in this case "https://google.com" or whatever).  Simple testcase, to be run as a bookmark:

  javascript:z=window.open();z.document.write('My URL is: ' + location.href);

And that's what we show in the URL bar.  It's the document URL.  It's running with that security origin.

In my opinion it's Chrome that is buggy here: its URL bar is not matching either the security state or location.href of the document being shown.

Comment 4

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #3)
> > That said, it's surprising we don't update the location bar state.
> 
> Update it from what?

Hm, I assumed we updated it for the initially opened window and then created a new about:blank document.

> What's going on here is that the opened tab starts as about:blank.  Then
> document.open() is called on it (implicitly via the document.write call). 
> Per spec,
> https://html.spec.whatwg.org/multipage/webappapis.html#opening-the-input-
> stream step 23 sets the url of that document to the url of the document that
> called open() (in this case "https://google.com" or whatever).  Simple
> testcase, to be run as a bookmark:
> 
>   javascript:z=window.open();z.document.write('My URL is: ' + location.href);
> 
> And that's what we show in the URL bar.  It's the document URL.  It's
> running with that security origin.
> 
> In my opinion it's Chrome that is buggy here: its URL bar is not matching
> either the security state or location.href of the document being shown.

OK, fair enough, I hadn't looked that far. This makes sense. Sounds like we can open up and resolve INVALID? Unless we think that the behaviour in Chrome represents an actual security issue and we need to keep this closed for their sake... I'll let you/Andrew decide that. :-)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Well, so...

If the bookmark just called window.open() but NOT document.open(), then you would get an about:blank but its security origin would still be "https://google.com".  I think in that case browsers pretty uniformly show empty URL bar.   I don't think the Chrome behavior in the document.open() case is necessarily any _worse_ than this.

In an ideal world, browsers would clearly indicate "the origin of the thing you are looking at".  They totally don't right now.

Comment 6

[:Wester]

I found safari has the same behavior with chrome.The opened tabs's security origin still belong to original tab(This is right,in this case,the document.domain and document.cookie still belong to www.google.com),but the location bar doesn't tell us this is google.com as usual in chrome and safari.

Comment 7

[:Wester]

Attachment: Safari.PNG

Comment 8

[Marco Bonardo [:mak]]

I also concur for sec-low, if valid at all, even for the fact you must convince a user to have that bookmark. Pages can't create bookmarks anymore from when we removed addPanel.

Comment 9

[:Wester]

any follow-ups on this issue?

Comment 10

[:Gijs (he/him)]

The address bar isn't lying by saying the domain that controls the page is google.com. The fact that the bookmark has some measure of control is a well-understood aspect of bookmarklets, and so the best I can say is that this ends up basically a dupe of bug 371179 or somewhere else in the near-infinite-supply of bugs for "if you can convince the user to bookmark this piece of arbitrary script and then execute it against a trusted site you can potentially do damage (and Firefox should stop/warn the user at some point along that process)".

I don't think there's any point keeping the bug in a security group, or indeed, keeping the bug unresolved.

Comment 11

[:Wester]

(In reply to :Gijs from comment #10)
> The address bar isn't lying by saying the domain that controls the page is
> google.com. The fact that the bookmark has some measure of control is a
> well-understood aspect of bookmarklets, and so the best I can say is that
> this ends up basically a dupe of bug 371179 or somewhere else in the
> near-infinite-supply of bugs for "if you can convince the user to bookmark
> this piece of arbitrary script and then execute it against a trusted site
> you can potentially do damage (and Firefox should stop/warn the user at some
> point along that process)".
> 
> I don't think there's any point keeping the bug in a security group, or
> indeed, keeping the bug unresolved.


I think we should don't mind that how to convince the user to bookmark this piece of arbitrary script at first,the location bar of firefox has been spoofing successfully from the technical point.

And Chrome、Safari and Brave have taken measures against this.(Not allow address bar displays opend-window domain via user's script)

Comment 12

[Boris Zbarsky [:bzbarsky]]

I don't think that's true at all.  You would observe the same behavior difference if the script that opened the window and did document.write() into it was all inside google.com.  So it's not that other browsers have taken any sort of measures.  It's just that they didn't correctly implement the "document.open changes the document URI and should update the UI accordingly" bit.

Comment 13

[:Wester]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #12)
> I don't think that's true at all.  You would observe the same behavior
> difference if the script that opened the window and did document.write()
> into it was all inside google.com.  So it's not that other browsers have
> taken any sort of measures.  It's just that they didn't correctly implement
> the "document.open changes the document URI and should update the UI
> accordingly" bit.

But my script "z=window.open()" don't open any url,So I think other browers show "about:blank" is correct.Only firefox has this strange behaviour...

Comment 14

[Boris Zbarsky [:bzbarsky]]

> But my script "z=window.open()" don't open any url

Yes, but the document.open() _changes_ its url.  I don't know how to make that any clearer.

Comment 15

[Daniel Veditz [:dveditz]]

It doesn't matter (to an attack) whether or not we show the domain. Blank or not blank, the document IS REALLY running in the domain you ran the bookmarklet on. If it's an attack you have already won. In the Firefox case if a blank address bar furthers your attack then just don't call document.open() -- you can construct a DOM in an about:blank document without that. If showing the real location somehow furthers your attack you can accomplish that in Chrome/Safari by opening another window with a real same-origin URL, and then using the window reference to adjust the content as you see fit. It's all the same, there's no "spoofing" of the location bar going on here.

We seem to be following the specified behavior here.

If we want to add hoops ("I know what I'm doing") to enable bookmarklets that's better handled in other bugs

Comment 16

[:Wester]

alright,maybe my report title is wrong,I also agree with you,there is no address bar spoofing,because the domain is still "google.com"

But in the other three browsers,the domain of newtab is also "google.com" like firefox.


Why they choose to hide the domain name，because the newtab is not "google.com" completely!Contains only a subset of attributes of "google.com"

Comment 17

[Daniel Veditz [:dveditz]]

We appear to be following the spec as noted above; you'd have to ask them why they prefer about:blank for this case.

Comment 18

[:Gijs (he/him)]

As noted elsewhere, please do not obscure original bug summaries and components.