361298 - URL spoof using custom cursor with CSS3 hotspot

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[David Eckel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

The URL bar can be spoofed by using a large, mostly transparent custom cursor image and dynamically modifying the hotspot coordinates as per CSS3 specs (http://www.w3.org/TR/css3-ui/#cursor). Cursors will overflow outside of the browser content area. Affects Firefox 1.5 and later.

Reproducible: Always




This spoof will not work if the mouse cursor leaves the browser content area, and may not be pixel-perfect depending upon the users' configuration of Firefox.

Due to poor performance, it is not a viable option to leave the spoof URL image as a cursor constantly. It will cause an obvious jitter effect on the URL bar when the mouse is moved, especially if the spoof image is large to accommodate large browser windows. A cleverly crafted attack site would try to minimize the amount of mouse movement, and keep the mouse movement near the top of the page.
	
In the attached example, the spoof URL image is disabled when the mouse moves. This exposes the true URL while the mouse is moving, but a cleverly crafted host URL could make this "switch" appear to be a glitch causing a character to be transposed with another character, something many users may not even notice.
	
To be even more creative, one could dynamically generate spoof URL images using a canvas and toDataURL(). This would be useful to provide the illusion that the site is using encryption. Since the full URL bar would have to be overlayed with a yellow box and padlock icon, the image width could be determined dynamically, assuming that all users have the search box and "Go" button visible on their browser.
	
The attached example could use more fine tuning with regards to mouseover events due to the fake cursor image being displayed. For example, to make the status bar text persist for anchors when the mouse stops moving by wrapping the spoof cursor image in an anchor tag with the same href as the anchor below the image.

Comment 1

[David Eckel]

Attachment: Proof of concept files

Attachment contents:
index.html
spoof.js
url.gif
arrow.png
pointer.png
text.png

Comment 2

[Daniel Veditz [:dveditz]]

You could get pretty close to perfectly spoofing an SSL site with this. Not sure we could get a fix in for the impending releases, but definitely want on the branches soon.

Comment 3

[Jay Patel [:jay]]

Not blocking the releases for this, but we will take a patch if we can get some traction on this bug.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What exactly should we do here? We obviously need to restrict CSS3 cursors in some way, but how?

Comment 5

[Jesse Ruderman]

Can they be restricted so they appear only in the content area, and don't go outside of it?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That would be hard.

We probably could track the cursor size along with mouse events and if the cursor spills *above* the content area, disable it.

Comment 7

[David Eckel]

(In reply to comment #6)
> We probably could track the cursor size along with mouse events and if the
> cursor spills *above* the content area, disable it.

If this approach is used, you should test for overflow in all directions to prevent spoofing of the status bar and any unforeseen exploitations involving sidebars. This would also prevent the use of cursors to spoof events that appear to occur outside of the browser window, such as on the OS toolbar.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That would suck. Maybe we have no choice.

Comment 9

[Daniel Veditz [:dveditz]]

Unfortunately if we don't let the cursor spill over a little at least to the bottom and right then a typical "arrow replacement" cursor isn't going to be able to point at things near the bottom or right edges (or left if it's reversed).

Or is that what roc means would "suck"?

Would it make sense to limit the cursor image to a certain size range? The one in this spoof would be insane for an actual cursor. 64x64? 100x100? Would there be some way to restrict to make sure the hot-spot is near a non-transparent area and that there's no big gaps of transparency? (just dreaming here).

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, that's what I meant by "would suck".

Restricting the size to 64x64 sounds good to me. Easy to implement, would make this infeasible to use in an exploit IMHO.

Comment 11

[Jay Patel [:jay]]

Assigning to roc.

roc:  code freeze is scheduled for next Thur. 1/18... could you get a patch together quickly for this?

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: simple approach

This is the simple approach. Works on GTK2, and presumably on Windows (can't test yet)

Comment 13

[Stuart Parmenter]

Comment on attachment 251566 [details] [diff] [review]
simple approach

We should at least scale the image down here or crop it.   Just erroring out is going to cause web authors confusion.

Comment 14

[Daniel Veditz [:dveditz]]

Are we going to get a tested scaling-down patch by Thursday? I don't mind confusing a few web authors who are trying big cursors if it prevents this spoof, and we can file a bug on making it nicer later.

64x64 might be a bit small. 100x100 or 128x128 would still prevent spoofing the url bar, you could only cover a bit of it only when you were pointing at the right part of the screen.

You could throw a message at the error console and call it done IMO.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> Are we going to get a tested scaling-down patch by Thursday?

Probably not for Windows, where I can't currently test.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

So I guess it's up to Stuart to say what he's OK with...

Comment 17

[Stuart Parmenter]

lets do 128x128 for now and then try to get a patch to scale after this?

Comment 18

[Daniel Veditz [:dveditz]]

Stuart: is that an r=you for same patch with new numbers? if so a=dveditz for landing on the 1.8 and 1.8.0 branches.

Comment 19

[Stuart Parmenter]

yeah, r/sr=me

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fixed on trunk and branches. Filed bug 368143 for the rescaling.

Comment 21

[Martijn Wargers (dead)]

Verified fixed on trunk.
I can see the issue in a 2007-01-24 build, but not anymore in a 2007-01-25.

Also verified that the spoof doesn't work in the latest branch builds.