Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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 3rd 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 3rd party website opens the target site in a new window or tab. If the 3rd 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 3rd party website from performing actions on the window (such as closing or redirecting it).

    Because it is sometimes expected that a 3rd party site will be making calls into the target site, it is possible to configure a list of "trusted" 3rd 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 3rd 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 3rd party site is not SSL protected and the target site is SSL protected.

    Table 1: CSRF Processor Configuration Parameters



    Default Value



    Processor Enabled



    Whether traffic should be passed through this processor.


    Block Response


    HTTP Response

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

    CSRF Nonce Salt



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

    CSRF Token Name



    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



    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


    .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 may interfere with CSRF protection and prevent the Silverlight content from loading.

    Remote Script Resource


    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



    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, will match, and

    CSRF Extra JavaScript



    Since CSRF protection may cause the referer to be removed from the request, it may be necessary to add any analytic code to the JavaScript used to detect and stop CSRF attacks. As such, if you use a 3rd 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 may stop functioning correctly.

    Incident: CSRF Parameter Tampering



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

    Incident: CSRF Remote Script Inclusion



    The user has accessed an untrusted 3rd party website which contains an embedded script reference to the protected application. While the user may 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



    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.

    Published: 2013-11-20