32x32 Custom Cursor Could Escape Content Area
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: fazim.pentester, Unassigned)
References
Details
(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Attachments
(3 files)
The custom cursor for the 32x32 size is not fully contained within a content area and can escape into the address bar, covering 75% of it. Additionally, it overlays a permissions prompt upto 20%. Therefore, a malicious site could hijack the cursor for spoofing.
Steps to reproduce:
- Extract poc.zip.
- Open poc.html and begin testing.
Reporter | ||
Comment 1•1 year ago
|
||
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Comment 2•1 year ago
|
||
I have tested this issue on Windows. While the 128x128 cursor is properly contained in the browser content area, the 32x32 cursor is not: https://cr.kungfoo.net/style/cursor/abusive-cursor.html
Updated•1 year ago
|
Comment 3•1 year ago
•
|
||
Our functionality seems identical to Chrome. I.e. we and Chrome both implemented this
-
In all cases, the hotspot of the cursor can't escape the content area.
-
If the cursor is > 32 x 32 then none of it can.
It's fairly straightforward to change if we think we need to.
Reporter | ||
Comment 4•1 year ago
|
||
I have reported this issue to Chromium as well at crbug.com/1502051 (Assigned)
Comment 5•1 year ago
|
||
Does this need to be hidden? We've implemented what we publically agreed with Chrome as reasonable restrictions on cursors and all this bug shows is that.
Updated•1 year ago
|
i have reported before on https://bugzilla.mozilla.org/show_bug.cgi?id=1804816 but at that time it set to wont fix, can you check it again?
Comment 8•1 year ago
|
||
I still think the same, fwiw. Though changing this is feasible (maybe shrinking the custom size to 16? To 0?). In any case not quite my call.
Comment 9•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
I still think the same, fwiw. Though changing this is feasible (maybe shrinking the custom size to 16? To 0?). In any case not quite my call.
On the one hand, the bookmark toolbar is (currently) 28px high and the navigation bar is 40px high: a 32px crosses one and bleeds almost all the way through the addressbar in the default config that hides the bookmark toolbar. Something smaller, like 16px would reduce the problem and make it much more likely that a victim would push too far trying to click a toolbar button and have the cursor revert back to revealing the real pointer position.
On the other hand, what is the spoofing scenario? You can put a fake cursor on one of the UI elements but the click won't do the privileged action, it can only do an unprivileged action simulated by the web site. Maybe you have a phishing site on a typo-squatting domain, and if suspicious users check out the site identity button you can show a fake panel with the real name in there to reassure them? In practice we know hardly anyone checks that panel, or if they're suspicious enough to do so the scammer has probably already lost them as phishing victims. Most of the time these days phishing sites don't even try very hard to get plausible domains because they get blocked too fast. Instead they just go for the gullible folks who don't even look.
People keep claiming this is a problem so it's probably worth watching for improved attacks and keeping in touch with Google folks to see if they are thinking of lowering their size limit. Lowering the limit would make real attacks even harder, but not hard enough to stop people trying to claim bug bounties by showing they can still touch things with a fake cursor in a screen recording.
Updated•1 year ago
|
Updated•9 months ago
|
Description
•