Welcome to HSBC, the world’s seventh-largest bank!
Of course, the page you’re reading isn’t actually hosted on hsbc.com;
it’s hosted on jameshfisher.com.
But when you visit this page on Chrome for mobile and scroll a little way,
the page is able to display itself as hsbc.com -
and worse,
the page is able to jail you in this fake browser!
In this post I show how the attack works,
then suggest some ways Chrome can fix this vulnerability,
then finally show you how to get out if you’re still stuck here.
But first, the proof:
In Chrome for mobile,
when the user scrolls down,
the browser hides the URL bar,
and hands the URL bar’s screen space to the web page.
Because the user associates this screen space with “trustworthy browser UI”,
a phishing site can then use it to pose as a different site,
by displaying its own fake URL bar -
the inception bar!
This is bad, but it gets worse.
Normally, when the user scrolls up,
Chrome will re-display the true URL bar.
But we can trick Chrome so that it never re-displays the true URL bar!
Once Chrome hides the URL bar,
we move the entire page content into a “scroll jail” -
that is, a new element with overflow:scroll.
Then the user thinks they’re scrolling up in the page,
but in fact they’re only scrolling up in the scroll jail!
Like a dream in Inception,
the user believes they’re in their own browser,
but they’re actually in a browser within their browser.
Here’s a video of the hack in use:
But it gets even worse!
Even with the above “scroll jail”,
the user should be able to scroll to the top of the jail,
at which point Chrome will re-display the URL bar.
But we can disable this behavior, too!
We insert a very tall padding element
at the top of the scroll jail.
Then, if the user tries to scroll into the padding,
we scroll them back down to the start of the content!
It looks like a page refresh.
In my proof-of-concept,
I’ve just screenshotted Chrome’s URL bar on the HSBC website,
then inserted that into this webpage.
With a little more effort,
the page could detect which browser it’s in,
and forge an inception bar for that browser.
With yet more effort,
the inception bar could be made interactive.
Even if the user isn’t fooled by the current page,
you can get another try
after the user enters “gmail.com” in the inception bar!
Is this a serious security flaw?
Well, even I, as the creator of the inception bar,
found myself accidentally using it!
So I can imagine this technique fooling users
who are less aware of it,
and who are less technically literate.
The only time the user has the opportunity to verify the true URL
is on page load,
before scrolling the page.
After that, there’s not much escape.
How can you guard yourself against this attack?
I don’t really know.
I see it as a security flaw in Chrome.
But what’s the fix?
There’s a trade-off,
between maximizing screen space on one hand,
and retaining trusted screen space on the other.
One compromise would be for Chrome to retain a small amount of screen space
above the “line of death”
instead of giving up literally all screen space to the web page.
Chrome could use this space to signal that
“the URL bar is currently collapsed”,
e.g. by displaying the shadow of an almost-hidden URL bar.
Want to build a fantastic product using LLMs? I work at Granola where we're building the future IDE for knowledge work. Come and work with us! Read more or get in touch!
TigYog
Kickabout