[WEB SECURITY] Interview With Jeremiah Grossman on ClickJacking attack
ivan.ristic at gmail.com
Thu Oct 16 07:25:53 EDT 2008
On Thu, Oct 16, 2008 at 12:06 PM, Ivan Ristic <ivan.ristic at gmail.com> wrote:
> On Sat, Oct 11, 2008 at 7:32 AM, Bil Corry <bil at corry.biz> wrote:
>> 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.
>> (from: http://ha.ckers.org/blog/20081007/clickjacking-details/)
>> ----- 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:
>> It'd become:
>> With the token in the URL, there is the possibility of leaking the token via the referer, server logs, etc.
> Yes, but using two different tokens/session IDs (one for the session
> cookie, the other in the URLs) would make such leakage irrelevant. (As
> a bonus, it would also defend against CSRF in general, although I
> prefer one time/per-action tokens.)
It should be noted that URL tokens won't work in situations where the
attacker can introduce a link that originates in the target web site
(and leads to his own site), which would enable him to obtain the
per-session URL. Considering this is one of the best ways to initiate
Clickjacking and CSRF attacks (it also ensures the user is logged in
at the time he arrives to the malicious web site), it greatly reduces
the effectiveness of URL tokens.
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