Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Daniel Fett <[e-mail]>]

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: [phone]
> Fax: [phone]
> Mobile: [phone]
> www.cirosec.de
>
> HRB Stuttgart 107883
> CEO Stefan Strobel, CFO Peter Lips
>
>  
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de