The most common protection methods against Cross-Site Request Forgery (CSRF) attacks are anti-CSRF tokens. A CSRF attack is where unsuspecting authenticated users submit malicious requests unknowingly to the web app. Attackers leverage CSRF attacks to gain access to sensitive information, transfer funds, tamper with passwords and email ids, take over accounts, and so on. This article discusses how web apps can use anti-CSRF tokens to protect themselves from these attacks.

Anti-CSRF Tokens: The Basics 

Anti-CSRF tokens are related pairs of tokens given to users to validate their requests and prevent issue requests from attackers via the victim.

Each token contains a unique, unpredictable, secret value that is not guessable by a third party. Since it is impossible for attackers to determine or predict the value of the CSRF token, they cannot completely construct a valid HTTP request with all necessary parameters to honor the request from the victim user end. This is how they prevent CSRF attacks from happening.

Using Anti-CSRF Tokens to Secure Web Apps 

Synchronizer Token Pattern 

Synchronizer token pattern is a commonly used token-based cross-site request forgery protection technique. Here, anti-CSRF tokens are generated by the server-side application and transmitted to the client-side in a way that is included in the subsequent HTTP request made by the client.

When the user sends a request, the server-side application verifies and validates the request to ensure that the expected token is included. If the relevant token is not included, the server-side application rejects the request. So, only original users are authenticated to send requests in a given session.

The following best practices should be followed in generating and validating tokens.

• A non-predictable, well-established random number generator with enough entropy must be leveraged to generate unique tokens.
• The tokens must be kept secret and handled securely throughout the lifecycle.
• One effective transmission method is to transmit the token within a hidden field of an HTML form.
• • The field with the anti-CSRF token must be placed at the earliest possible instance within the HTML document for stronger security.
  • It must be placed before non-hidden input fields and locations that allow user-controllable data embedded within the HTML.
  • This way, the web app is protected against several CSRF techniques that manipulate the HTML document and capture its content by crafting data.
• The tokens must have a short expiry period not to be reused.
• The tokens must not be transmitted within cookies for stronger CSRF protection.
• Safe ways such as compare hashes must verify the anti-CSRF tokens.
• Token should not be sent in HTTP GET requests to ensure that they aren’t directly available in the URL or that they don’t leak in the Referrer header.

CSRF Protection for Each Request 

Anti-CSRF tokens can be generated once per session or for each request. Per request tokens are more secure than per-session tokens as they provide attackers a shorter timeframe to exploit the tokens. So, in scenarios where a higher level of protection is necessary, tokens are generated for each session. As soon as it is verified, the token is invalidated.

Despite the simplicity in implementation, this method has some serious drawbacks.

• It erodes user experiences as they will not operate using multiple tabs. The flow gets interrupted/ broken when the back button is used.
• It may affect the server performance, especially when high traffic volumes. This drawback can be averted if less resource-intensive random number generators are used.

Anti-CSRF Tokens for Specific Forms

The synchronized token pattern method generates anti-CSRF tokens per session verified by each form. When web apps need an added level of protection, they may be configured to generate tokens for each form. To ensure that the tokens aren’t exposed to the browser, they are typically hashed with the form’s filename. The hashes will only match if the token and the current form are valid.

Non-Persisted Tokens

Server capacity is limited, and organizations would want to avoid persisting tokens as it would cause web servers to store lots of information. This is especially costly for web apps busy with high traffic volumes. To overcome these challenges, non-persisted tokens are used. These cryptographic tokens do not require the web app to store anti-CSRF tokens in the server sessions. The only drawback with this method is that encryption consumes more resources than random number generation.

Anti-CSRF for Login Forms

Though user impersonation may not be possible until they are logged in, users could be tricked into logging in as attackers without CSRF protection. So, anti-CSRF is necessary when the user is logged in and even for login forms.

The Way Forward

Anti-CSRF tokens, though highly effective, can be bypassed under certain circumstances. So, they must be used in combination with other CSRF prevention techniques and a robust web security solution like AppTrana to fortify your security posture.