User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140605174243 Steps to reproduce: On mozilla firefox only , you can use a specialy crafted cursor when you drag and drop a content. With a malicious cursor specialy crafted you can make drag and drop for fake into the webpage , but in reality , you drag and drop into the location bar (leading to spoofing or others) Steps: -1 Go to https://www.alternativ-testing.fr/Research/Mozilla/cursorjackingdragbigcursor.html -2 Try to drag and drop the blue link into the input text Actual results: Content is dragged and dropped into the location bar instead of the "input text". This issue is a CursorJacking / ClickJacking / Spoofing vulnerability. Expected results: Mozilla Firefox is the only web Browser that allow a specialy crafted cursor when a user dragged a content , it's a bad way.
I have tested this on Mac Os X 10.9.2 only. If this don't works on windows please test it on Mac Os X.
Summary: Cursor Specialy crafted can be used for make a fake drag and drop into the webpage but in reality the content is draged and droped into the location bar → Cursor Specialy crafted can be used for make a fake drag and drop into the webpage but in reality an other content is dragged and dropped into the location bar
We prefer to have the Proof of concepts as attachments to the bug along with any reproduction instructions as comments rather than visiting external websites. As such I took a copy of the page source and attached it as a comment to this bug. using FX 30 on OS X 10.9.3 I am not able to reproduce the reported behavior. tested with a local file open, a simple http server (python) and a local apache server the dragged contents show up in the text box and the prompt occur as indicated but they are not spoofed into the url/awesomebar
Summary: Cursor Specialy crafted can be used for make a fake drag and drop into the webpage but in reality an other content is dragged and dropped into the location bar → drag and drop with a cursor in content is redirected to location bar
Created attachment 8447566 [details] TESTCASE2.html cursor:url("https://www.alternativ-testing.fr/Research/Mozilla/pointer2visible.png"),default; instead of cursor:url("pointer2visible.png"),default; and this works very fine. works with you?
Please use TESTCASE2.HTML instead of PoC.HTML. On PoC.html , a small error is here.
and also , you should have the menu bar for this issue works fine.
The PoC.HTML that you have uploaded is wrong. I have uploaded a TESTCASE2.HTML with no error. cursor:url("https://www.alternativ-testing.fr/Research/Mozilla/pointer2visible.png"),default; instead of cursor:url("pointer2visible.png"),default; And you should have the menu bar visible for this issue works with my testcase (if you don't have the menu bar an other poc can be coded as well). THIS TESTCASE WORKS ONLY ON MAC OS X and don't works on windows. I remain at your disposal if you require any futher information.
Whiteboard: [reporter-external] → [reporter-external][WORKS ON MAC OS X ONLY][Please use testcase2]
Seems to be a non-issue on Linux -- the mouse cursor is reset by the UA when you start dragging, thus revealing its true position. Still, even if it would trick me into dropping something in the URL bar it seems like a sec-low at worst. -> Widget:Cocoa at a guess
Component: General → Widget: Cocoa
new POC appears to work as described on OS X FX 30. Interestingly the urlbar/awesomebar does get the input text but the tab title remains my test location. This is limited to OS X and you can see the ghosted url that is being dragged if one looks carefully. I'm gonna agree with Mats that this is likely sec-low
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase → csectype-spoof, sec-low
Whiteboard: [reporter-external][WORKS ON MAC OS X ONLY][Please use testcase2] → [reporter-external]
The second testcase doesn't work on Windows, either -- I just checked to be sure. So I suppose the bug is somewhere in Cocoa Widgets dragging code. As this isn't urgent, I'll probably get to it in a week or two.
Actually, looking more closely at https://www.alternativ-testing.fr/Research/Mozilla/pointer2visible.png, the problem may be in cross-platform code, after all. We may have to limit the size of custom cursors in some way. (As best I can tell, the only reason the bug doesn't happen on Windows is that the cursor gets changed to a standard "not-allowed" cursor as soon as you start dragging -- presumably because the mouse isn't yet over a location where the object can "legally" be dropped.)
> the mouse cursor is reset by the UA when you start dragging, thus revealing its true position. Or maybe we should just do this on OS X, as we already do on Windows and Linux.
How is making the user drag a link to the URL bar any worse than just setting document.location programmatically? Agree with the sec-low rating. Unhiding the bug because maybe we can get this as a mentored bug.
Flags: sec-bounty? → sec-bounty-
> maybe we can get this as a mentored bug This has some tricky design decisions (see comment #11 and comment #12). So it's probably not a good bug for mentoring. I hope to get to it later this week.
You need to log in before you can comment on or make changes to this bug.