1407574 - Firefox allows you to insert confirm/alert/prompt dialog in any domain with the back button

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[Jose María Acuña]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce:

1- go to: http://createcharts.esy.es/permission-prompt.html
2- click the "test" button
3- click the back button of the browser
4- an alert appears on the current page


Some observations:

- the url changes to the "about: blank" format but does not change the behavior of the current page
- it is not possible to interact with the elements of the page (links, buttons, etc.)
- I believe that the content of the page should be changed  (blank page?) to avoid fraudulent use
- Tested on Firefox 56.0 (64-bit)
- Firefox Nightly 58.0a1 and Firefox Developer Edition 57.0b7 return: SecurityError - Permission denied to access property "document" on cross-origin object

Comment 1

[Daniel Veditz [:dveditz]]

We changed the behavior of data: urls in Firefox 57 -- they are no longer same origin (behavior matches other browsers now). That's probably the source of the security error. try your testcase with <iframe srcdoc=> instead perhaps?

Comment 2

[Jose María Acuña]

It's great that it's changed in version 57

The problem I see in version 56.0 does not have its origin src or srcdoc:

- in the example I used src with data:text/html format to paint a button but could have skipped it and execute onload on the iframe.

For example:

<iframe onload="t=this;t.contentDocument.body.innerHTML+='<s'+'cript>setTimeout(function(){parent.location=\'https://play.google.com/store\';},0);</s'+'cript>';location='javascript:try{parent.document.body.innerHTML=t.contentWindow.document.body.innerHTML}catch(e){document.title=\'Google Play\';var p = prompt(\'password?\');alert(p);'}"></iframe>

I think the problem is that when you click the back button, an exception occurs because the variable t is not defined and in the catch force the message.

Comment 3

[Jose María Acuña]

Attachment: ice_video_20171012-202739.webm

Comment 4

[Jose María Acuña]

In this case, I execute the script in the onload of the iframe:

http://createcharts.esy.es/permission-prompt-yahoo-mail.html

Tested on Firefox 56.0.1 (64-bit), Firefox Nightly 58.0a1 and Firefox Developer Edition 57.0b7

Comment 5

[Jose María Acuña]

Attachment: test_video_20171017-104817.webm

Comment 6

[Jose María Acuña]

Another aspect that I consider relevant:
- with the example of yahoo mail, the notifications dialog is maintained making the identity of the domain more confusing.

Comment 7

[Jose María Acuña]

I had considered that this bug was not critical because the url expressly shows the protocol "about:blank"
In any case, I wanted to go deeper and other scenarios of much confusion can be produced.

Imagine that you want to access a web page and the browser directs you to an unsafe website (legitimate page displayed by Firefox).
Then, press the Back button to be safe and a message appears on the screen that can deceive the user.

1- access to http://createcharts.esy.es/permission-prompt-link.html
2- click on the link
3- press the "Go Back" button that appears in blue on the screen

(tested in the latest versions of firefox)

Comment 8

[Jose María Acuña]

Attachment: ice_video_20171102-155931.webm

Comment 9

[Jose María Acuña]

In addition, the response request can be modified by a request without content (204) so that a redirection does not occur.

In the previous example,
we replace https://www.mozilla.com:8080 with https://docs.google.com/drawings/u/0/jserror

Comment 10

[Jose María Acuña]

As well,
from another page you can access the document with window opener property and modify its behavior.

I modify the title of the page and its favicon and I add an iframe whose source is another web with an alert.

Example: http://createcharts.esy.es/permission-prompt-link.html

Attached video

Comment 11

[Jose María Acuña]

Attachment: ice_video_20171106-152653.webm

Comment 12

[Jose María Acuña]

I do not understand why no priority is set for this bug

Comment 13

[Jose María Acuña]

(In reply to Jose María Acuña from comment #7)
> I had considered that this bug was not critical because the url expressly
> shows the protocol "about:blank"
> In any case, I wanted to go deeper and other scenarios of much confusion can
> be produced.
> 
> Imagine that you want to access a web page and the browser directs you to an
> unsafe website (legitimate page displayed by Firefox).
> Then, press the Back button to be safe and a message appears on the screen
> that can deceive the user.
> 
> 1- access to http://createcharts.esy.es/permission-prompt-link.html
> 2- click on the link
> 3- press the "Go Back" button that appears in blue on the screen
> 
> (tested in the latest versions of firefox)

NOTE: The tests described from comment number 7 are part of a different bug because I think it is a different case.

The new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1415553

Comment 14

[:Gijs (he/him)]

So AFAICT the issue is that we're showing an alert that's embedded in inline script in a frame on a history navigation. Fixing this seems like it should involve not loading the iframe until its parent has loaded and been displayed, or something. I can't reproduce the icon/title changes, only the alert - so perhaps an initial fix could be blocking alerts on history navigations like this, but that feels a bit like a stopgap and not addressing the core issue, though maybe I misunderstand what that is.

In any case, this feels like a gecko issue to me. It seems we got rid of Core::Untriaged, so dumping in Core::DocNav for now, but chances are this wants to live somewhere else. Attempting to radar this to some people on platform...

Comment 15

[Andrew McCreight [:mccr8]]

Olli, do you have any ideas here?

Comment 16

[Samael Wang [:freesamael] (away for now)]

It's worth noting that we're also modifying the behavior of javascript: URI in bug 836567, so the iframe's URL in history entries will no longer be a javascript: URI, but the previous active document's URL (likely about:blank for these examples).

Comment 17

[Jose María Acuña]

Something new?

Comment 18

[Samael Wang [:freesamael] (away for now)]

I think this will be fixed by bug 836567, and I'm currently working on that. We can revisit this bug after bug 836567 gets fixed.

Comment 19

[Jose María Acuña]

The web server createcharts.esy.es is out of use.
Now the test pages are hosted at https://www.finanser.es/test/

Example: https://www.finanser.es/test/permission-prompt-yahoo-mail.html

Comment 20

[Daniel Veditz [:dveditz]]

The finanser.es testcase in comment 19 doesn't show any spoofing in Nightly. What build are you seeing the problem on?

Comment 21

[Jose María Acuña]

The bug is reproducible in:

1- Firefox Nightly 64.0a1 (2018-10-15) (64-bit) for Windows 10
2- Firefox Quantum 62.0.3 (64-bit) for Windows 10



(1) https://drive.google.com/file/d/1oTx2r2ukSttQ-qGQ9PvU8OwrWS4u3MYH/view
(2) https://drive.google.com/file/d/10WpSV-oeL--6SgbBQH2HZKXe4-MDmw4u/view

Comment 22

[Jose María Acuña]

At this time, the bug is not reproducible in:

1- Firefox Nightly 68.0a1 (2019-03-27) (64-bit) for Windows 10
2- Firefox Quantum 66.0.1 (64-bit) for Windows 10

Test: https://www.finanser.es/test/permission-prompt-yahoo-mail.html

Comment 23

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #22)

At this time, the bug is not reproducible in:

1- Firefox Nightly 68.0a1 (2019-03-27) (64-bit) for Windows 10
2- Firefox Quantum 66.0.1 (64-bit) for Windows 10

Test: https://www.finanser.es/test/permission-prompt-yahoo-mail.html

I can still reproduce if I hit the back button repeatedly (and after doing that once, it reproduces with just hitting the back button once, when the yahoo mail page loads). Maybe something changed wrt caching or something, but this doesn't seem fully fixed.

Comment 24

[Jose María Acuña]

(In reply to :Gijs (he/him) from comment #23)

(In reply to Jose María Acuña from comment #22)

At this time, the bug is not reproducible in:

1- Firefox Nightly 68.0a1 (2019-03-27) (64-bit) for Windows 10
2- Firefox Quantum 66.0.1 (64-bit) for Windows 10

Test: https://www.finanser.es/test/permission-prompt-yahoo-mail.html

I can still reproduce if I hit the back button repeatedly (and after doing that once, it reproduces with just hitting the back button once, when the yahoo mail page loads). Maybe something changed wrt caching or something, but this doesn't seem fully fixed.

I have tried pressing the Back button several times and the javascript alert does not appear
Video attachment: https://drive.google.com/file/d/15BKUFoVRg8nMAqqQA1560snDmtrsJzT_/view

Comment 25

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #24)

I have tried pressing the Back button several times and the javascript alert does not appear
Video attachment: https://drive.google.com/file/d/15BKUFoVRg8nMAqqQA1560snDmtrsJzT_/view

Perhaps the difference is that I'm not signed into yahoo mail?

Comment 26

[Jose María Acuña]

No, it does not reproduce in any case.
I've tried other pages and the bug does not play either.

Comment 27

[Jose María Acuña]

(In reply to Jose María Acuña from comment #21)

The bug is reproducible in:

1- Firefox Nightly 64.0a1 (2018-10-15) (64-bit) for Windows 10
2- Firefox Quantum 62.0.3 (64-bit) for Windows 10

(1) https://drive.google.com/file/d/1oTx2r2ukSttQ-qGQ9PvU8OwrWS4u3MYH/view
(2) https://drive.google.com/file/d/10WpSV-oeL--6SgbBQH2HZKXe4-MDmw4u/view

Hello,
I just did the test in the latest version of Firefox Developer Edition for Windows 10 (with and without authentication in the Yahoo mail service) and the bug is not reproducible either.

3- Firefox Developer Edition 67.0b6 (64-bit) for Windows 10

(3) https://drive.google.com/file/d/1UlNxcP4CZu1kmYPWENscZW0NGep1Qmka/view

Comment 28

[Jose María Acuña]

In summary,

this bug it does not reproduce in:

1- Firefox Nightly 68.0a1 (2019-03-27) (64-bit) for Windows 10

2- Firefox Quantum 66.0.1 (64-bit) for Windows 10

3- Firefox Developer Edition 67.0b6 (64-bit) for Windows 10

Comment 29

[Jose María Acuña]

What's new?

Comment 30

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #29)

What's new?

I can still reproduce on current beta (69), so I think the bug is still valid.

Comment 31

[Daniel Veditz [:dveditz]]

I can reproduce (eventually, lots of back clicking) in nightly 70.0a1 as well. Easily reproduced on ESR-60 with a single click. Not a very normal action people would take though. When it does work, though, it's disturbing that the prompt script is running on top of the wrong domain.

Comment 32

[Jose María Acuña]

Hi! How are you?

It's been 12 months since I received a reward for this bug.

Currently does not reproduce in any version of Firefox.
Do you plan to fixed it and assign a cve?

Thank you. Regards.

Comment 33

[Jose María Acuña]

Hello,
sorry for insisting, but can this issue be made public?

Comment 34

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #33)

Hello,
sorry for insisting, but can this issue be made public?

The understanding from the last few comments is that this isn't fixed yet. If the issue is not fixed, I don't understand why we should open up the ticket.

Trying very quickly, I don't see an issue with alerts, but the address bar's identity block is confused, showing a document icon and claiming that https://www.finanser.es/test/permission-prompt-yahoo-mail.html is "stored on [my] computer".

Johann, can you take a look?

Comment 35

[Johann Hofmann [:johannh]]

I have no idea what fixed the original bug. It's reproducible in older builds but definitely not in newer builds. I tried to get the fix range from mozregression but the behavior is super weird to the point where I stopped investigating (e.g. no matter which revision I would run the bug would reproduce only if it was the very first build mozregression started). It definitely stops some time in the 70s.

The local file icon thing seems to be a regression from bug 1570678. I'm not sure if it makes sense to transform this bug here or open up a new one and block it against bug 1570678. I can take a closer look at that, whenever I get to it :)

Please note that in the near future, when we re-enable browser.navigation.requireUserInteraction and fix the dependencies of bug 1645211, the user will not be able to navigate back to the page because it didn't have user interaction before forwarding. We should probably still fix the local file icon bug.

Comment 36

[:Gijs (he/him)]

Having just re-checked, I can now reproduce a change in reproducability between 65 and 66 with mozregression on my Windows machine. That narrows down to this window:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bb2895bfd1bc3d83c309e904dbe74e0c60c3fac9&tochange=06e3993985b77e62c9b6ee1f9dba87da407eb6d1

which noticeably includes bug 1270059, which would change the timing of when we run setTimeout events. If that accidentally "fixed" this issue on some machines, then it is likely that a modified testcase would still work / have worked, given that AFAICT you could move all the setTimeout calls to happen after pageload of the JS URL.

On my mac, I can still reproduce on later releases. Going to see what fixed it there.

Comment 37

[:Gijs (he/him)]

OK, on my mac, this was fixed when bug 836567 was fixed, in Firefox 74, which makes a lot more sense.

Tom, based on that, can we open this up?