Cross Site Request Forgery – Explained in detail

What is so cross-site about Cross Site Request Forgery? What kinds of forgery can be committed using XSRF?

When a user is tricked, by whatever method, to load a URL of the attacker’s liking and the request is processed by the website in question, cross site request forgery is said to have taken place.
 
To explain in greater detail:
 
Let us take the most famous example associated with XSRF – The fund transfer scenario.
1) V is currently logged on to somebank.com website
2) The somebank.com website is vulnerable to XSRF
3) A sends V a link to a website with the latest deals in Fashion. V visits this website which has a 0 size image like so:

4) V visits the website which promises exciting deals. The request above, gets triggered and is sent to somebank.com and the fund transfer is successful.
 
Of course, this is a simplistic depiction of the attack since most banks use a OTP or two factor authentication to effect fund transfer these days.
 
XSRF can be used to:
a) Take over an administrative account (An admin is tricked into adding another admin account)
b) Add a user to a website
c) Change password
d) Post a message to a victim’s social media page/ wall, add the attacker as a friend
e) Rig voting process etc.
 
In real terms, the list is endless.
 
But, the key success factor for any XSRF attack is that the web application performs a critical action based only on the session cookie. Session cookies are common to the browser (and not just the particular tab) and therefore, in the above example, even though V was browsing the fashion deals website on tab T2 and the bank was open on tab T1, the session cookie gets sent to the bank website which bases its fund transfer decision on the receipt of the correct cookie.
 
In order to protect your website from such an attack, in addition to the session cookie, a random value may be embedded in a page by the website. Whenever a user request comes in, the website should check the correctness of both the session cookie and the random embedded value. If both these match, the website can assume that the request has indeed come from the user i.e. the user intended to perform the action.
 
The way in which the user can protect himself from such attacks is to log off from critical websites (banks, shopping etc) before visiting other sites.