Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Possible ClickJacking Protection?
Posted by: jamuse
Date: October 30, 2008 08:16AM

Would adding a per-page nonce in the URL protect against ClickJacking attacks? For example, say the only static URL for the app was hxxp://bank.com which returned a login screen. Every URL after that used a POST request with a per-page nonce in the URL and a seperate per request nonce in the post data. The app would terminate the session any time either of these nonces are submitted incorrectly and redirect the user to hxxp://bank.com/. Using this example, the attacker would not be able to predict any post-authenticated URLs (i.e. hxxp://bank.com/TransferFunds?RID=zx132as3) to frame, thus the best they could do is only frame the login screen.

Options: ReplyQuote
Re: Possible ClickJacking Protection?
Posted by: Anonymous User
Date: October 30, 2008 08:57AM

Yep - in several cases it would. Also frame buster turn out to be helpful again :)



Edited 1 time(s). Last edit at 10/30/2008 08:57AM by .mario.

Options: ReplyQuote
Re: Possible ClickJacking Protection?
Posted by: jamuse
Date: October 30, 2008 09:03AM

if the app isn't vulnerable to any XSS flaws, then under what circumstances would a non-predictable URL **not** provide ClickJacking protection then?

Options: ReplyQuote
Re: Possible ClickJacking Protection?
Posted by: kuza55
Date: November 01, 2008 06:25AM

jamuse Wrote:
-------------------------------------------------------
> if the app isn't vulnerable to any XSS flaws, then
> under what circumstances would a non-predictable
> URL **not** provide ClickJacking protection then?

If it was possible to get the user to navigate to the target page by clicking on links (e.g. think whack-a-mole flash games), then the attacker could get the victim there.

A safer bet would to simply put some kind of wrapper around your site that detects whether it's in a frame or not, and then only renders when it's not; trying to break out of frames only leads to the attacker winning by using anti-framebreaking code.

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

Options: ReplyQuote
Re: Possible ClickJacking Protection?
Posted by: jamuse
Date: November 01, 2008 02:32PM

I've seen the frame-breaking code suggestion, but if you can implement random non-predictable URLs (or even just a parameter) on the server, why would you want to rely on a JavaScript solution? Unless I'm missing something, an attacker can't frame a non-predictable URL, thus she can't create a link to trick the victim into clicking. Take my original example, it seems that adding a random parameter to a URL (i.e. hxxp://bank.com/TransferFunds?RID=zx132as3, where if the correct random parameter is missing then the app redirects to the login screen) would be more robust that a client side solution. Am I missing something?

Options: ReplyQuote
Re: Possible ClickJacking Protection?
Posted by: kuza55
Date: November 02, 2008 12:23AM

jamuse Wrote:
-------------------------------------------------------
> Am I missing something?

Like I said above; you still need to have a predictable URL as your home page/login page; unless you're willing to log someone out once they leave your site, or in some other way break the user interface, the user will be able to get to a sensitive page by clicking; as we've already assumed we can get the user to click on any links in your domain, all we need to do is construct a scenario (e.g. a whack-a-mole flash game) where the user will click where we want them to a number of times, at which point we will have framed the URL with the unpredictable token.

If you're willing to break your site so that once the user leaves your page, they have to login again, then sure, that solution works better than JavaScript code.

In that case you might also be interested in having a look at SessionSafe (search this forum or the internet), which goes a bit further, and restricts the user to one browsing 'stream' (i.e. from one page, you can only follow one link, you can't open up a link in a new window, then go back to the previous window), which also gives a lot of protections against all kinda of XSS attacks on the server-side; it's a bitch to implement, but we seem to have bashed the hell out of the client-side component, so that should be pretty safe to use (if you know what you're doing, of course).

Also, note that I didn't say frame-breaking code, I said frame-detection code; the two are different, namely because I can stop a site breaking out of frames in some browsers without disabling cookies or javascript or anything of the sort, mainly because you're trying to cause a change in a window I control, but I can't actively control what you do inside your iframe, otherwise I wouldn't need clickjacking, so if you check that you aren't framed before rendering anything I can't do anything about it.

[EDIT]: If you really care about this (and given you phrase this as if this was for a bank, I assume you do), it might be worth getting someone who specialises in this kind of stuff to do it for you; on a related note, a fair chunk of people on this board are infosec consultants during the day or moonlight as consultants, just saying :p

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]



Edited 2 time(s). Last edit at 11/02/2008 12:29AM by kuza55.

Options: ReplyQuote


Sorry, only registered users may post in this forum.