[WEB SECURITY] Interview With Jeremiah Grossman on ClickJacking attack
bil at corry.biz
Sat Oct 11 02:32:16 EDT 2008
Jeremiah Grossman wrote on 10/6/2008 10:26 AM:
> Another gotcha exists here as well. Internet Explorer there is
> security=restricted with regards to IFRAMES, which prevents the
> framebusting code from executing, as well as all other JS included on
> the page. So if the clickjacked targeted "button" DOES NOT utilize
> Another possible option is out-of-band confirmation by the user. Email,
> SMS, etc
I was reading RSnake's "Clickjacking Details" and took note of something he says at the end of it:
----- Quote -----
From an attacker’s perspective the most important thing is that a) they know where to click and b) they know the URL of the page they want you to click, in the case of cross domain access. So if either one of these two requirements aren’t met, the attack falls down.
----- Quote -----
So I wanted to explore those two pre-conditions to ClickJacking that RSnake pointed out in the above quote. I'm going to offer up a variety of ideas and am looking for some feedback on what might be a possible defense (if any):
Knowing Where To Click
What if the site randomize where the buttons are located on each page load?
Or how about after the button is clicked, a second randomly-placed button asks for confirmation?
Or how about the button has to be "chased down" for a second to click it? I suspect that will quickly annoy users, especially me. But it's an idea.
Others? Obviously, if you can get the victim to click incessantly, then any of these ideas can be brute-forced.
Another idea is to have the second randomly-placed button ask for confirmation, but a click anywhere outside of the "ok" ends the request. Now the attacker gets one shot to make it work. I suppose even still, the attacker could reset the page and try again so long as the victim is willing (and we all know they are).
Knowing The URL
The only way to prevent an attacker from knowing the URL would be to randomize it -- basically instead of placing the token/nonce as a hidden field (ala anti-CSRF), use it as part of the URL instead. So for example, if the URL looks like:
With the token in the URL, there is the possibility of leaking the token via the referer, server logs, etc.
And more troubling, all users must begin at a known starting page before being routed to their randomized pages. So to prevent an attacker from simply walking the victim from the starting page to the target page, the site would have to re-authenticate any user that goes to the commonly known starting page and that re-authentication page would have to be such that the user is unable to have the browser auto-fill their username and password.
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
More information about the websecurity