Question

Suppose my web app is protected against a CSRF attack with a CSRF token, and, in addition, it uses SSL and is protected against XSS attacks. Also, for the purposes of this question, suppose it's used only from recent browsers and that they have no bugs. I can protect against frame-based clickjacking with an X-Frame-Options:Deny header, but I don't see what additional protection it would be providing, as any frame-based form submission would be lacking the CSRF token. (And the same-origin policy prevents the CSRF token from being discovered by the attacker's JavaScript.) Questions:

  1. Is there some other kind of clickjacking that's not frame based? (I.e., is an X-Frame-Options:Deny not a complete clickjacking defense?)

  2. In the absence of an X-Frame-Options:Deny header, is it still possible for a clickjacking attack to succeed given the above assumptions?

(I'm asking this not because I want to prevent frame-based clickjacking, because I do include the X-Frame-Options:Deny header. Rather, I'm trying to understand how the scope of clickjacking attacks.)

Was it helpful?

Solution

Doing some more research, I think I have answered my own question: The overlaid, transparent iframe holds the site to be attacked, accessed normally. For example, it might be a page with a button to delete photos, emails, etc. The visible page, from the attacker's site, is something else entirely, perhaps for entering a contest, with a button positioned exactly where the iframe button is. So, this is not a case of CSRF, because the form submitted is not a forgery; it's real in every way, and hasn't been altered.

The solution is to disallow the site from being loaded into a frame, which is what X-Frame-Options:Deny does.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top