Cross-Site Request Forgery (CSRF)

OWASP Top 10 2013 - A8




What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.


Example of a Cross-Site Request Forgery attack

In order for perform a Cross-Site Request Forgery attack, the victim must be authenticated with the target website. The attacker includes a script in a third-party website that the victim visits. When the victim visits that website, the script will be executed without the victim noticing. For example, in a car forum, an attacker posts a message which contains a script which performs transfers in the victim's bank (target website).


        <div style="display:none;">
        <iframe id="frame" name="frame"></iframe>

        <form target="frame" id="formid" action="http://www.mybank.com/transfer" method="post">
          <input type="hidden"
              name="toAccount"
              value="55555555555555555555"/>
          <input type="hidden"
              name="amount"
              value="666"/>
           <input type="hidden"
              name="fee"
              value="5.0"/>
          <input type="hidden"
              name="description"
              value="EVIL ACCOUNT"/>
          <input type="submit"
              value="View"/>
        </form>

        <script>
        document.getElementById("formid").submit();
        </script>
        </div>
        

Even if HTTP POST is disabled, the same attack could be performed with HTTP GET request.

<img src="http://www.mybank.com/transfer?toAccount=55555555555555555555&amount=1000000&fee=5&description=EVIL">
        



How to prevent Cross-Site Request Forgery (CSRF)

How do I prevent Cross-Site Request Forgery attacks?

Use Synchronizer Token Pattern

Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as "form keys".

Risk Covered by Hdiv Protection (RASP)

  • Hdiv automatically adds a random token to all URLs and forms.
  • Hdiv offers an extreme security level adding a new random token per request. Many frameworks have or are starting to include this type of protection "built-in" to every form but this protection level is not enough. Applications developed with these frameworks remain vulnerable because the random token generated by them is per session and not per request as with Hdiv.
Since 2008 in productionSINCE 2008IN PRODUCTION
more than 128 countriesMORE THAN 128COUNTRIES
Fortune 500 companiesFORTUNE 500COMPANIES



Resources

WHITEPAPER

The 7 Key Factors to Successful DevSecOps

Download Now

VIDEO

Hdiv Detection (IAST) for Developers

Watch

VIDEO

The Best Protection Against OWASP Top 10 Risks

Watch

AGILE PROTECTION

Agile protection: above and beyond the WAF

Read More