Re: [WEB SECURITY] Interview With Jeremiah Grossman on ClickJacking attack

["Ivan Ristic" <ivan.ristic@xxxxxxxxx>]

On Sat, Oct 11, 2008 at 7:32 AM, Bil Corry <bil@xxxxxxxxx> 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
>> JavaScript, then the attack can still work.
>>
>> 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 now I'm brainstorming a bit because relying on framebusting (which in turn relies on JavaScript) doesn't seem like a great solution.  You'd have to force users to turn on JavaScript by making your site unusable unless it's turn on, in which case maybe framebusting might be a solution assuming the IE issue (and others?) is fixed.
>
> 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:
>
>        http://site.tld/action
>
> It'd become:
>
>        http://site.tld/dR4tl7/action
>
>
> 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.)


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

That (re-authentication) can be defeated in many cases when users
instruct their browser to remember login credentials, in which case
one click is all it takes to log in. So, preventing browsers to
persist login credentials should be added to the list of things to do.


> Thoughts?

It is also possible to monitor the referrer, and refuse to serve
requests that either don't have it or whose referrers are elsewhere.
This can be done only on the pages that are deemed private (deep
linking), otherwise simple linking would be broken. Such requests
could be redirected to the home page. Assuming there is no direct link
to the private pages on the home page (as you've discussed above) that
should be reasonably safe. Only those users who block the referrer
information would be in trouble, because they wouldn't be able to use
the site any more. Does anyone have any reliable information as to how
many users could be doing this?


> - Bil
>
>
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>



-- 
Ivan Ristic

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA