# CROSS SITE REQUEST FORGERY

Feature Value
Type Protection
Risk Other
Covered by Agent/Library

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated. CSRF attacks specifically target state-changing requests, not data, since the attacker has no way of seeing the response to the forged request. With a little help from social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests, such as transferring funds, changing their email address, and so on. If the victim is an administrative account, CSRF can compromise the entire web application.

## How to solve it

Hdiv adds an aleatory token to each link or form existing within the application, making it extremely difficult to implement a CSRF attack because the attacker does not know what the value is.

In order to offer the highest security level, Hdiv does not use an aleatory token per session but instead creates a new token for each requested page. Even the tokens used by links and forms within the same page are different, avoiding the reuse of link tokens to exploit a web form.

## Agent Configuration

Hdiv agent supports different CSRF protection policies. In this section we will cover how they work and how they can be configured.

### When will CSRF be validated?

Several configuration options can slightly modify this behavior but the following situations will be excluded from validation

• Not POST: Unless GET requests are modifying the state (which they should not be), only POSTs can be vulnerable to CSRF
• Empty POST: If no parameter is sent then the request cannot change the status and therefore it should not be validated
• Invalid content-types: Only the following content-types are supported "text/plain", "multipart/form-data" and "application/x-www-form-urlencoded"
• Not AJAX: AJAX calls are protected by cross domain policies by default
• No User-Agent header: a CSRF attack implies an unaware browser user. All browsers send user-agent headers, so no validation is applied
• Same domain calls: a CSRF attack is a cross domain call, so if the request comes from the same domain, then we are safe
• Static resources: Static resources such as js files are excluded

### Policies

#### Token

The most simple approach is the token-based solution. In this case a random session token will be included in HTML forms and it will be required when they are submitted.

The following configuration options are supported

• Protection of GETs: false by default, implying that all GET requests that have parameters will be validated to have a CSRF token. This approach only works if all GET requests which have parameters are created with HTML Forms and not with a simple link. For most scenarios this should be set to false, or otherwise create exclusions for those GET requests that are created with links
• Protection in same domain calls: false by default, CSRF vulnerability implies a request that comes from a cross domain. If the request comes from the same domain, then we cannot be attacked with a CSRF. By default, Hdiv does not validate the token for same domain calls but this behavior could be changed with this option
• Inline CSRF token: false by default, Hdiv includes the CSRF token for forms using Javascript at the end of the page as this is the most efficient approach. However, several commercial scanners are not able to detect that the token is included in this way. If that might be an issue, this option can be activated. In this case the token is included directly inside the form as a hidden field, although it is not advisable to activate this option in production environments
• CSRF token name: By default, HdivToken is the name of the token inside the form
• Fixed token value: In same configurations the token value needs to be a fixed value that can be set. In general, this option should be left empty (variable token)

#### Whitelist

A token-based approach is the most widespread solution to contain CSRF attacks. However, not all scenarios can be solved with it. A token policy implies including a token inside a form. This may work in most cases but it will not be an option if for example a third party application (contained in a different domain) is targeting a POST url without requesting the form to the original domain. In that case the third party application will never send the token and therefore it will be blocked. A solution involving no code change, which is also transparent, is a domain whitelist approach.

By using this policy, Hdiv agent sends all the different domains that are targeting an application to Hdiv Console. All those domains are stored in the web console, making it really easy to create a whitelist of valid third party domains. Once it is created, Hdiv agent will only allow requests that need to be validated against CSRF (see the list above) when they come from whitelisted domains. Otherwise they are rejected.

The main features of this policy are, transparency (no additional information required), ease of update and being based on a whitelist.

The following configuration options are supported

• Protection of GETs: false by default, implying that all GET requests that have parameters will be validated to be on a domain whitelist. This approach only works if all GET requests which have parameters are created with HTML Forms and not with a simple link. For most scenarios this should be set to false, otherwise create exclusions for those GET requests that are created with links
• Protection in same domain calls: false by default, CSRF vulnerability implies a request that comes from a cross domain. If the request comes from the same domain, then we cannot be attacked with a CSRF. By default, Hdiv does not validate the whitelist for same domain calls but this behavior can be changed with this option

NOTE: As it is transparent, its protection may not be detected by most scanners

#### Token-Whitelist

The last option is a mixture of the previous ones. In this last option the token is included in the same way as in the first approach. When validation is needed, an attempt is first made to validate the token in the same ways as with the first policy. If the token is not valid, then the domain is validated using a domain whitelist as with the whitelist policy.