Open
Bug 1322022
Opened 8 years ago
Updated 4 months ago
Need test for location bar spoofing via drag and drop of broken javascript: URI
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
NEW
| Tracking | Status | |
|---|---|---|
| firefox-esr45 | --- | wontfix |
| firefox50 | --- | wontfix |
| firefox51 | --- | unaffected |
| firefox52 | --- | unaffected |
| firefox53 | --- | unaffected |
People
(Reporter: mishra.dhiraj95, Unassigned)
Details
(Keywords: csectype-spoof, reporter-external, sec-low, Whiteboard: [needs test][fxsearch])
Attachments
(4 files)
aboutmozilla.PNG
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161129173726
Steps to reproduce:
Hi Again ,
Omini Bar Spoofing , I am able to replicate the issue in Window's OS and Ubuntu as well.
Actual results:
Please drag the Link into the OminiBox and it spoof.
Demo URL : http://hackies.in/omin.html
1.Open in Latest Firefox.
2.Drag the link in OminiBox.
3.Spoof Occurs
Script :
==omini.html==
<title>
Drag spoof testcase | Dhiraj Mishra.
</title>
<body>
<h4><a href="https://www.google.com" id="a">Please Drag Me To Omnibox</a></h4>
</body>
<script>
var spoof_url = 'https://www.google.com';
spoof_url = 'javascript:' + spoof_url;
ondragstart= function() {
event.dataTransfer.setData('text/plain',spoof_url);
}
ondragend = function(){
document.title = 'Done';
document.write('<h4>The Content is not google.com.</h4>');
}
</script>
Please find the attached Video POC below.
Expected results:
The Spoof should not occur.
Looking forward to it.
Thank you
|
||
Comment 1•8 years ago
|
||
(In reply to Dhiraj Mishra from comment #0)
> Please drag the Link into the OminiBox and it spoof.
>
> Demo URL : http://hackies.in/omin.html
This is a 404. Fixed link (from video):
http://hackies.in/omini.html
> 1.Open in Latest Firefox.
> 2.Drag the link in OminiBox.
> 3.Spoof Occurs
Doesn't work for me in 51 beta 6 (e10s off). Are you testing with e10s on or off? (Check in about:support for "multiprocess windows")
Also doesn't work in nightly with e10s on or off.
Flags: needinfo?(mishra.dhiraj95)
|
Reporter | |
Comment 2•8 years ago
|
||
Hi Gijs ,
Sorry for the worng link,the actuall link is :
http://hackies.in/omini.html
However , i am attaching my about:support screenshot for your review , the above issue works fine for me ,
in the attached screenshot version.
Thank you
Flags: needinfo?(mishra.dhiraj95)
|
|
Reporter | |
Comment 3•8 years ago
|
||
|
||
Comment 4•8 years ago
|
||
Your screenshot shows you're using an ESR build based on Firefox 45. We have not backported minor spoofing fixes to that branch, and we have addressed a couple since then. Please try this in a current release firefox build (50.0.2) -- appears fixed to me.
Flags: needinfo?(mishra.dhiraj95)
|
|
Reporter | |
Comment 5•8 years ago
|
||
Hi Daniel ,
Yes in latest release of firefox (50.0.2) the issue is not replicated in Windows OS , however its working in ESR.
I am attaching a new Video POC , i would request you to please have a look, I am able to replicate it on new release of firefox on Linux.
Thank you
Flags: needinfo?(mishra.dhiraj95)
|
|
Reporter | |
Comment 6•8 years ago
|
||
|
|
||
Comment 7•8 years ago
|
||
I can reproduce on Linux 50, but only in non-e10s mode. Not sure why the behaviour there is any different. All of this will likely go away with the fix for bug 791597. Ni -> me to figure out why the behaviour is different when comparing Linux and OS X / Windows.
Flags: needinfo?(gijskruitbosch+bugs)
|
|
Reporter | |
Comment 8•8 years ago
|
||
Hi Gijis ,
Please can you have a look on the video , it works me on windows as well.
PFA.
|
|
Reporter | |
Comment 9•8 years ago
|
||
|
|
||
Updated•8 years ago
|
Summary: OminiBox Spoofing → Location bar spoofing via drag and drop
|
|
||
Comment 10•8 years ago
|
||
So, I can reproduce on:
v50 with e10s off on Windows
v50 with e10s off on Linux
I cannot reproduce with e10s off, on OS X, or on v51 or nightly.
Using mozregression I found this regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37ab1d54a08e7e1431660b22377428b74dcd090a&tochange=62c5218b7325723c8d88d5c4cfe4fa241f905406
I suspect this has been fixed by bug 1310737.
Marco, I tried to debug *why* that change fixed this, and I couldn't quite figure it out. My hunch is that we used to avoid the google load when it didn't match the lastLocationChange, but never reverted the URL bar. That code is gone now, so I don't think the same thing can happen again.
Note that the testcase seems to be needlessly complex - the dragstart handler doesn't actually do anything, so really what's happening is a dragend listener is invoked after the drag finishes that starts an alternative load, that races with the load started by dropping the new URI in the location bar. That also explains why this doesn't reproduce in e10s as-is, though I'm not convinced it could never be reproduced in e10s with a different testcase.
In any case, given the severity and the fact that 51 is already fixed, I'm not sure there's much to do here, though it might be worth poking at it more to make sure there's not some edgecase we haven't thought of.
status-firefox50:
--- → affected
status-firefox51:
--- → unaffected
status-firefox52:
--- → unaffected
status-firefox53:
--- → unaffected
status-firefox-esr45:
--- → affected
Component: Untriaged → Location Bar
Flags: needinfo?(gijskruitbosch+bugs)
|
||
Updated•8 years ago
|
Flags: sec-bounty?
|
||
Updated•8 years ago
|
Flags: needinfo?(mak77)
Priority: -- → P2
|
|
||
Comment 11•8 years ago
|
||
(In reply to :Gijs from comment #10)
> Marco, I tried to debug *why* that change fixed this, and I couldn't quite
> figure it out. My hunch is that we used to avoid the google load when it
> didn't match the lastLocationChange, but never reverted the URL bar. That
> code is gone now, so I don't think the same thing can happen again.
I suspect what fixed it is that we used to invoke _loadURL and then bail out in the middle of it, at the
- if (openUILinkWhere == "current" && !matchLastLocationChange) {
- return;
- }
Now we check the lastLocationChange even before trying to invoke _loadURL, so we skip a bunch of horrible initialization that we should have undone before the early return.
I agree that code-wise there isn't much to do here, thus lowering prio.
It may be worth to write an automated test case, for the future.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mak77)
Priority: P2 → P3
|
||
Comment 12•8 years ago
|
||
Can this be closed now? Maybe duped to the other bug?
Flags: needinfo?(gijskruitbosch+bugs)
|
|
||
Comment 13•8 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #12)
> Can this be closed now? Maybe duped to the other bug?
Imo we should retain this bug to write an automated test for it, sooner or later.
|
|
||
Comment 14•8 years ago
|
||
I agree with Marco that we should leave the bug open until we have a test. We can remove the security flag either now, if we're agreed that (given that it's a sec-low spoof) this doesn't need to be hidden, or otherwise when ESR45 EOLs, given that this is fixed in 52.
Flags: needinfo?(gijskruitbosch+bugs) → in-testsuite?
Keywords: csectype-spoof,
sec-low
Summary: Location bar spoofing via drag and drop → Need test for location bar spoofing via drag and drop of broken javascript: URI
Whiteboard: [needs test]
|
|
||
Updated•8 years ago
|
Whiteboard: [needs test] → [needs test][fxsearch]
|
|
||
Comment 15•8 years ago
|
||
Does not qualify for a bug bounty because it's sec-low and essentially a duplicate of bug 1310737
Group: firefox-core-security
Flags: sec-bounty? → sec-bounty-
|
|
||
Updated•4 years ago
|
Points: --- → 3
|
||
Updated•2 years ago
|
Severity: normal → S3
|
||
Updated•4 months ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•