To gain an understanding of what a Cross-site Request Forgery (CSRF) vulnerability is, please see the article entitled: “What Is Cross-Site Request Forgery?“.
For insights into how to detect Cross-site Request Forgery (CSRF) vulnerabilities within web-applications, see the article entitled: “How To Test For Cross-Site Request Forgery“.
Cross-Site Request Forgery
For the purposes of this explanation, we will assume that you have either detected a critical transaction that has been determined to be vulnerable to Cross-site Request Forgery (CSRF) attack, OR are in the process of developing a critical transaction and wish to avoid the problem. We will refer to the subject HTTP request as the “transaction under consideration”.
Recall from “What Is Cross-Site Request Forgery?” that exploitation involves an attacker tricking an authenticated end-user into submitting an HTTP Request representing a critical transaction. Preventing Cross-site Request Forgery (CSRF) is as simple as making sure the application verifies that the transaction under consideration actually came from the client application and not a link outside the application.
The Solution
The solution is simple: generate a (cryptographically strong) random code on the server and store it in the user’s session. Whenever a page associated with a critical transaction is produced, include the secret code in a manner that will be provided in the HTTP Request WITHOUT USING A COOKIE. Verify the secret code against the value stored in the session when the request is received, and reject the request if the code is missing or does not match. This ensures that the request was submitted by the client-interface because an attacker is unaware of the value of the secret code.
Using a Hidden Field
In the simplest (and most common) case, the transaction under consideration is the result of a form that the end-user must complete and submit. The solution is to include a hidden field within that form that contains the secret code that is submitted with the form and verified by the application when the request is received.
Using a URL Parameter
Another design scenario would be a standalone button that must be protected. This could be accomplished by building the secret code into the button’s “action” URL as a query parameter value that would be verified by the application when the request was received.
Using an HTTP Request Header
Another potential approach would be to add the secret code to the HTTP Request Header.
Variations
A slight variation on the approach would be to generate the secret code more frequently than once per session. This would be advised in the design scenario in which the secret code appears within URLs. It is also worth noting that some development frameworks automatically provide anti-CSRF tokens in their forms. It is worth investigating whether a turn-key solution is available in your development environment before you “roll your own” solution. Fameworks that include anti-CSRF support include:
- ASP .NET
- Spring
- Struts
- OWASP
- PHP
The Non-Solution
Notice that cookies are NOT a viable solution for transferring the secret code because it would automatically returned with every request to the application, defeating our purpose in trying to thwart the CSRF attacker.
Resources
Additional details on the problem and other solution approaches can be found in the OWASP XSRF Prevention Cheatsheet.
Summary
In short, Cross-Site Request Forgery (CSRF) is not difficult to prevent and there are several viable approaches. The challenge often turns out to be awareness of the problem and identifying the critical transactions within the application.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.