1741034 - Guessing the URL a cross-origin iframe was redirected to by listening and counting the number of load events

Status: ASSIGNED

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

Description

[Luan Herrera]

Attachment: attack.html

It is possible to try to guess the URL that a cross-origin iframe was redirected to by listening to the load event of the iframe and then redirecting it to the URL you are trying to guess appended by a random hash.

After that, there are two possible outcomes:

1. If you redirect the iframe to the correct URL the iframe was redirected to, no load event will be triggered.
2. If you redirect the iframe to a different URL the iframe was redirected to, the load event will be triggered.

An attacker then would be able to infer the current URL of the cross-origin iframe and thus leak sensitive information that shouldn't be available to them.

This issue is similar to two Chrome bugs (https://bugs.chromium.org/p/chromium/issues/detail?id=1208614 and https://bugs.chromium.org/p/chromium/issues/detail?id=1248444) that were fixed recently but unfortunately are still private.

VERSION
Version: 94.0.1 (64-bit)
Version: 95.0b6 (64-bit)
Operating System: Windows 10

REPRODUCTION CASE

1. Download both "me.php" and "victimName.php" and host the files in a PHP server (this is needed to simulate the targeted redirect you want to leak information from).
2. Download "attack.html" (you don't need to host it on a server).
3. In the "attack.html" file you will need to change the domains of the URLs located in the "tryToGuessURL" function calls so that they match the correct domain of your server. By default, the attack is assuming the files can be found on "http://localhost/victimName.php" and "http://localhost/me.php".
4. Open the "index.html" file and after a few seconds two alert dialogs will show up saying whether you correctly guessed the URL that the iframe was redirected or not.

CREDIT INFORMATION
Reporter credit: Luan Herrera (@lbherrera_)

Comment 1

[Luan Herrera]

Attachment: me.php

Comment 2

[Luan Herrera]

Attachment: victimName.php

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

b/w S2 and S3 - S3 because a prerequisite may be a infinite number of url guesses in advance that to some extent eases the level of how critical this is. However, given chrome fixed this, we should fix this rather than letting it sitting in our backlog.

Comment 4

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Annevk, isn't this a spec issue?

Comment 5

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

https://chromium.googlesource.com/chromium/src/+/5f8ddef5a678553c9bb1491cd5710788e6d571b3%5E%21/

Comment 6

[Anne (:annevk)]

Yeah it is, there's a variety of leaks due to the cross-origin load event. I hadn't seen this particular variant before though. Nice work Luan!

The mitigation Chrome added seems pretty susceptible to timing attacks? However, I don't have anything better.

As for fixing the specification, I suspect we want to wait until all browsers have fixed this. Has this also been reported against WebKit?

Comment 7

[Andrew McCreight [:mccr8]]

(In reply to Anne (:annevk) from comment #6)

As for fixing the specification, I suspect we want to wait until all browsers have fixed this. Has this also been reported against WebKit?

(needinfo for this question)

Comment 8

[Andrew McCreight [:mccr8]]

FWIW, one of the similar Chrome bugs from the reporter is now public: https://bugs.chromium.org/p/chromium/issues/detail?id=1248444

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:hsinyi, since the bug has high severity and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Andrew McCreight [:mccr8] from comment #8)

FWIW, one of the similar Chrome bugs from the reporter is now public: https://bugs.chromium.org/p/chromium/issues/detail?id=1248444

I am thinking that we should give it a higher priority now that Chrome bug is public. Per comment 6, Chrome's fix is a hack but there's probably nothing else that can be done.

Kris, can you please take this? Thanks!

Comment 12

[Kris Maglione [:kmag]]

I'm not so much worried that Chrome's fix is a hack, but I am worried that Anna is right about timing attacks. The fake load event for same-document navigations would be fired almost immediately, while even in the best caching circumstances, it would take at least tens if not hundreds of milliseconds in the fake load event case.

I'm tempted to record how long it took from when the request was initiated to the time the load event fired, and wait approximately that long before firing the fake load event. It may be a bit tricky, though.

Comment 14

[Daniel Veditz [:dveditz]]

Unhiding because the chrome bug is already public and we've picked up a couple of dupes

Comment 15

[Andreas Farre [:farre]]

This worked out better than I expected. It still avoids solving the timing issue, but it aligns us with how Chromium and WebKit works.

Comment 16

[Andreas Farre [:farre]]

Attachment: Bug 1741034 - Part 2: Test that cross-origin same document navigation fires load event. r=peterv!

Comment 17

[Andreas Farre [:farre]]

Attachment: Bug 1741034 - Part 1: Make iframe cross-origin same document navigation fire a load event. r=peterv!