Cross-site request forgery

The XSS attack tricks the browser in running the script and performs an unwanted action on behalf of the innocent victim; the cross-site request forgery attack (CSRF) is a similar sort of flaw where the attacker makes the innocent victim perform some action but without the use of the script. The target of the malicious action is the web application in which the victim is currently authenticated.

Although CSRF and XSS seem similar, there are some distinct differences. In a CSRF flaw, the attacker takes over the identity of the victim and performs actions on their behalf. The CSRF attack is often used to change the details of the user on the vulnerable website such as email address, phone number, and address.

Note

Cross-site request forgery attack is also known as one-click or session riding attack.

Here's a simple example:

  1. Attacker identifies a direct link on a vulnerable bank application to transfer money as follows:

    http://vulnerablebank.com/transfer.do?acct=ROGER&amount=100

  2. The innocent victim has an account on the vulnerablebank.com website and is currently authenticated on it.
  3. The attacker tricks the victim into opening the modified URL, changing some variables using a phishing attack or storing the link on a blog or a forum.

    The modified URL transfers 100 from the account of the currently logged in user to attackers account as follows:

    http://vulnerablebank.com/transfer.do?acct=ATTACKER_ACCOUNT&amount=100

  4. The vulnereablebank.com web application does not verify if the user indeed wanted to perform the desired transaction. The request gets completed and the account of the attacker is increased by 100.

The web application is again the culprit in CSRF flaw, as it blindly accepts new requests coming from an authenticated browser. During any critical transactions, such as balance transfer or change of personal details, the web application should prompt the user to re-enter the credentials or at least implement a CAPTCHA. Using random tokens, known as Anti-CSRF tokens that change on every request, is also a good mitigation step as the attacker would not know this dynamically changing random token.