Response Processors: CSRF Processor

The CSRF processor is responsible for ensuring that the protected website does not allow a cross site request forgery attack. CSRF attacks are a type of session hijacking, where a malicious website redirects a user to a sensitive service call on the target website. For example, a user might visit a malicious website that has an image tag pointed to the "deleteAccount" service running on a target website. When a user visits the malicious website, they are unknowingly calling the "deleteAccount" operation. If they had an active session on the target site, their account would be deleted.

This processor works by intercepting any request that could potentially be part of a CSRF attack. This is determined by looking at the referer header being passed in by the client. The referer header tells the server where the user came from. If the user is navigating around the actual website legitimately, they will have a referer header on nearly all requests they make which will match the domain of the site they are navigating. If the user types the URL in manually, or follows a link from another site, they will not have a referer. If it's a CSRF attack, there will either be no referer, or a third party domain in the referer.

In all cases where the referer does not match the domain of the protected site, a special redirection page will be returned to the client instead of the request they actually asked for. The redirection page will check to make sure the user is not a victim of a CSRF attack, and if they are not, it will automatically redirect the user to the original page they requested.

This processor only protects clients that have "user-agent" headers matching that of a known browser. This is because CSRF attacks are specifically targeted at average web users, and they generally stick to the major browsers. So spiders and scripts will bypass the CSRF processors detection/protection mechanism. This processor also detects the case where a user has turned off referers (and thus, no requests will contain a referer), and in that case, will turn off CSRF protection for the client. As such, a user who has disabled referers will still be susceptible to CSRF, but that should be a very small percentage (if not zero) of the overall user pool.

In the event that a user issues a request that cannot be validated as not a CSRF attack, the user will not be automatically redirected. Instead, they will be presented a "This page has moved" response, and will be asked to click a link to continue to the page they actually wanted. The link to proceed is randomly positioned on the page to prevent Click Jacking attacks (where a malicious site overlays legitimate content on top of the target site and gets the user to click the legitimate content, while also hijacking the click to transparently activate the content underneath). A special case involves when a third party website opens the target site in a new window or tab. If the third party site retains ownership of the newly opened window or tab, the user will be asked to click the "continue" link so that the original window can be closed and a new window can be opened in its place. This action breaks the ownership and prevents the third party website from performing actions on the window (such as closing or redirecting it).

Because it is sometimes expected that a third party site will be making calls into the target site, it is possible to configure a list of "trusted" third party sites. Any requests issued from a trusted domain will not be protected against CSRF. This allows the trusted site to host the target site in an IFRAME or make service calls unimpeded. Be careful who you add to the trusted domain list, because if the trusted domain is susceptible to XSS or CSRF itself, then it can be used as a proxy to launch a CSRF attack against your protected sites. This trust does not apply if the hosting domain is running over SSL, and the target domain is not running over SSL. If the third party page hosting an IFRAME of the target site is running in SSL, it must load the SSL version of the target site, otherwise the CSRF protection will still be applied. It is however fine if the third party site is not SSL protected and the target site is SSL protected.

Table 32: CSRF Processor Configuration Parameters

Parameter

Type

Default Value

Description

Basic

Processor Enabled

Boolean

True

Whether traffic should be passed through this processor.

Advanced

Block Response

Configurable

HTTP Response

The response to return if the CSRF mechanism cannot complete the request due to errors or tampering.

CSRF Nonce Salt

String

Random

A 256 character random string used to ensure that CSRF nonce tokens are generated differently between different deployments.

CSRF Token Name

String

Random

The name of the query string parameter used to indicate a successfully validated request after it has been determined that it is not a CSRF attack. Select a name that will not conflict with a real query parameter used by the site.

Ignore Scripts

Boolean

True

CSRF is largely a browser based attack, so to ensure that scripts such as legitimate spiders are not treated as potential CSRF victims, this option can be enabled to ignore all non browsers for CSRF protection.

Ignored Extensions

Collection

.xap, .xaml

A list of file suffixes (extensions) that will not be protected by CSRF. By default, Silverlight binaries are included, because some browsers will remove the referer for Silverlight embedded content, which can interfere with CSRF protection and prevent the Silverlight content from loading.

Remote Script Resource

Configurable

CSRF Script Inclusion Resource

The fake resource to request if the page is being loaded as a remote script on a third party domain. This is primarily for detection of the attack and can be any fake resources as long as it does not actually exist on the server.

Trusted Domains

Collection

None

The list of domains that are allowed to display the web application in a frame, reference resources such as images or scripts, or are allowed to make remote API calls using techniques that are similar to a CSRF attack. If the trusted domain starts with a period, then it will match any subdomain before the designated period. For example, .site.com will match www.site.com, my.new.site.com and site.com.

CSRF Extra JavaScript

String

None

Since CSRF protection can cause the referer to be removed from the request, it can be necessary to add any analytic code to the JavaScript used to detect and stop CSRF attacks. As such, if you use a third party analytics script, you should put that code in this parameter to capture the unmodified original request details. The code will be injected into a script tag, so it must be valid JavaScript or the CSRF protection can stop functioning correctly.

Incident: CSRF Parameter Tampering

Boolean

True

The user tampered with the parameters used by the security engine to prevent CSRF on requests that have an untrusted third party referer. This is likely in an attempt to find a vulnerability in the CSRF protection mechanism.

Incident: CSRF Remote Script Inclusion

Boolean

False

The user has accessed an untrusted third party website which contains an embedded script reference to the protected application. While the user might not be malicious, this represents a CSRF attack from the untrusted website against the protected application. Because the attack was not successful, it is likely being executed by the user who is attempting to construct the attack vector.

Incident: HTTP Referers Disabled

Boolean

True

The user is using what looks like a browser, but they have HTTP referers disabled. This is not a malicious incident, but it does indicate an unusual client.