With cross-site scripting (XSS) and SQL injection getting most of the Web security attention these days, it may seem like nothing else matters. Obviously there's a slew of Web weaknesses we can't ignore. However, one weakness in particular that we don't hear much about can create just as many problems: cross-site request forgery (CSRF).
CSRF is one of those "mysterious" flaws that, like XSS, started to appear a few years ago, but it's actually pretty simple to understand. Think of CSRF as just the opposite of XSS, where there's an exploitation of the trust a Web application has for a user, rather than an exploitation of the trust a user has for the application.
Here's what you can do right now to uncover CSRF flaws in your environment:
- Understand the vulnerability so you'll know what you're up against and what to look for. Although it's essentially the opposite of XSS, CSRF is a little more complicated.
- Assemble your toolset. You'll want to start your search for CSRF using a good Web vulnerability scanner such as HP's WebInspect or Acunetix Web Vulnerability Scanner. These tools can turn up CSRF flaws you'd be hard-pressed to find otherwise.
- Scan your systems as an untrusted outsider and a trusted user. The code, communication sessions, and business logic in front of and behind your login mechanism can facilitate CSRF so you need to let the scanner look at things from every angle possible.
- Focus on your highest value systems first such as e-commerce and online banking. Unlike XSS in many cases, the premise of CSRF targets applications that process and store valuable or sensitive information. This drives the attacker's motivation for ill-gotten gains.
- Check for XSS using your Web vulnerability scanner as CSRF can be distributed and executed in that fashion like in the Samy worm case.
- Manually analyze how your code manages and interprets user identities and sessions. Are users kept in the loop and required to authorize certain actions such as adding or removing items from a shopping cart, transferring money, and so on? More specifically does the system simply look for a cookie or a valid URL? Are static URLs and POST requests blindly accepted? Are sessions handled by the browser, and thus, easy to follow/decode? Are referrers in the HTTP header validated to ensure requests are not originating from authorized sites? Are the input values required for session manipulation easily-guessed? Can remote (cross-domain) images be displayed? All of these can facilitate CSRF attacks.
CSRF can actually be pretty difficult to exploit but don't let that discourage you from testing for it. An attacker may have an account on your system or gain access via another user's compromised login credentials. When you factor in the number of unsecured – and under-secured – wireless networks out there combined with the widespread usage of weak online passwords, this is not unreasonable. Once the attacker can get in and see how the application works, he can determine how to manipulate not just one, but all, of your user accounts.
About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored or co-authored seven books on information security including the ethical hacking books, Hacking for Dummies and Hacking Wireless Networks for Dummies (Wiley). He's also the creator of the Security On Wheels IT security audio books.