Hi Benjamin, thanks for bringing this up!
What you describe is essentially a downgrade from PKCE to a non-PKCE flow. Nov Matake pointed out this possibility in an earlier discussion: https://mailarchive.ietf.org/arch/msg/oauth/qrLAf3nWRt8HAFkO49qGrPRuelo/ We therefore added this attack to the Security BCP: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#page-28 As countermeasures, the BCP lists Beyond this, to prevent PKCE downgrade attacks, the AS MUST ensure that if there was no code_challenge in the authorization request, a request to the token endpoint containing a code_verifier is rejected. Note: AS that mandate the use of PKCE in general or for particular clients implicitly implement this security measure. -Daniel Am 04.01.22 um 11:45 schrieb Benjamin Häublein: > > Hello everyone, > > I think RFC 7636 “Proof Key for Code Exchange by OAuth Public > Clients”, section 4.6. “Server Verifies code_verifier before Returning > the Tokens” leaves a tiny gap regarding the handling of verification > when no code challenge was present in the authorization request: > > Upon receipt of the request at the token endpoint, the server > > verifies it by calculating the code challenge from the received > > "code_verifier" and comparing it with the previously associated > > "code_challenge", after first transforming it according to the > > "code_challenge_method" method specified by the client. > > It is unspecified how the server should behave when “code_verifier” is > present, but “code_challenge” and “code_challenge_method” were not set > in the initial authorization request. > > The following example worked for three well-known authorization > servers where the client was configured in a way that PKCE could be > used, but was not enforced: > > Authorization Request: > > https://XXXX/auth?client_id=YYYY&response_type=code&scope=openid+profile&redirect_uri=https://localhost > <https://XXXX/auth?client_id=YYYY&response_type=code&scope=openid+profile&redirect_uri=https://localhost> > > Subsequent Token Request: > > POST /token HTTP/1.1 > Host: XXXX > Content-Length: 256 > > code=ZZZZ&grant_type=authorization_code&client_id=YYYY&redirect_uri=https%3A%2F%2Flocalhost&code_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX > > As a result, an access token was issued although the code_verifier > provided in the token request did not match the code_challenge and > code_challenge_method in the authorization request. > > > > Many applications consider the usage of PKCE as enough protection from > Login-CSRF and do not use state or nonce (for example this blog entry > by Daniel Fett > https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > <https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/> > suggests, that neither state nor nonce are necessary when PKCE is > used). However, when the authorization server is not configured to > require a specific code_challenge_method from the client and the > authorization behaves as described in the example, PKCE does not > protect from Login-CSRF. > > I think the following mitigations are possible: > > * Enforce usage of PKCE in the client configuration in the > Authorization Server > * Implementation of the authorization server returns an error in the > Access Token Response when code_verifier is present in the token > request, but no code_challenge and code_challenge_method is > present in the authorization request. > * Additionally, when the behavior of an AS is correct (verification > of code_verifier fails when no code_challenge was present), a > client that relies on PKCE for CSRF protection must always include > a code_verifier parameter in the token request (even if no > code_verifier is present on the client side). > > > > Best regards, > > > > Benjamin Häublein > Senior Consultant > > cirosec GmbH > Ferdinand-Braun-Strasse 4 > 74074 Heilbronn > Germany > Phone: +49 (7131) 59455-74 > Fax: +49 (7131) 59455-99 > Mobile: +49 (151) 122414-74 > www.cirosec.de > > HRB Stuttgart 107883 > CEO Stefan Strobel, CFO Peter Lips > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
