Closed
Bug 1491575
Opened 6 years ago
Closed 6 years ago
Cross-Origin URL Steal is possible using performance.getEntriesByType()
Categories
(Core :: DOM: Core & HTML, defect, P2)
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.
Updated•6 years ago
|
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM
Product: Firefox → Core
Updated•6 years ago
|
See Also: → CVE-2018-18499
Comment 2•6 years ago
|
||
Dragana, can you take a look at this since you fixed bug 1468523.
Flags: needinfo?(dd.mozilla)
Comment 3•6 years ago
|
||
(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)
Comment 4•6 years ago
|
||
(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)
Updated•6 years ago
|
Keywords: csectype-sop
Updated•6 years ago
|
Flags: needinfo?(honzab.moz)
Comment 5•6 years ago
|
||
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: 6 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → DUPLICATE
Comment 6•6 years ago
|
||
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 → ---
Comment 7•6 years ago
|
||
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
Comment 8•6 years ago
|
||
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)
Updated•6 years ago
|
Priority: -- → P2
Comment 11•6 years ago
|
||
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)
Assignee | ||
Comment 12•6 years ago
|
||
Stealing this from Dragana.
Assignee: dd.mozilla → valentin.gosu
Whiteboard: [necko-triaged]
Assignee | ||
Comment 13•6 years ago
|
||
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: 6 years ago → 6 years ago
Resolution: --- → INVALID
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•4 years ago
|
Group: dom-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•