Closed Bug 1491575 Opened 3 years ago Closed 3 years ago

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

Categories

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

60 Branch
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: proof131072, Assigned: valentin, NeedInfo)

References

Details

(Keywords: csectype-sop, Whiteboard: [necko-triaged])

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.
Tested on Firefox Nightly 64.0a1 (2018-09-15) (64-bit).
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM
Product: Firefox → Core
See Also: → CVE-2018-18499
Dragana, can you take a look at this since you fixed bug 1468523.
Flags: needinfo?(dd.mozilla)
(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.
Assignee: nobody → dd.mozilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(dd.mozilla)
(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.
Flags: needinfo?(proof131072)
Flags: needinfo?(honzab.moz)
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.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → DUPLICATE
Duplicate of bug: 1492207
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?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
Depends on: CVE-2018-18494
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.
Status: REOPENED → NEW
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
Flags: needinfo?(proof131072)
See Also: → 1495324
Priority: -- → P2
Duplicate of this bug: 1495324
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
Flags: needinfo?(proof131072)
Stealing this from Dragana.
Assignee: dd.mozilla → valentin.gosu
Whiteboard: [necko-triaged]
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.
Status: NEW → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.