Tokens and CSRF (Cross-Site Request Forgery)
1. Understanding CSRF (Cross-Site Request Forgery)
a. What is CSRF?
- Cross-Site Request Forgery (CSRF) is a type of attack where a user is tricked into performing actions on a web application where they are authenticated, without their knowledge. The attacker typically uses social engineering to make the user click a link or load a page that triggers a request to the target web application.
b. How CSRF Works:
- CSRF exploits the fact that browsers automatically include credentials (e.g., session cookies) with every request to a particular domain. If a user is logged in to a web application, a malicious website can create a request to that application, and the browser will automatically attach the user’s session cookie, making the request appear legitimate.
c. Potential Consequences:
- CSRF can lead to unauthorized actions such as changing account details, transferring funds, or deleting data. Essentially, any action the user is authorized to perform can be triggered by a CSRF attack.
d. Example of a CSRF Attack:
- A user is logged into their banking application. The attacker sends the user an email containing a link to a malicious site. When the user clicks the link, it triggers a hidden request to transfer funds within the banking application. Since the user is logged in, the request carries their session cookie, making the bank process the request as if it were legitimate.
2. Using Tokens to Prevent CSRF
a. Anti-CSRF Tokens:
- The most common method of preventing CSRF attacks is through the use of anti-CSRF tokens. These are unique tokens generated by the server and sent to the client along with the web form or API response. When the client submits the form or makes an API request, the token must be included, and the server verifies its validity before processing the request.
b. How Anti-CSRF Tokens Work:
- When a user accesses a form or an endpoint, the server generates a unique, cryptographically secure token and stores it in the user’s session.
- The token is then embedded in the HTML form as a hidden field or included in the request headers (for APIs).
- When the form is submitted, or the request is made, the token is sent back to the server.
- The server compares the token received with the one stored in the session. If they match, the request is valid and processed; otherwise, the request is rejected.
c. Characteristics of Anti-CSRF Tokens:
- Unique and Unpredictable: Tokens must be unique per session or request and difficult for an attacker to guess.
- Bound to the User Session: Tokens should be tied to the user’s session to prevent reuse by an attacker.
- One-Time Use (Optional): Some implementations make tokens valid for only a single request, ensuring they cannot be reused.
d. Implementation Considerations:
- Tokens should be included in all forms and API calls that perform sensitive actions.
- For Single Page Applications (SPAs) or APIs, the token can be sent in a custom header (e.g.,
X-CSRF-Token
) instead of a form field.
- The token should be kept secret and not exposed in URLs or other easily accessible places.
e. Handling AJAX Requests:
- For AJAX requests, anti-CSRF tokens can be included in the request headers. The server should check the presence and validity of the token before processing the request.
3. Relationship Between Tokens and Authentication
a. Session vs. Token-Based Authentication:
- While session-based authentication relies on server-stored sessions, token-based authentication (e.g., JWT) is stateless. However, both approaches can be vulnerable to CSRF attacks if not properly secured.
- In token-based authentication, it is common to use CSRF tokens in conjunction with cookies when the token is stored in a cookie and sent automatically by the browser.
b. Double Submit Cookie Pattern:
- In token-based authentication scenarios, a common pattern to prevent CSRF is the double-submit cookie pattern. Here, the CSRF token is sent as a cookie and as a request header. The server compares the token from both sources and processes the request only if they match.
c. JWT and CSRF:
- JWTs, when stored in cookies, are vulnerable to CSRF attacks. To mitigate this, JWTs should be stored in a secure manner (e.g.,
Authorization
header) and combined with CSRF tokens if stored in cookies.