Cross-Site Request Forgery (CSRF) Protection

Cross-Site Request Forgery (CSRF)

Cross Site Request Forgery (CSRF or XSRF) allows an attacker to forge a malicious cross origin write request to a targeted web application that invokes sensitive functions on behalf of an authenticated user. Forged requests are usually represented in the form of a hyperlink, zero-width image, in-page Javascript request, or auto-submitted form post. Some form of social engineering (e.g. a URL to a website in a phishing email), is used by the attacker to trick a victim into unknowingly submitting such a request.

CSRF exploits existing user session identifiers with ambient authority that are provided automatically by the browser during each request, e.g. cookies such as the JSESSIONID and shib_idp_session, or the IP address of the victim. As the attacker has no way of determining/reading the results of that request, useful requests are limited to state-changing, non-idempotent (has side effects) actions that the user is allowed to perform.

Despite the fact the IdP does not itself represent the end resource the user will ultimately interact with, the IdP does present some user flows that could be manipulated by an attacker. For example, of particular importance is the prevention of login CSRF [2], where the attacker attempts to trick the victim into logging in as themselves (the attacker), with the aim then of:

1. Tracking a victim's activity because it is happening in their own session.

2. Tricking the victim into entering sensitive information into an attacker's session/account e.g. bank account details etc.

Consequently, the IdP now employs a synchroniser token pattern [1] CSRF defense. Abstractly, a cryptographically strong string token is generated and attached to the user session by the IdP each time a view is rendered and embedded into HTML forms in the view. When the form is submitted by the user back to the IdP, the IdP verifies that the token in the request matches that stored against the user's session. If they do not match, it is assumed the request was forged - the attacker would not have access to this token, and should not be able to ‘guess’ it.

CSRF attacks on the IdP

Performing a CSRF attack on the IdP is difficult even without specialised CSRF defence. Firstly, for the most part, the IdP does not have stable, static, endpoints listening for requests (other than for certain RESTFul admin functions). Instead, because of the underlying use of Spring Web Flow, the conversation the browser is having with the IdP must be at the correct flow state to accept a HTTP POST/GET request with a given set of manipulatable parameters. For example, using the password authentication flow, the attack opportunity only occurs when the user has progressed the flow to the DisplayUsernamePasswordPage view-state (login page) and no further. It is fairly unlikely, although not impossible, a user would stop at this point and navigate to a malicious website to be tricked into submitting an attacker's username and password back to the IdP.

In addition, in order for Spring Web Flow to resume the flow conversation at the correct state to accept the request, the attacker must guess a suitable execution key. That said, a login would typically occur early in the conversation for a given protocol/binding, and would be fairly predictable/guessable. Finally, as with all login CSRF attacks, the attacker would need an account within the IdP’s authentication source.

However difficult, CSRF attacks are still possible, and these points do not detract from a robust CSRF defense by default.

Configuration

New installations

New installations of IdP v4 will have CSRF protection enabled by default. This is configured by a property in %{idp.home}/conf/idp.properties which globally turns on CSRF protection:

When enabled, all view-states will automatically be protected unless explicitly excluded; see excluding-views. This means any custom view-state added to new or existing flows of the IdP will also be protected, and any submissions back to the IdP will require an anti-CSRF token; see adding-csrf-token.

Upgrades

On upgrade, user views and IdP properties files are not overwritten by the installer. Consequently, in an upgraded state from older versions of the IdP without this feature e.g. v3, CSRF protection is disabled by default, and views will not have the velocity template content required to add anti-CSRF tokens.

Enabling After Upgrade

To enable CSRF protection the following property should be added to %{idp.home}/conf/idp.properties:

Once enabled, the following views need to be updated to include the anti-CSRF token inside HTML forms; see adding-csrf-token for more information on injecting the tokens.

The IdP contains a number of other views from which CSRF has been excluded by configuration; see excluding-views for more information on excluding views.

Excluding Views

Sometimes views do not require CSRF protection, for example when they do not submit sensitive information back to the IdP. Other times, views are involved in user flows that cannot meaningfully benefit from ‘IdP led’ CSRF protection, for example, an external authentication servlet that reaches outside of the IdP and can include arbitrary user interactions. In either case, views can be excluded by annotating the <view-state> element with the following CSRF annotation attribute in the corresponding flow XML configuration file.

CSRF excluded annotation attribute

For example, to exclude an external authentication servlet:

Example: exclude external authentication view

Injecting anti-CSRF tokens into views

HTML forms

HTML forms within protected views must include a hidden input field with both the anti-CSRF token (value attribute) and the HTTP parameter name (name attribute). The IdP comes with a velocity template fragment which adds the anti-CSRF token into a form if present. To add it, simply place the following velocity script element inside the form where it is required:

For example, inside the login form:

If protection is enabled, the token will then be rendered similar to the output below:

Open

Iframe source

Iframes that return control to the IdP in the source attribute also require CSRF tokens unless their parent view-state is excluded from protection. This is required even in a GET request as Spring Web Flow does not differentiate between GET and POST to initiate or resume flows. These can be added with conditional velocity logic e.g.

It is unlikely however that iframe usage benefits much from CSRF protection, and most often the view-state can be excluded. That said, the implementer of a custom flow and or view is responsible for determining that.

Hyperlinks

For the same reason as the iFrame source above, if CSRF protection is enabled hyperlinks also require the CSRF token. These can be added using the same conditional velocity logic e.g.

Custom Flows

If you add a new flow to the IdP, unless excluded (see excluding-views), any view-state it contains will automatically be protected from CSRF attacks providing CSRF protection is enabled globally in the IdP's properties file. Hence, the view template of any view-state must also include the anti-CSRF token; see inject-token.

To cleanly handle the InvalidCSRFTokenException the IdP throws on a CSRF token mismatch, a global on-exception transition must be registered in appropriate flows in addition to a corresponding action/end state. In subflows, this can be added to the list of error events that are reflected back to the parent flow. For example:

Catching a CSRF exception in subflows

In abstract parent flows, this can be added to the global-transitions transitioning to a new action state:

Catching a CSRF exception in parent flows

References

1 - https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#synchronizer-token-pattern
2 - https://seclab.stanford.edu/websec/csrf/csrf.pdf