Discovery / Security Considerations: CSRF attack on user input identifier

[Vladimir Dzhuvinov]

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:

http://arxiv.org/pdf/1508.04324.pdf

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.

[Hans Zandbelt]

In that case "Initiating Login from a Third Party" from the core spec (http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin) to me seems mutually exclusive with Discovery under the same security considerations as you mention. That probably deserves to be documented/cautioned as well.

[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.

[Michael Jones]

This issue clearly needs discussion on the mailing list.

[Vladimir Dzhuvinov]

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.

[Nat Sakimura]

assigned to John.

[Nat Sakimura]

Being intensively discussed in IETF.

[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.

[John Bradley]

Possible xsrf reference https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

[Joseph Heenan]

Mike mentioned this issue to me as he’s trying to wrap up all the errata issues.

The attack as described seems like it would be prevented by the ‘iss’ authorization response parameter, https://datatracker.ietf.org/doc/html/rfc9207

Although technically adding PAR into the mix reintroduces the issue.

‌

‌

As Mike/John commented above, adding a sentence to the web finger section along the lines “Any web input form needs to have CSRF protection, see https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html” makes sense.

‌

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/575

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/575