Preventing Cross-Site Request Forgery in Identity Provider-Initiated OpenID Connect
CSRF (Cross-Site Request Forgery) can allow an attacker to coerce a user into unknowingly and unintentionally dispatch responses to an application. By tricking a user into following a link, for example a link which submits a form to a vulnerable application which does not detect CSRF an attacker can have a user unknowingly perform operations on the application.
Generally, CSRF protection can be provided by the use of a CSRF token. In order to protect against CSRF, this token should be a cryptographically random nonce which is tied to the user’s session. This token can be submitted with the requests as an invisible form field or cookie which ensures that a user cannot submit a form without first visiting the form page. Every request that contain this value must be checked to ensure that it matches the expected value. In the event the value does not match, this can be flagged as suspicious behavior, as it is a clear indication of malicious activities.
In OIDC flow, CSRF attacks can occur against client callback URL when an attacker injects its own authorization code or access token, which can result in the client using an access token associated with the attacker’s protected resources rather than the victim’s. This is described in ‘OAuth 2.0 Threat Model and Security Considerations’ spec [1] as follows.
An attacker could authorize an authorization “code” to their own protected resources on an authorization server. He then aborts the redirect flow back to the client on his device and tricks the victim into executing the redirect back to the client. The client receives the redirect, fetches the token(s) from the authorization server, and associates the victim’s client session with the resources accessible using the token.
Impact: The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker’s resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker’s identity at the external Identity Provider. In this way, the attacker could easily access the victim’s data at the client by logging in from another device with his credentials at the external Identity Provider.
In OIDC flow, ‘state’ parameter is used to mitigate CSRF attacks. In order to prevent CSRF attacks on callback, client needs to implement CSRF protection by checking that the state parameter exists in the user’s session when an authorization code response arrives in exchange for the access token to the client callback URL. The state parameter in this design should a be key to a session attribute in the initiator user’s session with the client application. In typical scenario, this is done by cryptographically binding the value of user’s browser cookie and client ID to session parameter.
However, in the case where OIDC flow is initiated by IDP, IDP cannot prevent the CSRF attacks because the state parameter needs to be generated and managed by the client in order to correlate the state with the application user’s session.
One possible solution which can be performed by the client to mitigate CSRF attacks in IDP initiated OIDC requests, is by verifying the ‘Referer’ headers of the incoming HTTP requests.
This is further elaborated in [2] section 6. Following is an overview of the solution mentioned in the paper.
When the RP receives an authorization response, it first retrieve the identity of the IdP from redirect uri and then checks that the domain in the Referer header is either the RP Domain or the IdP domain. If the domain of the Referer header is one of these two values,then the RP knows this is a genuine authorization response coming from the IdP; otherwise, the RP should discard this HTTP message and send an error page to the user.
As an example of how this might work in practice, suppose a web attacker puts a link https://rp.com/AIdP-callback?code=[code_belongs_to_attacker_generated_by_AIdP] on attacker.com to try to launch a CSRF attack against the redirect uri RP registered with IdP. The HTTP message of the attack re-quest will contain a Referer header which points to attacker.com. The RP is able to detect this is an attack message by comparing the identity of the IdP or its own domain with the domain in the Referer header.
