Discovery / Security Considerations: CSRF attack on user input identifier

Issue #979 open
Vladimir Dzhuvinov created an issue

I would like to propose a new section under 7. Security Considerations:

7.3 CSRF Attack On User Input Identifier

The RP MUST ensure that input of the Identifier used to commence OpenID Provider Issuer discovery is submitted by the legitimate End-User and protected from Cross-Site Request Forgery (CSRF) attacks.

An attacker may employ a CSRF attack to submit an Identifier chosen to resolve to an Issuer location and OpenID Provider Metadata document controlled by the attacker. The attacker may then return OpenID Provider Metadata pointing to the Client Registration Endpoint and Authorization Endpoint of a legitimate OP for the End-User while referring to a malicious Token Endpoint in order to steal the authorization grant and client credentials of the RP.

This proposal was prompted by a paper that was published last week:

The paper has a number of problems, such as failing to clearly identify CSRF as the key issue and recommending measures for that. Anyway, the threat of CSRF is there and I think we should warn developers of this.

Comments (8)

  1. John Bradley

    It should be noted that clients using client_secret_jwt or private_key_jwt are not susceptible to this.
    Per core Sec 9 they include the audience in the JWT. aud REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

    The attacker can get the code by doing this but they cannot replay it against the token endpoint belonging to the registration server/authorization endpoint. It may be worth emphasizing why the token endpoint really needs to check that audience.

  2. Vladimir Dzhuvinov reporter

    Copying my response to the mailing list:

    #979 - Discovery / Security Considerations: CSRF attack on user input identifier We need to work out how to prevent MITM attacks against Dynamic Registration The attack is getting someone to talk to a bad token endpoint You don't know that you've registered at the right endpoint when you register This issue clearly needs discussion on the mailing list. One possible fix is to have registration return the token endpoint URL for a cross-check Mike points out that in multi-tenant environment, the issuer will vary by tenant We may want to look at how we're using the JWT token profile

    Here is an alternative solution:

    The RP (client) may be required to include the discovered Issuer URL in the client registration request. The OP can then check whether the RP has used a legitimate discovery endpoint, and if not deny registration.

    I think this approach will fare better. The client is not required to do a cross check, which developers may forget to implement. OPs are more likely to get this right.

  3. Michael Jones

    The attack is against the web form that the RP puts up for input of the user identifier. This web form needs to have CSRF protection. John said that this is done by a nonce and/or cookie.

    We can add language saying that the input form must have CSRF protection.

  4. Log in to comment