Cursory hack – Fake address bar interaction | Hacker News Reader

Cursory hack – Fake address bar interaction

jameshfisher.github.io

107 pointsbenjaminbenben40 comments

Credit where it's due. It seems this is illustrating a sinister use of the original code found here:

https://github.com/benfoxall/cursory-hack

Demo: https://rawgit.com/benfoxall/cursory-hack/gh-pages/

Ha, yes, Ben himself posted this to HN - I didn't realize it was going public!

Unless I'm completely getting myself confused then it's doing something I didn't think was possible and drawing over the browser chrome.

Can anyone explain what's going on here.

After a first look, it seems like this hack involves setting a custom cursor, which is defined as a canvas image that is 128 px tall. This 128px high image is mostly transparent, and has a fake "cursor" image at the top of it. The bottom of this image tracks your real cursor, and the fake cursor at the top of the image makes it seem like your real cursor is hovering over the browser chrome, when in fact it is ~128px lower than it appears. The rest of the effect is achieved via animating the canvas used for the custom cursor.

In terms of mitigation, it seems like at a minimum custom cursors should never be rendered outside the bounds of the page content.

Hello! Author here (along with my inspiration benjaminbenben). This explanation is perfect. And yes, I think the TODO is to not render the custom cursor outside the viewport.

Are you sure that is possible?

At least on Windows, i'm reasonably sure all the API does is tell the OS which image to render as cursor and the cursor is rendered entirely by the OS; meaning there's no control over whether the cursor is being rendered partially outside the viewport or not.

Solutions where the browser would have enough control would likely require rendering the cursor by itself, which would impart it noticable input latency.

Edit: Quick addition of a bounding box to the demo: https://wchristian.github.io/cursory-hack/

The browser could check whether the cursor image would be painted outside the page viewport.

In this case the browser could create a clipped version of the cursor image and set it as the new cursor.

That would be very expensive computationally, and as seen in the padlock, accompanied by latency and jitter.

It would also break the case where pages have legit uses for crosshair style cursors, or cursors that are rotated 180° in order to not overlay contents.

Thanks for the explanation. Most informative comment.

On Chrome Windows 7 version I've got the window un-maximised and the pretend cursor escapes well onto the desktop and outside the bounds of the visible Chrome window itself.

Ditto on Win10

Curious about this as well, didn't think you could escape the viewport but clearly it was overlaying the lock icon in my address bar.

The tracking wasn't great, but maybe that was intentional to illustrate a point.

Move the cursor farther up and you will see it jump.

So I thought this was just doing something on click (showing the fake HTTPS info), but that it maybe didn't work on newer or non-Chrome browsers, e.g. Chrome 52, Safari 9.1, and whatever bug was fixed there. But then I noticed that it causes really weird interactions at the top of the browser, at least on Mac; if you open the page in either Chrome or Safari and move your mouse towards the address bar, it jumps around on Safari and does a "double take" on Chrome. Really interesting!

I'm using Firefox on Windows and it's awfully flickery but it does work.

The original linked hack is clever. But this page is just confusing (in Safari on OS X), for several reasons, not the least of which is the fact that the page is in fact served over https, and if I mouse over the padlock and click it, everything behaves correctly (and even if the page was specially designed for Safari and could figure out where the url bar was, it can't even replicate the behavior Safari has for clicking the padlock because web pages can't show sheet dialogs).

Part of the problem here is the fact that the fake cursor never actually escapes the page on this one. When my mouse is near the top of the page it reverts back to the system cursor instead of the fake one, before it even leaves the frame of the page. The original linked hack worked much better.

There are several similar reports on chromium project.

All of them are nofix.

Really? That is strange, because there is ways this could be exploited... Can you link them to me?

https://news.ycombinator.com/item?id=12260444

Sorry, I'm on mobile. But several similar reports as the HN link shows.

Doesn't seem to work in Safari.

Or Firefox

or on HiDPI

Or on Netscape Navigator

Or in lynx

Confirmed in cURL

On both Firefox and Chromium on Linux the true place of the real cursor stay visible (Firefox displays a thin cross, and chromium a light blue star). The menu position of course doesn't make sense in Firefox :)

Link to the source on github for anyone else without a view source button:

https://github.com/jameshfisher/cursory-hack/blob/gh-pages/i...

It's using a canvas to draw the address bar and adjusting the position every time the mouse moves, but I don't understand the details of it

Note: If you have the home button always visible in chrome, or the bookmarks bar hidden, you'll notice that the demo doesn't work properly.

Interesting... Can this 'hack' be used to convince people that, say, they're in a different/secure website when they're in a malicious website? I ask because since the 'fake' cursor is visible even on the address bar, the page must be able to overwrite the pixels there?

As this demo is now (and probably even with a lot of work) no due to the vast number of browser chrome (UI, not google chrome) configs. It's also very jittery in the demo. That said there is plenty of room for abuse in clicking things like like/tweet/etc buttons it would appear.

Source code: https://github.com/jameshfisher/cursory-hack

Someone should combine this with a "change the address bar url without reloading" in javascript to make it complete.

Edit: looks like it only works on the same origin.

Whoa that is a sweet hack. You should have submitted it to Google for a bug bounty. It should NOT be possible to clickjack the browser's address bar.

It isn't though. This merely changes the display of the cursor. Go to windowed mode (not fullscreen) and pull the cursor down into the address bar and tabs area to see that this does not prevent access to the address bar. It only changes how you perceive the position of the cursor.

Even if that's not able to directly take over the web browser, it's really annoying to have your mouse taken over like that.

Before you click on that remember.

Alt + Left

to go back :P

For those on mac:

⌘ + Left (go back)

⌘ + W (closes the window)

On Safari on OS X 10.11 it just blinks the page.

in firefox, you can't

Reply on news.ycombinator.com