The Open Web Application Security Project (OWASP) has released their top 10 web security risks and number eight is cross-site request forgery (CSRF). This problem exists because web apps typically accept requests in a standardized way, which can easily be forged by attackers.
CSRF can be exploited via email or a malicious website and cause a user to make changes they did not intend, such as updating personal data, posting bad content, or even initiating false transactions.
OWASP outlines cross-site request forgery as follows:
Defining the Problem
Most websites use a standard URI for forms. For example, a social networking site might post a comment using the following URL (disclaimer – URLs are not encoded):
https://www.my-social-site.com/user/post?comment=TIL how to prevent CSRF attacks!
If an attacker notices this is the standard way to post a comment, they could craft the following malicious request:
https://www.my-social-site.com/user/post?comment=Goto this awesome site http://bad-site.com
The attacker could then use cross-site scripting (XSS), a malicious website, or a bugged email to tell your browser to submit their malicious request to the social networking site. If you are currently logged into the social networking site you would end up posting the malicious comment the attacker created.
Fortunately, the requirement for a user to be currently authenticated lowers the success rate of these types of attacks for most sites. However, websites with users who are “always online,” such as email providers and social networking sites, should pay special care to CSRF, as they are most likely to be targeted by attackers.
Detection & Prevention
Detection of a CSRF vulnerability is fairly trivial. First, capture a request that is being made while logged on as a user of your site. Then attempt to replay the same request while logged in as a different user. If the second request succeeds, that request is vulnerable to CSRF. OWASP created the CSRF Tester tool to assist in the detection of this vulnerability. Additionally, many automated web security and PCI compliance testing toolkits provide automated testing for CSRF vulnerabilities.
For prevention of CSRF attacks, OWASP outlines three primary methods to help guard your site: synchronizer token pattern, header verification, and challenge-response.
The Synchronizer Token Pattern
The synchronizer token pattern prevents CSRF by requiring a random, user specific token be added to the request for it to complete successfully. Typically, this token is generated when the user first creates their session and is stored as session data on the server (not as a cookie). When the server generates the form for the user to fill out, this token is added as a hidden input that will be returned to the server for verification when the user submits the form. This method prevents CSRF because the attacker cannot create a valid forged request without knowing what the secret token value is for that particular user.
The synchronizer token pattern is the recommended solution to CSRF by OWASP because it is transparent to users, but attackers will know there is CSRF protection when it is used. This pattern is only successful as long as attackers cannot determine a user’s token; therefore, it is important that this token is sufficiently random and kept secret. The token pattern is no longer effective if the website is vulnerable to XSS because the attacker can utilize XSS to load the user’s token and submit the token with the forged request.
Header Verification
Header verification is the simplest and weakest form of CSRF protection recommended by OWASP. Because CSRF attacks rely on attackers tricking a user’s browser in to sending an authenticated request to the server, attackers have no way of spoofing any header or cookie information. For this reason, validating that the referrer in the header is your website is a valid way to prevent CSRF. This can be useful when you don’t want to have to keep track of a user’s state. However, because the synchronized token pattern is more visible to attackers and header verification can be exploited via an open redirect vulnerability or XSS, the synchronized token pattern is the preferred method.
Challenge-Response
Challenge-response is another method of CSRF protection recommend by OWASP. This method involves requiring a verification step by the user before an action is completed. Some examples of challenge-response include: captcha, password verification, or a one-time use token. This method is considered the strongest form of CSRF protection (if properly implemented) because it does not allow an attacker to perform an action without the user’s confirmation. Additionally, this is the only method of CSRF protection that is not vulnerable to XSS. However, this method does interrupt the user experience and is not easily implemented as a site-wide solution. For this reason, it is recommended that the challenge-response method is only used when the highest level of security is required.
All of the methods above are for protecting any particular page on your site from CSRF, but how do you ensure your whole site is protected from CSRF? At Credera, we have a couple steps we recommend to ensure your site is protected from CSRF.
First, check whether or not the framework you are using has built-in CSRF protection support. Many web application frameworks such as WordPress, .NET MVC and the Spring Framework have native or plugin support for CSRF protection. Using a framework-supported CSRF solution is recommended because it is likely to be tested and patched by the many users of the framework.
If your framework does not have built in support for CSRF, the next best resource it to look at OWASP’s CSRFGuard project. The CSRFGuard project provides solutions for CSRF protection for Java Servlet, .NET, and PHP. Even if you’re using a technology not covered under the CSRFGuard project, you can use the implementations of CSRFGuard as an example of how to properly implement CSRF protection.
Finally, ensure all of your state-changing business logic follows the proper usage of HTTP verbs. According to the HTTP Spec, the GET method should only be used to retrieve information. Therefore, any requests that are making changes to state should use one of the other HTTP verbs, PATCH, POST, PUT, and DELETE. By following proper HTTP method guidelines, you prevent leaking your CSRF token through the URL and simplify detection of CSRF vulnerabilities.
Summary
Verifying your website is protected against CSRF attacks is an important part of testing your website for possible vulnerabilities. By follow the steps outlined above, and using the tools and resources provided by OWASP, you can ensure your site will be secure against CSRF.
Be sure to follow us on Twitter or LinkedIn for more great tips. Have a question related to the blog series or web security in general? Use the comments section below to join the conversation.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
