Cross-Site Request Forgery ¶
Cross-Site Request Forgery (CSRF) is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.
The premise for these attacks involves tricking (or simply asking) a user's browser into sending a request to a website without user intervention. For example, an img tag's src attribute can reference an arbitrary URL. Requests like this are often legitimate for loading dynamic content off another site or from a CDN. One issue here is that such requests are sent with any cookies for the target domain. Users are most commonly authenticated by cookie, so these requests are authenticated. If the application is not careful to verify that a request actually came from a human, it may take action that the user did not actually request.
To guard against CSRF attacks, developers should use randomly generated, session-unique challenge tokens in requests for sensitive operations. These challenge tokens are inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier.
See the OWASP wiki page on CSRF for more details on the attack, and the CSRF cheat sheet for more details on prevention.
Software¶
GET vs POST¶
Note:
In order to properly protect against CSRF attacks, you must first ensure that your application does not allow HTTP GET requests to change state on the server. Operations such as executing transactions, changing user data, etc. should be executed as HTTP POST requests. This alone does not protect you, but it is an important first step.
The idea that HTTP GETs should not change state is a critical one when it comes to CSRF. To secure GETs that change state, an application must include a CSRF token in the request string. This can potentially leak the token in multiple places: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referrer headers if the protected site links to an external site.
-
Wiki content is available under a Creative Commons 3.0 License.
