We hear about SQL injection and Cross-Site Scripting constantly – but there are eight other high-risk vulnerabilities we need to be aware of, just in the OWASP Top Ten. One of those eight is yet another one to keep your eyes out for: Cross-Site Request Forgery, normally shortened as CSRF or XSRF.

CSRF is widespread in today’s web apps, OWASP says, and can cause some major damage when exposed in an app that deals with money or data. Just how much damage? The most powerful CSRF attack is most likely this attack discovered against uTorrent in 2008, which would have given an attacker complete control over a victim’s system using a record three CSRF attacks in a row. And while most CSRF attacks aren’t as damaging as that one, they can do damage, given an opportunity in a data-rich web application.

So whether you’re a developer, tester or security maven, here’s why you need to pay attention for CSRF vulnerabilities in your web apps.

What is a CSRF attack?

At the most basic definition, Cross-Site Request Forgery attacks occur when a user is made to execute an action that the user is completely unaware of. Preying on the trust an application has for a user that is logged on, an attacker tricks the user into submitting an HTTP request on the attacker’s behalf, which the application believes to be from the user. The user is both the victim and unwitting accomplice in CSRF attacks – and will most likely never know what hit them.

“The key to understanding CSRF attacks,” Bill Zeller of the Freedom to Tinker blog says, “is to recognize that websites typically don’t verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user.”

Browsers don’t allow reading across sites; for example, this blog can’t read content on pages you may have open in other tags. However, form submissions across sites or domains are allowed. It’s through that security loophole that the CSRF attack is possible in the first place.

At the heart of the vulnerability is a “confused deputy problem,” which happens when a web browser isn’t able to properly validate a web app user that is logged in.

This allows an attacker to code a bit of JavaScript on a separate malicious web page and, with a bit of social engineering, get the victim to click on the malicious link. Once the victim has visited the site, the JavaScript is triggered and the browser is forced into sending HTTP requests, authenticated by the victim/user. The attacker needs you to be authenticated into a certain web site for you to be vulnerable to this attack – but if you are authenticated, the game is on.

Learn better through video? Check out Computerphile’s video on CSRF:

Anatomy of a CSRF Attack

If you’re less familiar with the concept of authentication, cross-site request forgery can be a bit hard to swallow – thus, here’s an example of a very simple attack using an HTTP GET request, with visuals:

You log into your banking app at www.vulnerablebank.com Vulnerablebank.com authenticates you and you remain logged in The attacker, believing you to be logged in at vunerablebank.com, sends you a malicious link via email or social media, which you click The malicious site, using a bit of JavaScript hidden in an image source, submits a request to the bank (masked as a request by you) to transfer an amount of money into the attacker’s bank account.

The bank app, without re-authenticating, automatically validates the transaction because the victim is logged in and the request appears to be coming from them. Pwned by CSRF!

How to Prevent CSRF Vulnerabilities

Luckily, detecting cross-site request forgery flaws are easily prevented – once you know what you’re looking for. With the proper use of CSRF tokens, along with source code analysis to ensure all state-changing actions are protected, along with two-factor authentication where possible, CSRF vulnerabilities can be completely eradicated.

CSRF tokens, for the uninitiated, are client-side mechanisms used to make each request unique for the user. When the token is verified on the server-side, the request is validated, and because the app creates a new token each time any page is served to anyone, the request could not be forged.

Besides source code analysis and tokens, sensitive applications – such as the bank site in the example above – should also log users out after certain amounts of time and offer users a two-step verification process upon log-in, though this is not a complete solution.