What you need to know about Cross Site Request Forgery

Web sites are vulnerable to Cross-Site Request Forgery (CSRF) when they fail to check the user’s intention when a request is submitted. If a user authenticates to a web site but fails to log off (as most people do), the session might still be active and thus susceptible to tampering actions. The classic example of CSRF is a user logging into a bank account, navigating to a hacker controlled page, and that page requesting money to be transferred from the user to the hacker. Any submission that allows the underlying data to be modified is subject to this attack vector if the action is not authenticated and protected. It could range from something as trivial as changing a comment on a wiki to something as devastating as performing financial transactions. The impact is only limited to the attacker’s imagination and the application’s purpose.

Social media sites and DVD rental companies have seen successful attacks in their environments as well. Single Sign-On (SSO) makes this issue problematic for more and more websites, even intranet ones where the potential risk is even greater.

Attackers will often attempt to trick an end user into submitting malicious requests. The attacks may come via phishing, emails or documents with hidden scripts or macros, or polluted web servers. Once the attacker has duped the user, the impact of the attack is directly correlated to the user’s privileges. Low level users may sacrifice their own resources, but everyone could be affected if administrative users fall victim to the attack.

The MITRE article for CWE-352: Cross-Site Request Forgery (CSRF) recommends using OWASP CSRFTester as a complement to manual code review, penetration testing, threat modeling, and other time consuming activities which only yield partial success. Since an understanding of the underlying business logic is required, CSRF removal can be very costly. OWASP has a complementary protection tool called CSRFGuard to help add securely generated random tokens to address the issue. Although many modern frameworks have CSRF protection capability, you must have direct access to the web application’s source code to leverage them or embed OWASP CSRFGuard directly in the application.

BrixBits Security Analyzer uses OWASP CSRFGuard to help mitigate the problem. Security Analyzer allows administrators to embed the token without having to modify the underlying code. CSRF exploits can be detected and blocked. To further protect production applications, Security Analyzer can also add prevention tokens to the user’s session, with a great deal of granularity to optimize performance and minimize configuration complexity.