Cross-Site Request Forgery (CSRF) protection

A Cross-Site Request Forgery (CSRF) attack consists of sending illegitimate requests to a site on behalf of a user who is already authenticated via a session cookie. These illegitimate requests are usually triggered by the authenticated user visiting a malicious website, which sends the forged requests to the target site (typically using Javascript in a web browser). Without CSRF protection, the session cookie and the requests originating from the malicious site are indistinguishable from legitimate requests by the server.

Note that the same-origin policy implemented in web browsers ensures that responses to requests originating from the malicious site cannot be accessed by the malicious script.

• Read-only operations like GET requests are considered to be safe request methods and therefore not subject to CSRF attacks.
• When CSRF protection is enabled, the CSRF token is automatically disabled for sessions that do not use the Security Gate session cookie. So, for example, for mobile applications that cannot use the Security Gate session cookie, but instead use the configured request header for session tracking. Note that this implicit disabling is not visible in the log files.

• Your application is vulnerable to Cross-Site Request Forgery attacks if all the following points are true:
• The user's web browser can automatically send the session credentials. This includes but is not limited to the case where session tracking is done via cookies. Credentials from other authentication schemes, such as Basic or client certificate authentication, can also be automatically sent by the browser.
• There are state-changing requests requiring an authenticated session.
• The URLs of those state-changing requests are not secret. This is usually always the case excepted when session-based URL encryption is enabled.

We highly recommend enabling the Security Gate CSRF token if your application is vulnerable to CSRF attacks.

The Security Gate can protect your web application against Cross-Site Request Forgery (CSRF) attacks using CSRF tokens.

With Airlock Microgateway 3.0 and later, CSRF tokens can protect all request types except for GET, HEAD and OPTIONS requests.

Standard read-only GET requests are expected to be idempotent and safe (see RFC2616). State-changing operations implemented using GET requests are therefore non-standard and should be avoided as they additionally pose a security risk for Cross-Site Request Forgery.

• They can be the target of CSRF attacks.
• The CSRF tokens functionality of the Security Gate will not protect GET requests.
• If possible, modify your application to ensure that state-changing operations are implemented using standard POST, PATCH, PUT or DELETE requests.
• Otherwise, ensure that those GET requests are sufficiently protected against CSRF attacks (see OWASP - Cross-Site Request Forgery Prevention Cheat Sheet).

The Security Gate offers a defense in depth against CSRF attacks as recommended by current best practices (see OWASP - Cross-Site Request Forgery Prevention Cheat Sheet).

The CSRF token is named CSRFT759 by default for all HTTP requests and CSRFT759-S for HTTPS.

• The countermeasures include:
• Standard security attributes on session cookies, such as HttpOnly, Secure, and SameSite.
• The option to protect mappings by enabling CSRF tokens for each mapping. This does the following:
• The Security Gate generates a random token bound to the user session. This token will be sent to the client via an additional cookie (CSRFT759) when the user session is created.
• Every state-changing request is then required to provide the delivered token in a specific request header (X-CSRFT759) in order not to be blocked by the Security Gate. However, for POST requests also the POST parameter CSRFT759 can be used for forms with content type application/x-www-form-urlencoded.

Note that CSRF countermeasures cannot apply in situations where the Security Gate CSRF token is not used (header-based session tracking) i.e. for non-browser-based mobile applications.

The protection offered by Security Gate CSRF tokens relies on the correct implementation of the same-origin policy by the user's web browser, which prevents scripts from another origin to be able to read the value of the CSRF token delivered in the corresponding cookie.

• General requirements and thoughts:
• Correct implementation of the same-origin policy. No other assumption on the user's browser (e.g., support for the SameSite cookie attribute, correct implementation of CORS, etc.) is required for the protection to be effective.
• The application must not be vulnerable to XSS attacks. If vulnerable, an injected malicious script could directly send malicious requests to the server which can not be blocked by the CSRF token feature. Such requests would be indistinguishable from requests executed by legit JavaScript code in the application.
• Reading the CSRF token from the cookie to set it as a custom header in a state-changing request will be handled via JavaScript. The cookie (CSRFT759) delivering the CSRF token to the client does therefore not have the security attribute HttpOnly – in contrast to the session cookie. This, however, is of no consequence for the security based on the previous assumptions (same-origin policy and impossibility of XSS attacks).
• If your application (e.g. the Airlock IAM Login REST UI) is being delivered through a gateway mapping with CSRF tokens enabled, a script tag referencing a JavaScript file is automatically injected by the Gateway. This feature transparently attaches the CSRF token to every state-changing request, your SPA does therefore not need to handle CSRF tokens at all.