Why csrf token

For example, suppose an application contains a function that lets the user change the email address on their account. When a user performs this action, they make an HTTP request like the following:. With these conditions in place, the attacker can construct a web page containing the following HTML:. Although CSRF is normally described in relation to cookie-based session handling, it also arises in other contexts where the application automatically adds some user credentials to requests, such as HTTP Basic authentication and certificate-based authentication.

Manually creating the HTML needed for a CSRF exploit can be cumbersome, particularly where the desired request contains a large number of parameters, or there are other quirks in the request. The delivery mechanisms for cross-site request forgery attacks are essentially the same as for reflected XSS.

Typically, the attacker will place the malicious HTML onto a web site that they control, and then induce victims to visit that web site. This might be done by feeding the user a link to the web site, via an email or social media message.

Or if the attack is placed into a popular web site for example, in a user comment , they might just wait for users to visit the web site. In this situation, the attacker may not need to employ an external site, and can directly feed victims a malicious URL on the vulnerable domain. In the preceding example, if the request to change email address can be performed with the GET method, then a self-contained attack would look like this:.

The token should be:. In the previous example, suppose that the application now includes a CSRF token within the request to change the user's password:. This ought to prevent CSRF attacks because it violates the necessary conditions for a CSRF vulnerability: the application no longer relies solely on cookies for session handling, and the request contains a parameter whose value an attacker cannot determine.

However, there are various ways in which the defense can be broken, meaning that the application is still vulnerable to CSRF. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

As such, CSRF attacks target state-changing requests. The attacker forces a non-authenticated user to log in to an account the attacker controls. If the victim does not realize this, they may add personal data—such as credit card information—to the account. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet.

The likelihood is also increased because the victim is sure to be authenticated to the site already. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation. A number of flawed ideas for defending against CSRF attacks have been developed over time. Cross-Site Request Forgery. What is Cross-Site Request Forgery?

How does Cross-Site Request Forgery work? Examples include: Submitting or deleting a record. Submitting a transaction. Purchasing a product. Changing a password. Sending a message. To successfully launch this attack: The attacker must build an exploit URL. The attacker must also trick Bob into clicking the exploit URL. Bob needs to have an active session with samplebank. There are some limitations. The attack will only be successful if the user is in an active session with the vulnerable application.

An attacker must find a valid URL to maliciously craft. The URL needs to have a state-changing effect on the target application. An attacker also needs to find the right values for the URL parameters. Otherwise, the target application might reject the malicious request. Quickly scan source code to find vulnerabilities Learn more. Since the attacker cannot determine or predict the value of a user's CSRF token, they cannot construct a request with all the parameters that are necessary for the application to honor the request.

CSRF tokens should contain significant entropy and be strongly unpredictable, with the same properties as session tokens in general. You should use a cryptographic strength pseudo-random number generator PRNG , seeded with the timestamp when it was created plus a static secret.

If you need further assurance beyond the strength of the PRNG, you can generate individual tokens by concatenating its output with some user-specific entropy and take a strong hash of the whole structure. This presents an additional barrier to an attacker who attempts to analyze the tokens based on a sample that are issued to them. CSRF tokens should be treated as secrets and handled in a secure manner throughout their lifecycle.