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.
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.
Learn better through video? Check out Computerphile’s video on CSRF:
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:
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.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.