Cross-site Request Forgery (CSRF / XSRF) is a type of attack that occurs when a victim’s web browser is forced to perform an unwanted action, on a trusted site, while the user is authenticated by a malicious site, blog, email, program, or instant message.
For most sites, browser requests automatically include any credentials (session cookie, Windows domain credentials, IP address etc.) associated with the site. As such, the site is unable to differentiate between a legitimate or forged request sent by the victim.
Attackers executing CSRF attacks have no way of seeing the response to the forged request, since the target of the attacks are transient i.e. state-changing requests. However, when paired with a social engineering attack on an administrative user, this method can devolve into full application compromise.
CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response of the forged request. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or making a purchase with the user’s credentials.
CSRF attacks typically comprise two actions: tricking the victim into clicking a link or loading page by social engineering or phishing, then sending a legitimate-looking, crafted request to the website from the victim’s browser. The attacker is able to send the request with values, including cookies the website associates with the victim, meaning the website presumes the victim can execute certain actions on the site.
The following neatly exemplifies the application of the term ‘cross-site’ in this attack:
A user logs into
www.vulnerablebank.comusing forms authentication.
The server authenticates the user. The response from the server includes an authentication cookie.
Without logging out, the user visits a malicious web site, e.g.
www.attackerwebsite.com. The malicious site contains the following HTML form:
<form action="https://www.vulnerablebank.com/api/account" method="POST"> <input type="hidden" name="action" value="pay"> <input type="hidden" name="amount" value="1000"> <input type="submit" value="Click Me"> </form>
Notice that the form action posts to the vulnerable site, not to the malicious site. This is the ‘cross-site’ part of CSRF.
The user clicks the submit button. The browser includes the authentication cookie with the request.
The request runs on the server with the user’s authentication context and can do anything that an authenticated user is allowed to do.
A number of code patterns that prevent CSRF attacks exist, and more than one can be applied at the same time as part of a defence in depth security strategy.
Developers should require anti-forgery tokens for any unsafe methods (POST, PUT, DELETE) and ensure that safe methods (GET, HEAD) do not have any side effects.
Developers should consider implementing a Synchronizer Token Pattern:
A random token is generated server-side upon successful authentication and associated with the user’s session. The token is returned to the user as part of an HTML response (e.g. a hidden field in a form or retrieved by AJAX).
When the user needs to perform a sensitive operation, the token is included in the request. The application verifies the correctness of the token, and then performs the requested action only if the token in the request matches the token stored in the user’s session.
If maintaining the state for a CSRF token at the server side is problematic, developers can adopt the Double Submit Cookie Pattern. This is an easy to implement, stateless alternative that assigns a random value to both a cookie, and a request parameter, with the server verifying if the cookie value and request value match:
- The client requests an HTML page that contains a form.
- The server includes two tokens in the response. One token is sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary cannot guess the values.
- When the client submits the form, it must send both tokens back to the server. The client sends the cookie token as a cookie, and it sends the form token inside the form data.
- If a request does not include both tokens, the server disallows the request.
If the origin header is present, developers should verify that its value matches the target origin. Unlike the Referer, the Origin header will be present in HTTP requests that originate from an HTTPS URL.
If the origin header is not present, developers should verify that the hostname in the Referer header matches the target origin. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state, which is required to keep track of a synchronization token.
Importantly, developers should enforce User Interaction based CSRF Defense:
- Re-Authentication (password or stronger)
- One-time Token
Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality.