Briefly, what is CSRF?
CSRF stands for cross-site-request-forgery. It is an exploit of a website where an attacker constructs a request and has a victim execute it on the attacker’s behalf. In the past few years, a flurry of major CSRF attacks has thrust this type of exploit into the limelight yet many applications still do not protect against it.
In this post, I won’t go into how to defend against CSRF attacks, but instead review several solutions I’ve come across and provide some of my own opinions for them. For a better description of the CSRF exploit and how to prevent it, here are some really good articles for you to read:
Custom Solutions
With CSRF attacks in mind, it actually takes little additional development cost to integrate a CSRF defenses into a new project. One of the simplest ways to prevent most CSRF related exploits is to append and validate a security token to every request made to your application.
At the basic level, all CSRF libraries must accomplish the following 3 actions:
- Generate a token (per session or request) and store it in the session.
- On each request, validate the token sent by the browser against the one store in the session. (probably
implemented as a filter or interceptor) - Handle user specified unguarded or landing pages.
In addition, each form on all your pages will be responsible for sending the token on submission.
Positives
Not tied to any existing CSRF library conventions or limitations. Many CSRF libraries currently available restrict the application to conventions that the application must follow. For example, some libraries restrict applications to only POST requests. This may or may not be acceptable to your client. In addition, many libraries may have crippling limitations that prevent you from using 3rd party solutions “out of the box”.
Many frameworks support the token synchronization pattern built in to prevent double submission of forms. Though it
does not provide 100% protection from CSRF attacks, it can be used as the basis to protecting your application against CSRF attacks.
Negatives
Increased development costs – Regardless of the approach, defending against CSRF attacks do increase cost of the application and developing a custom solution is typically the highest cost. That being said, the cost of retrofitting an existing application to guard against CSRF exploits is far more costly. The costs of dealing with a security breach can be significantly higher.
Non-global Solutions – Many custom CSRF solutions are “exclusive” in the sense, developers choose when to add CSRF protection to specific requests. “inclusive” solutions protect all URLs by default and developers are able to explicitly state unguarded pages. Developers tend to code pages as unprotected and them protect them later. This is highly error prone in “inclusive” solutions and can leave large portions of the application unprotected if they forget to protect them.
Missed Vulnerabilities – With a custom solution, you greatest asset (and weakness) of your CSRF defense is your team
of developers. As with other open-source libraries, open-source CSRF libraries benefit from a large community
continuously providing feedback, updating the source, and thus making the library more effective.
3rd Party Libraries
In the Java world, I’ve worked with OWSAP’s CSRF Guard library. So this will be the bases of my review on “3rd party libraries”
Positives
Provides adequate out of the box protection against CSRF guard attacks. It is a well-established library with ‘some’ community support.
Require minimal configuration to get started.
Once installed, all URLs are protected by default. Developers must specify unprotected URLs.
Negatives
By using a 3rd party library, you are tied into their conventions and limitations.
- CSRF Guard’s configuration file for defining new landing page and unguarded pages requires the context-root as part of the URL. Pattern matching for unguarded URLs is extremely limited.
- When going to the new token landing page, CSRF Guard changes the title of the browser to “new token landing page”. Not only does this expose the underlying security library, it can be a total showstopper to the client.
- Verbose logging is on by default.
Conclusion
In conclusion, CSRF Gurad provides adequate CSRF protection but there are some limitations that make it hard to work with. Custom solutions are…custom. You have to build and maintain it. Custom solutions give you the flexibility to be as tight or loose as you need but with this flexibility comes with the risk of exposing too many CSRF vulnerabilities by accident. So there you have it, as I become more exposed to additional CSRF libraries, I will continue to update this post.