
Cursory hack – Fake address bar interaction - benjaminbenben
https://jameshfisher.github.io/cursory-hack/
======
rShergold
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](https://github.com/benfoxall/cursory-hack)

~~~
dividuum
Demo: [https://rawgit.com/benfoxall/cursory-hack/gh-
pages/](https://rawgit.com/benfoxall/cursory-hack/gh-pages/)

------
andybak
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.

~~~
gabemart
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.

~~~
jamesfisher
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.

~~~
Mithaldu
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/](https://wchristian.github.io/cursory-hack/)

~~~
jabiko
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.

~~~
Mithaldu
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.

------
yladiz
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!

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

------
eridius
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.

------
angry-hacker
There are several similar reports on chromium project.

All of them are nofix.

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

~~~
angry-hacker
[https://news.ycombinator.com/item?id=12260444](https://news.ycombinator.com/item?id=12260444)

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

------
athenot
Doesn't seem to work in Safari.

~~~
mrweasel
Or Firefox

~~~
benwaffle
or on HiDPI

~~~
hexadec0079
Or on Netscape Navigator

~~~
HeadlessChild
Or in lynx

~~~
strictnein
Confirmed in cURL

------
wazoox
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 :)

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

[https://github.com/jameshfisher/cursory-hack/blob/gh-
pages/i...](https://github.com/jameshfisher/cursory-hack/blob/gh-
pages/index.html)

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

------
heywire
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.

------
benten10
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?

~~~
joshstrange
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.

------
amga_
Source code: [https://github.com/jameshfisher/cursory-
hack](https://github.com/jameshfisher/cursory-hack)

------
ikeboy
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.

------
smidgen2
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.

~~~
hexadec0079
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.

------
yumaikas
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.

------
oolongCat
Before you click on that remember.

Alt + Left

to go back :P

~~~
redbeard0x0a
For those on mac:

⌘ + Left (go back)

⌘ + W (closes the window)

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

------
wodenokoto
in firefox, you can't

