What is Cross-Site-Request-Forgery?

Cross-site request forgery (CSRF/XSRF) is an attack in which an end user is forced to perform an unwanted action in a web application to which they are currently logged in. However, this attack usually works only in combination with a social engineering attack, as the victim must deliberately perform the action. The impact of this attack depends on the application behind it and the privileges of the logged-in user. For example, a user account can be deleted, the password or email address can be changed, or orders can be placed. Therefore, every page and every form should be protected accordingly 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 logged in for the duration of the session and can perform actions without having to re-enter the password. While logged in, the user visits a page created by the attacker. There, the user performs an action, e.g. by pressing a button. As a result, the attacker sends an HTTP request to the application used by the user and performs a malicious action under the user's identity. This works because the session the user has with the web application is still active. By making the session cookie valid, the server performs the malicious action. The CSRF attack is so successful because it does not check where the request is coming from. It is not known whether the HTTP request comes through its own site or originates from a third-party source.

Preconditions for a Successful CSRF Attack

Performing a CSRF attack is usually very elaborate, as several preconditions must be met. The attacker must know how the web application works and must also know, among other things, how the corresponding call to be executed is structured. Furthermore, the victim must be logged into the application and have the appropriate rights to execute the call. The victim must click on the link sent by the attacker and last but not least, the application must not have CSRF protection.

What is the Impact of an Attack?

The impact of a CSRF attack can be catastrophic, but this depends on the application being attacked, the type of action being performed, and on the privileges the victim has in the application. In some cases, the attacker can gain complete control over the user account. If the compromised user has a privileged role within the application, the attacker may be able to take complete control over all of the application's functions and data. The consequences can include data theft, unauthorized money transfers, changed passwords, and more.

Example of CSRF Attack - Change Password

Figure 1: CSRF flowchart

• The victim logs into the website
• The website issues a valid session token.
• The attacker sends the user the payload that leads to the password change.
• The user complies with the request and opens the payload. Hidden in the payload is a request to the website, which leads to a change of password.
• The action is performed by the website in the context of the victim. The password for the user has been changed.

In most cases, the impact of a CSRF attack is not directly visible to the user. With the newly set password and the victim's username, the attacker is now able to log in to the website. The precondition for this example is that when the password is changed, the current password is not requested.

How do I Prevent CSRF?

To prevent CSRF attacks, it is necessary to ensure that an attacker cannot create an arbitrary request that is executed in the context of another user. This can be implemented in several ways.

Token-based Prevention

As also described by the OWASP, the most common defense technique for cross-site request forgery attacks is the use of a CSRF token. These session tokens are unpredictable and unique values generated by the application and sent to the client. Then, they are sent back to the server in the client's request, which verifies the request.

This introduces an unknown element that can effectively mitigate the CSRF attack. Any request that does not originate from the original form can simply be discarded because it does not contain the correct value for the CSRF token.

Nevertheless, even when CSRF tokens are used, some vulnerabilities can occur due to errors in the implementation. To protect against such an attack, CSRF tokens must be implemented correctly. When using modern frameworks, token-based CSRF protection is usually already included or can be easily added.

Double-Submit Cookie

If using a valid token on the server side is not possible, an alternative option is to use the Double Submit Cookie technique. This technique is simple to implement and also stateless. Here, a random value is sent both in a cookie and as a request parameter, and the server checks whether the cookie value and the request value match. When a user visits the website for the first time, the website should generate a cryptographically strong random value and store it as a cookie on the user's computer. This cookie should be stored separately from the session identifier. The website then requires that each transaction request contain this pseudo-random value as a hidden form value. If both values match on the server side, the server accepts the request as legitimate, if not, it is rejected.

Same-site Cookie

The Same-Site-Cookie is an attribute designed to prevent CSRF attacks. This attribute helps the browser decide whether to send cookies along with a request. Possible values for this attribute are Lax, Strict, or None.

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

Lax - With a lax setting, the browser will prevent the cookie from being sent only for "unsafe" requests (POST), but will allow "safe" requests (GET).

Strict - With the Strict setting, cookies are never sent on cross-page requests.

It is important to note that the use of this attribute should not replace a CSRF token. Instead, it should co-exist with that token to protect the user in a more robust way.

Conclusion

Although the CSRF vulnerability itself has been known for a long time and its impact is already mitigated by default by many frameworks, the vulnerability is still frequently found in the wild. This also usually with catastrophic effects. However, with some of the methods listed above, the security of your web application can be increased many times over.