What Is Cross-Site Request Forgery?

Cross-site request forgery (CSRF/XSRF) is an attack that tricks an end user into performing an unwanted action within a web application where they are currently authenticated. This attack typically works only in combination with a social engineering attack, since the victim must trigger the action themselves. The impact depends on the underlying application and the privileges of the logged-in user. For example, a user account could be deleted, a password or email address changed, or orders placed without authorization. For this reason, every page and form should be adequately protected against cross-site request forgery.

How Does a CSRF Attack Work?

The potential victim is logged into the application. After logging in, the user remains authenticated for the duration of the session and can perform actions without re-entering their password. While still logged in, the user visits a page crafted by the attacker and performs an action -- for example, by clicking a button. As a result, the attacker sends an HTTP request to the application on behalf of the user, executing a malicious action under the user's identity. This works because the user's session with the web application is still active. Since the session cookie remains valid, the server carries out the malicious action. The CSRF attack succeeds because the server does not verify where the request originates -- whether from its own site or from an external source.

Preconditions for a Successful CSRF Attack

Carrying out a CSRF attack is usually very involved, as several preconditions must be met simultaneously. The attacker needs to understand how the web application works and, among other things, how the target request is structured. The victim must be logged into the application and have the necessary privileges to execute the request. Additionally, the victim must click the link sent by the attacker, and the application must lack CSRF protection.

What Is the Impact of an Attack?

The impact of a CSRF attack can be devastating, depending on the target application, the type of action performed, and the victim's privileges. In some cases, the attacker can gain full control over the user account. If the compromised user holds a privileged role within the application, the attacker may be able to take over all of the application's functions and data. Consequences can range from data theft and unauthorized fund transfers to changed passwords and beyond.

Example of a CSRF Attack -- Changing a Password

Figure 1: CSRF flowchart

• The victim logs into the website.
• The website issues a valid session token.
• The attacker sends the user a payload designed to trigger a password change.
• The user follows the prompt and opens the payload. Hidden inside is a request to the website that initiates the password change.
• The website executes the action in the victim's context. The password has been changed.

In most cases, the impact of a CSRF attack is not immediately visible to the user. With the newly set password and the victim's username, the attacker can now log in to the website. The prerequisite for this example is that the application does not require the current password when setting a new one.

How Do You Prevent CSRF?

To prevent CSRF attacks, you must ensure that an attacker cannot craft an arbitrary request that executes in the context of another user. Several approaches are available.

Token-Based Prevention

As described by OWASP, the most common defense against cross-site request forgery is the use of a CSRF token. These tokens are unpredictable, unique values generated by the application and sent to the client. With each subsequent request, the client sends the token back to the server for verification.

This introduces an element unknown to the attacker, effectively neutralizing CSRF attacks. Any request that does not originate from the legitimate form can simply be discarded because it lacks the correct token value.

However, implementation errors can still introduce vulnerabilities even when CSRF tokens are in use. For effective protection, tokens must be implemented correctly. Modern frameworks typically include token-based CSRF protection out of the box or allow it to be added with minimal effort.

Double-Submit Cookie

If server-side token validation is not feasible, the Double-Submit Cookie technique offers a stateless alternative that is straightforward to implement. A random value is sent both as a cookie and as a request parameter, and the server checks whether the two values match. On the user's first visit, the website generates a cryptographically strong random value and stores it as a cookie -- separate from the session identifier. Every subsequent transaction request must include this value as a hidden form field. If both values match on the server side, the request is accepted as legitimate; otherwise, it is rejected.

Same-Site Cookie

The Same-Site Cookie is an attribute designed to prevent CSRF attacks. It controls whether the browser sends cookies along with a request. Possible values are Lax, Strict, or None.

• None -- Cookies are always sent regardless of context. This only works for cookies marked with the "secure" flag.

• Lax -- The browser withholds the cookie only for "unsafe" requests (POST) but allows it for "safe" requests (GET).

• Strict -- Cookies are never sent with cross-site requests.

It is important to note that this attribute is not a replacement for a CSRF token. Instead, it should be used alongside the token to provide a more robust layer of protection.

Conclusion

Although the CSRF vulnerability has been known for a long time and many frameworks mitigate it by default, it still appears frequently in the wild -- often with severe consequences. By applying the methods described above, you can significantly strengthen the security of your web application.