All you need to know about CSRF Tokens

CSRF (Cross-Site Request Forgery) tokens are a great way to prevent CSRF attacks, but what exactly are they? How do they safeguard against CSRF attacks? How should they be produced? 

 

This blog post will address the answers to these and other questions. 

 

What is Cross-Site Request Forgery or CSRF? 

 

Cross-Site Request Forgery (CSRF) is an attack that forces an authenticated end user to perform unwanted actions on a web application. An attacker can trick users of a web application into performing actions of the attacker's choosing with the help of social engineering (such as sending a link via email or chat). 

 

A successful CSRF attack can force a normal user to perform state-changing requests such as transferring funds, changing their email address, and so on. CSRF can compromise the entire web application if the victim is an administrative account.

 

Cross-site request forgery (CSRF) is a web security flaw that allows an attacker to trick users into performing actions they do not intend to perform. It enables an attacker to partially bypass the same origin policy, which is intended to prevent different websites from interfering with one another.

 

In a successful CSRF attack, the attacker causes the victim user to perform an unintentional action. This could be to update their email address, change their password, or make a money transfer, for example. The attacker may be able to gain complete control of the user's account depending on the nature of the action. If the compromised user has a privileged role within the application, the attacker may be able to gain complete control of all data and functionality.

 

Cross-site request forgery attacks use the same delivery mechanisms as reflected XSS attacks. Typically, the attacker will upload the malicious HTML to a website under their control and then lure victims to that website. This could be accomplished by sending the user a link to the website via email or social media. Alternatively, if the attack is placed on a popular website (for example, in a user comment), they may simply wait for users to visit the site.

 

Also Read | 5 Key Steps for Vulnerability Testing

 

What is CSRF Token? 

 

A CSRF Token is a secret, unique, and unpredictable value generated by a server-side application to protect CSRF's vulnerable resources. The server-side application generates and submits the tokens in a subsequent HTTP request made by the client.

 

The server-side application compares the two tokens found in the user session and the request after the request is made. If the token is not present or does not match the value in the user session, the request is rejected, the user session is terminated, and the event is logged as a possible CSRF attack.

 

A CSRF token is a one-of-a-kind, secret, unpredictable value generated by the server-side application and sent to the client in such a way that it is included in the client's subsequent HTTP request. When the later request is made, the server-side application validates that it contains the expected token and rejects it if it is missing or invalid.

 

CSRF tokens can help prevent CSRF attacks by making it impossible for an attacker to create a fully valid HTTP request that can be fed to a victim user. Because the attacker cannot determine or predict the value of a user's CSRF token, they are unable to construct a request with all of the parameters required for the application to honor the request.

 

Cross-Site Reference Forgery is also known as CSRF and, in some cases, XSRF. It is a type of fraud attack in which the user's credentials are used to enter the website and access the user's data. It is typically carried out by prompting the user to click on an unknown link or page advertisement, leading the user to deceive malware. Another method of luring a user into CSRF is to send scam links in emails or SMS and encourage them to click on the links.

 

Also Read | Network Security: Types, Advantages, and Disadvantages

 

How to use CSRF Tokens?

 

CSRF tokens should have significant entropy and be highly unpredictable, similar to session tokens in general. You should use a cryptographic strength pseudo-random number generator (PRNG) seeded with the timestamp of creation, as well as a static secret.

 

If you require additional assurance beyond the KING's strength, you can generate individual tokens by concatenating its output with some user-specific entropy and performing a strong hash of the entire structure. This adds another barrier to an attacker attempting to analyze tokens based on a sample issued to them.

 

In some applications, it is preferable to send the CSRF tokens as part of a custom request header. Though a token can be placed in the URL query string, this method is considered unsafe because the query string is logged on multiple records both on the server and on the client. The query string, on the other hand, can be accessed on the client browser's screen and transmitted to third-party applications via the HTTP referer header.

 

Furthermore, the CSRF token should be stored on the server-side application, which validates all requests that require validation. The server-side application should ensure that valid requests include a token that matches the value stored during the active session of the user. All HTTP methods, including POST, PUT, and DELETE, should have CSRF token validation.

 

Top Anti- CSRF Tokens: 

 

The most common method for preventing Cross-site Request Forgery (CSRF) is to use a token that is associated with a specific user and can be found as a hidden form in each state, a dynamic form on the online application.

---

Top Anti- CSRF Tokens 

---

1. CSRF Token:

 

• The client wants an HTML page with a form.
• The server appends two tokens in response to this request. One is sent as a cookie, while the others are stored in a hidden form field. These tokens are created at random.
• When the client submits the form, he sends both the token and the form to the server. The cookie token is transmitted as a token, and the form token is transmitted within the form data.
• If a request does not contain both requests, the server does not respond or rejects it.

 

An attacker attempting to forge the request must guess the anti-CSRF tokens as well as the user's authentication passwords. These tokens are invalidated after a period of time and when the session ends. This makes it difficult for the attacker to guess the token.

 

2. Cookies from the same website:

 

Some cookies are associated with a specific origin or website, and when a request is sent to that specific origin, cookies are sent along with it. These are known as cross-origin requests. Cookies are sent to third parties during this process, making CSRF attacks possible.

 

3. Identical Site Cookie Attribute:

 

• The same-site cookie attribute can be used to prevent CSRF attacks. It prevents third-party use of a specific cookie.
• It is done by the server when the cookie is set; the browser is then requested to send the cookie only when the user is directly using the web application.
• If a request is made to the web application, the browser will not send the cookie.

 

It does, however, prevent the CSRF attack. Same-site cookies are not supported in modern browsers, and web applications that use same-site cookies are not supported in older browsers.

 

 

How to avoid a CSRF attack?

 

Here are the steps to take to avoid a CSRF attack.

 

• The first step is to ensure that all GET requests have no side effects. As a result, if a malicious site includes one of your pages, it will have no negative impact.

 

• That leaves only the POST requests to be handled. So we proceed to the next step.

 

• The second step is to add a hidden field to each POST with a secret value generated from the user's session ID.

 

• Then, when the form is processed on the server side, look for that secret field and throw an error if it does not validate.

 

Tokens for CSRF should be generated on the server. They can be produced once per user session or once per request. Per-request tokens are more secure than per-session tokens because an attacker has less time to exploit stolen tokens. However, this may cause usability issues. 

 

For example, the "Back" button browser capability is frequently hampered because the previous page may contain a no longer valid token. Interaction with the previous page will cause the server to generate a CSRF false positive security event. In a per-session token implementation, the value of the token is saved in the session and used for each subsequent request until the session expires.

 

When a client sends a request, the server-side component must check the existence and validity of the token in the request against the token in the user session. If the token could not be found within the request, or if the value provided did not match the value in the user session, the request should be aborted. Additional actions should be considered, such as logging the event as a potential CSRF attack in progress.

 

Tokens for CSRF should be:

 

• Each user session is distinct.
• Secret
• Unpredictable (large random value generated by a secure method).

 

CSRF tokens prevent CSRF because an attacker cannot create valid requests to the backend server without a token.

 

The CSRF token can be added via hidden fields, headers, and forms, as well as used with AJAX calls. Check that the token is not being leaked in the server logs or in the URL. CSRF tokens in GET requests may be leaked in a variety of places, including the browser history, log files, network appliances that log the first line of an HTTP request, and Referer headers if the protected site links to an external site.

 

Stopping CSRF attacks is as simple as adding code that requires a CSRF token. To do so, you must first determine which applications are vulnerable and where they are located, and Bright can assist you!

 

Bright automatically scans all aspects of your apps and generates actionable reports. It works in tandem with the tools and workflows that developers already use. Our AI-powered engine understands application architecture and generates sophisticated and targeted attacks, so scans are quick. The results are completely false-positive free, allowing you to concentrate on releasing code.