Need test for location bar spoofing via drag and drop of broken javascript: URI

NEW
Unassigned

Status

()

defect
P3
normal
3 years ago
2 years ago

People

(Reporter: mishra.dhiraj95, Unassigned)

Tracking

({csectype-spoof, sec-low})

50 Branch
Points:
---
Bug Flags:
sec-bounty -
in-testsuite ?

Firefox Tracking Flags

(firefox-esr45 wontfix, firefox50 wontfix, firefox51 unaffected, firefox52 unaffected, firefox53 unaffected)

Details

(Whiteboard: [needs test][fxsearch])

Attachments

(4 attachments)

Reporter

Description

3 years ago
Posted video OminiBox-Mozilla.avi
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
(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

3 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

3 years ago
Posted image aboutmozilla.PNG
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

3 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

3 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

3 years ago
Hi Gijis , 

Please can you have a look on the video , it works me on windows as well.
PFA.
Reporter

Comment 9

3 years ago
Summary: OminiBox Spoofing → Location bar spoofing via drag and drop
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.
Component: Untriaged → Location Bar
Flags: needinfo?(gijskruitbosch+bugs)
Flags: sec-bounty?
Flags: needinfo?(mak77)
Priority: -- → P2
(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
Can this be closed now? Maybe duped to the other bug?
Flags: needinfo?(gijskruitbosch+bugs)
(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.
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?
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]
Whiteboard: [needs test] → [needs test][fxsearch]
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-
You need to log in before you can comment on or make changes to this bug.