The most common methods of protection against Cross-Site Request Forgery (CSRF) attacks are anti-CSRF tokens. A CSRF attack occurs when unsuspecting authenticated users unknowingly submit malicious requests to the web application. Attackers take advantage CSRF Attacks to access sensitive information, transfer funds, falsify passwords and email ids, take control of accounts, etc. This article explains how web applications can use anti-CSRF tokens to protect against these attacks.
Anti-CSRF tokens are pairs of linked tokens given to users to validate their requests and prevent attackers from issuing requests through the victim.
Each token contains a unique, unpredictable secret value that cannot be guessed 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 the necessary parameters to honor the victim user’s request. This is how they prevent CSRF attacks from happening.
Sync token pattern
The synchronization token model is a commonly used token-based cross-site request forgery protection technique. Here, anti-CSRF tokens are generated by the server-side application and passed 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 checks 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. Thus, only originating users are authenticated to send requests in a given session.
The following best practices should be followed when generating and validating tokens.
- An unpredictable, well-established random number generator with enough entropy must be exploited to generate unique tokens.
- Tokens should be kept secret and handled securely throughout the lifecycle.
- An efficient method of transmission is to pass the token in a hidden field of an HTML form.
- The field with the anti-CSRF token should be placed as early as possible in the HTML document for enhanced security.
- It should be placed before non-hidden input fields and places that allow the embedding of user-controllable data in the HTML code.
- This way, the web application is protected against multiple CSRF techniques that manipulate the HTML document and capture its content creating data.
- Tokens must have a short expiration period so they cannot be reused.
- Tokens should not be passed in cookies for better CSRF Protection.
- Safe means such as hash comparison should verify anti-CSRF tokens.
- The token should not be sent in HTTP GET requests to ensure it is not directly available in the URL or leaked in the Referrer header.
CSRF protection for every request
Anti-CSRF tokens can be generated once per session or per request. Per-request tokens are more secure than per-session tokens because they provide attackers with a shorter timeframe to mine the tokens. So in scenarios where a higher level of protection is needed, tokens are generated for each session. As soon as it is verified, the token is invalidated.
Despite the simplicity of implementation, this method has serious drawbacks.
- This erodes user experiences as they will not work with multiple tabs. The stream is paused/broken when the back button is used.
- This can affect server performance, especially when traffic volumes are high. This drawback can be avoided if less resource-intensive random number generators are used.
Anti-CSRF tokens for specific forms
The synchronized token model method generates per-session anti-CSRF tokens checked by each form. When web applications require an additional level of protection, they can be configured to generate tokens for each form. To ensure tokens are not exposed to the browser, they are usually hashed with the form’s filename. The hashes will only match if the token and the current form are valid.
Server capacity is limited and organizations will want to avoid persistent tokens as this would require web servers to store a lot of information. This is especially costly for busy web applications with high volumes of traffic. To overcome these challenges, non-persistent tokens are used. These cryptographic tokens do not require the web application to store anti-CSRF tokens in server sessions. The only drawback of this method is that the encryption consumes more resources than the random number generation.
Anti-CSRF for login forms
Although impersonation is not possible until they are logged in, users may be tricked into logging in as attackers without CSRF protection. Thus, anti-CSRF is needed when the user is logged in and even for login forms.
The path to follow
Anti-CSRF tokens, while very effective, can be circumvented under certain circumstances. Thus, they should be used in combination with other CSRF prevention techniques and a robust web security solution like Trana app to strengthen your security posture.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitterand LinkedIn.
The post How to protect your web applications using anti-CSRF tokens? appeared first on Indusface.
*** This is a syndicated blog from the Indusface Security Bloggers Network written by IndusfaceCMS. Read the original post at: https://www.indusface.com/blog/how-to-protect-your-web-apps-using-anti-csrf-tokens/