XSS vs CSRF vs ClickJacking

Obviously there's tons of material out there explaining all three of those topics. So I'm not going to sit and talk about each of them in detail. This is just a short summary about all three, illustrating the key differences in one single post. I'm assuming that people who read this already have a fairly good idea about how all these 3 attacks work and just want a quick refresher. Here goes:

NOTE: It is assumed that you are logged in with a valid user account into the application, for all these attacks to be fully successful.

XSS - You have a website. The website accepts user input and processes it; either on the client or on the server. It however does not filter user input, disallowing special characters OR ensure that the content is encoded safely before displaying it on the browser. This results in attackers being able to inject their own scripts into:
a) Public pages that the whole world will see - Persistent
b) Pages that specific users will see - Reflected

The content of this malicious script results in the attacker stealing data or gaining complete control of the user's browser.. and if things work out well.. maybe the attacker's machine as well. User Interaction IS needed. Even viewing an infected website IS user interaction.

CSRF - So you now protect your website against XSS using the OWASP XSS Protection sheet. You still might be vulnerable to CSRF. If you have pages on your website which change data on your website(edit/modify/delete) check if those requests contain parameters whose values are unpredictable. If not then your application is vulnerable.

The aim of CSRF is NOT to inject scripts and steal information - like XSS. It is to make you perform an operation on your application, without you wanting to. For eg. Delete the Entire Administrators group in your application. You obviously don't want to do that.. right?

A CSRF request which is sent by an attacker is a perfectly normal request, hence the XSS defenses are not applicable here. The reason CSRF happens is because the attacker can predict the values of all the parameters in the "Delete Admin Group" request. So to protect yourself, you have to ensure that all your requests contain something that the attacker can't predict. Add a random token to all your requests. The attacker shouldn't be able to guess its value. You're then safe from CSRF.

Clickjacking - Appending a random token to all your requests, means that the attacker cant guess them. For carrying out a clickjacking attack though; he doesn't need to guess it. That's because you will voluntarily load a page WITH a valid token into your browser and then further shoot yourself by authorizing the "operation"; just like CSRF. So Clickjacking = CSRF + Nullifying CSRF defenses.

An attacker will create a page on his own website with a cleverly created IFRAME. You need to visit this page. The moment you do, the "Delete all admins page" will load inside this IFRAME. How? The attacker has coded that into the page with something like . Note that this is WITH the random CSRF token which the application assigned to that page. That's because YOU as a user were logged in and visited some random website while still logged in to the application. Since you're logged in, the application gave you that random token as well; the attacker does NOT have to craft a request like in CSRF The attacker now cleverly positions buttons on that page(his website) exactly under which are the buttons confirming "Delete all admins". So when you click a button on the attackers website, you also click a button confirming the "Delete all admins" operation.

So as you see - Despite protecting against XSS and CSRF, you could still be vulnerable to Clickjacking. Here are good reads on how to protect from all three attacks:

XSS - http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
CSRF - http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
Clickjacking - http://www.owasp.org/index.php/Clickjacking