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

2022-01-05 Thread Thomas Broyer 
=http%3A%2F%2Flocalhost%2F_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 as they were absent.
>>
>>
>>
>> An attacker can thus send the victim the authorization response, after
>> the victim clicks the link, the client application sends a Token Request
>> with the code_verifier present with the client to Keycloak.
>>
>> As a result, a token is issued for the application, although the
>> code_verifier does not match the inexistent
>> code_challenge/code_challenge_method in the malicious authorization
>> response.
>>
>>
>>
>> For this to work, the client must either generate a code_verifier on the
>> fly or have one already present. This obviously depends on the precise
>> implementation of the respective client.
>>
>> To reach such a state, an attacker could trick the user into starting the
>> authorization grant but clicking the malicious link before the
>> authorization response is sent.
>>
>>
>>
>> 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
>>
>>
>>
>> *Von:* Warren Parad 
>> *Gesendet:* Mittwoch, 5. Januar 2022 13:44
>> *An:* Benjamin Häublein 
>> *Cc:* George Fletcher ; oauth@ietf.org
>> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies
>> code_verifier facilitates Login-CSRF
>>
>>
>>
>> Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch". Weitere
>> Informationen, warum dies wichtig ist
>> <http://aka.ms/LearnAboutSenderIdentification>
>>
>> I'm not following to be honest. Could you detail concretely what the flow
>> would be that would result in vulnerability?
>>
>>
>> *Warren Parad*
>>
>> Founder, CTO
>>
>> Secure your user data with IAM authorization as a service. Implement
>> Authress <https://authress.io/>.
>>
>>
>>
>>
>>
>> On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein <
>> benjamin.haeubl...@cirosec.de> wrote:
>>
>> Finally, I'm not sure a client that doesn't send the 'code_challenge' and
>> 'code_challenge_method' on the authorization request but does send the
>> 'code_verifier' on the token request should consider that the client has
>> implemented PKCE correctly and hence can rely on it for CSRF.
>>
>> My point is not, that a client behaves that way. The problem is that an
>> attacker could get a user (through social engineering) to start the
>> authorization process and then click a link with an authorization response
>> that the attacker provides.
>>
>> Then the client has send the 'code_challenge' and 'code_challenge_method'
>> in the authorization request, but the authorization response belongs to an
>> authorization request that does not have these parameters.
>>
>> When the client sends the token request based on the malicious
>> authorization request but with the ‘code_verifier’ for the original
>> authorization request.
>>
>> When the AS behaves as described the client has no way to know that an
>> attacker has interfered.
>>
>>
>>
>> Best Regards,
>>
>> Benjamin Häublein
>>
>> *Von:* George Fletcher 
>> *Gesendet:* Dienstag, 4. Januar 2022 14:51
>> *An:* Benjamin Häublein ; oauth@ietf.org
>> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies
>> code_verifier facilitates Login-CSRF
>>
>>
>>
>> My guess is that for an Authorization Server that doesn't receive a
>> 'code_challenge' and 'code_challenge_method' as part of the authorization
>> request, they treat the request as a non-PKCE authorization request. 
>> Therefore
>> when the 'code_verifier' is presented at the /token endpoint, the AS
>> ignores the parameter because it doesn't consider the request to be a PKCE
>> request. I can also see the AS returning an error regarding an "unexpected
>> parameter" or "invalid request" error in this case.
>>
>> I agree with your recommendation for th

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

2022-01-05 Thread George Fletcher 
ot match the inexistent
code_challenge/code_challenge_method in the malicious
authorization response.

For this to work, the client must either generate a
code_verifier on the fly or have one already present. This
obviously depends on the precise implementation of the
respective client.

To reach such a state, an attacker could trick the user into
starting the authorization grant but clicking the malicious
link before the authorization response is sent.

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 <http://www.cirosec.de>

HRB Stuttgart 107883
CEO Stefan Strobel, CFO Peter Lips

*Von:* Warren Parad 
*Gesendet:* Mittwoch, 5. Januar 2022 13:44
*An:* Benjamin Häublein 
*Cc:* George Fletcher ; oauth@ietf.org
        *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server
    Verifies code_verifier facilitates Login-CSRF




Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch". Weitere
Informationen, warum dies wichtig ist
<http://aka.ms/LearnAboutSenderIdentification>



I'm not following to be honest. Could you detail concretely
what the flow would be that would result in vulnerability?




*Warren Parad*

Founder, CTO

Secure your user data with IAM authorization as a service.
Implement Authress <https://authress.io/>.

On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein
 wrote:

Finally, I'm not sure a client that doesn't send the
'code_challenge' and 'code_challenge_method' on the
authorization request but does send the 'code_verifier' on
the token request should consider that the client has
implemented PKCE correctly and hence can rely on it for CSRF.

My point is not, that a client behaves that way. The
problem is that an attacker could get a user (through
social engineering) to start the authorization process and
then click a link with an authorization response that the
attacker provides.

Then the client has send the 'code_challenge' and
'code_challenge_method' in the authorization request, but
the authorization response belongs to an authorization
request that does not have these parameters.

When the client sends the token request based on the
malicious authorization request but with the
‘code_verifier’ for the original authorization request.

When the AS behaves as described the client has no way to
know that an attacker has interfered.

Best Regards,

Benjamin Häublein

*Von:* George Fletcher 
*Gesendet:* Dienstag, 4. Januar 2022 14:51
*An:* Benjamin Häublein ;
    oauth@ietf.org
    *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server
Verifies code_verifier facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't
receive a 'code_challenge' and 'code_challenge_method' as
part of the authorization request, they treat the request
as a non-PKCE authorization request. Therefore when the
'code_verifier' is presented at the /token endpoint, the
AS ignores the parameter because it doesn't consider the
request to be a PKCE request. I can also see the AS
returning an error regarding an "unexpected parameter" or
"invalid request" error in this case.

I agree with your recommendation for the AS to require
specific clients to use PKCE and consider an authorization
request without PKCE to be an error.

Finally, I'm not sure a client that doesn't send the
'code_challenge' and 'code_challenge_method' on the
authorization request but does send the 'code_verifier' on
the token request should consider that the client has
implemented PKCE correctly and hence can rely on it for CSRF.

Thanks,
George

On 1/4/22 5:45 AM, Benjamin Häublein wrote:

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 au

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

2022-01-05 Thread Warren Parad 
The PKCE downgrade attack is the converse, here we are adding in PKCE where
there was none.

An attacker can thus send the victim the authorization response, after the
> victim clicks the link, the client application sends a Token Request with
> the code_verifier present with the client to Keycloak.

That isn't the whole flow though, right? You are missing what the
authorization request the attacker sent to the AS is, as well what happens
after the user agent gets back the access token, how is a token generated
this way a vulnerability.

I think I see the suggested problem:

if an AS-client interaction supports both PKCE and not PKCE, and the client
assumes that PKCE is sufficient for CSRF, when the auth code request
doesn't include the PKCE but the client didn't send state/nonce. With OAuth
2.1 it is clear that the nonce/state must be sent in this situation:

   - State is required in OAuth authorization code requests if PKCE isn't
   specified: OAuth 2.1 section 7.7
   <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-7.7>
   - State is required in OAuth token exchange requests if present: Section
   4.1.2
   
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2>

Since the user agent won't contain the valid state/nonce generated by the
attacker, it isn't possible for it to send the attacker's state to the AS.
Therefore the AS will reject the token exchange due to the state mismatch.
It doesn't matter if the request isn't protected against CSRF, because no
valid token is going to be returned anyway.

So I don't think there is an issue here, did I get that correct?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Jan 5, 2022 at 3:56 PM Christopher Burroughs <
chris.burrou...@protonmail.ch> wrote:

> Greetings,
>
>
> Is this scenario any different from a PKCE downgrade attack, as described
> in OAuth 2.0 Security Best Current Practice section 4.8.2 ?
>
>
> Warm regards and happy new year!
>
>
> Christopher Burroughs
>
>
>
>
>
>  Original Message 
> On Jan 5, 2022, 21:29, Benjamin Häublein < benjamin.haeubl...@cirosec.de>
> wrote:
>
>
> The following example shows this behavior in keycloak:
>
> Authorization Request:
>
>
> http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
>
> Authorization Response:
>
>
> http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
>
> Token Request:
>
> POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
> Host: identity-provider:8080
> Content-type: application/x-www-form-urlencoded
>
>
> code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_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 as they were absent.
>
>
>
> An attacker can thus send the victim the authorization response, after the
> victim clicks the link, the client application sends a Token Request with
> the code_verifier present with the client to Keycloak.
>
> As a result, a token is issued for the application, although the
> code_verifier does not match the inexistent
> code_challenge/code_challenge_method in the malicious authorization
> response.
>
>
>
> For this to work, the client must either generate a code_verifier on the
> fly or have one already present. This obviously depends on the precise
> implementation of the respective client.
>
> To reach such a state, an attacker could trick the user into starting the
> authorization grant but clicking the malicious link before the
> authorization response is sent.
>
>
>
> 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
>
>
>
> *Von:* Warren Parad 
> *Gesendet:* Mittwoch, 5. Januar 2022 13:44
> *An:* Benjamin Häublein 
> *Cc:* George Fletcher ; oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636,

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

2022-01-05 Thread Christopher Burroughs 
Greetings,

Is this scenario any different from a PKCE downgrade attack, as described in 
OAuth 2.0 Security Best Current Practice section 4.8.2 ?

Warm regards and happy new year!

Christopher Burroughs

 Original Message 
On Jan 5, 2022, 21:29, Benjamin Häublein wrote:

> The following example shows this behavior in keycloak:
>
> Authorization Request:
>
> http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
>
> Authorization Response:
>
> http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
>
> Token Request:
>
> POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
> Host: identity-provider:8080
> Content-type: application/x-www-form-urlencoded
>
> code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_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 as they were absent.
>
> An attacker can thus send the victim the authorization response, after the 
> victim clicks the link, the client application sends a Token Request with the 
> code_verifier present with the client to Keycloak.
>
> As a result, a token is issued for the application, although the 
> code_verifier does not match the inexistent 
> code_challenge/code_challenge_method in the malicious authorization response.
>
> For this to work, the client must either generate a code_verifier on the fly 
> or have one already present. This obviously depends on the precise 
> implementation of the respective client.
>
> To reach such a state, an attacker could trick the user into starting the 
> authorization grant but clicking the malicious link before the authorization 
> response is sent.
>
> 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-74www.cirosec.de
>
> HRB Stuttgart 107883
> CEO Stefan Strobel, CFO Peter Lips
>
> Von: Warren Parad 
> Gesendet: Mittwoch, 5. Januar 2022 13:44
> An: Benjamin Häublein 
> Cc: George Fletcher ; oauth@ietf.org
> Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
> facilitates Login-CSRF
>
> Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch". [Weitere Informationen, 
> warum dies wichtig ist](http://aka.ms/LearnAboutSenderIdentification)
>
> I'm not following to be honest. Could you detail concretely what the flow 
> would be that would result in vulnerability?
>
> Warren Parad
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement 
> [Authress](https://authress.io/).
>
> On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein 
>  wrote:
>
>> Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
>> 'code_challenge_method' on the authorization request but does send the 
>> 'code_verifier' on the token request should consider that the client has 
>> implemented PKCE correctly and hence can rely on it for CSRF.
>>
>> My point is not, that a client behaves that way. The problem is that an 
>> attacker could get a user (through social engineering) to start the 
>> authorization process and then click a link with an authorization response 
>> that the attacker provides.
>>
>> Then the client has send the 'code_challenge' and 'code_challenge_method' in 
>> the authorization request, but the authorization response belongs to an 
>> authorization request that does not have these parameters.
>>
>> When the client sends the token request based on the malicious authorization 
>> request but with the ‘code_verifier’ for the original authorization request.
>>
>> When the AS behaves as described the client has no way to know that an 
>> attacker has interfered.
>>
>> Best Regards,
>>
>> Benjamin Häublein
>>
>> Von: George Fletcher 
>> Gesendet: Dienstag, 4. Januar 2022 14:51
>> An: Benjamin Häublein ; oauth@ietf.org
>> Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
>> facilitates Login-CSRF
>>
>>

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

2022-01-05 Thread Benjamin Häublein 
The following example shows this behavior in keycloak:
Authorization Request:
http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
Authorization Response:
http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
Token Request:
POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
Host: identity-provider:8080
Content-type: application/x-www-form-urlencoded

code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_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 as they were absent.

An attacker can thus send the victim the authorization response, after the 
victim clicks the link, the client application sends a Token Request with the 
code_verifier present with the client to Keycloak.
As a result, a token is issued for the application, although the code_verifier 
does not match the inexistent code_challenge/code_challenge_method in the 
malicious authorization response.

For this to work, the client must either generate a code_verifier on the fly or 
have one already present. This obviously depends on the precise implementation 
of the respective client.
To reach such a state, an attacker could trick the user into starting the 
authorization grant but clicking the malicious link before the authorization 
response is sent.

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

Von: Warren Parad 
Gesendet: Mittwoch, 5. Januar 2022 13:44
An: Benjamin Häublein 
Cc: George Fletcher ; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
facilitates Login-CSRF

Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>". 
Weitere Informationen, warum dies wichtig 
ist<http://aka.ms/LearnAboutSenderIdentification>
I'm not following to be honest. Could you detail concretely what the flow would 
be that would result in vulnerability?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://authress.io/>.


On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein 
mailto:benjamin.haeubl...@cirosec.de>> wrote:
Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
'code_challenge_method' on the authorization request but does send the 
'code_verifier' on the token request should consider that the client has 
implemented PKCE correctly and hence can rely on it for CSRF.
My point is not, that a client behaves that way. The problem is that an 
attacker could get a user (through social engineering) to start the 
authorization process and then click a link with an authorization response that 
the attacker provides.
Then the client has send the 'code_challenge' and 'code_challenge_method' in 
the authorization request, but the authorization response belongs to an 
authorization request that does not have these parameters.
When the client sends the token request based on the malicious authorization 
request but with the ‘code_verifier’ for the original authorization request.
When the AS behaves as described the client has no way to know that an attacker 
has interfered.

Best Regards,
Benjamin Häublein
Von: George Fletcher mailto:gffle...@aol.com>>
Gesendet: Dienstag, 4. Januar 2022 14:51
An: Benjamin Häublein 
mailto:benjamin.haeubl...@cirosec.de>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't receive a 
'code_challenge' and 'code_challenge_method' as part of the authorization 
request, they treat the request as a non-PKCE authorization request. Therefore 
when the 'code_verifier' is presented at the /token endpoint, the AS ignores 
the parameter because it doesn't consider the request to be a PKCE request. I 
can also see the AS returning an error regarding an "unexpected parameter" or 
"invalid request" error in this case.

I agree with your recommendation for the AS to req

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

2022-01-05 Thread Warren Parad 
I'm not following to be honest. Could you detail concretely what the flow
would be that would result in vulnerability?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein <
benjamin.haeubl...@cirosec.de> wrote:

> Finally, I'm not sure a client that doesn't send the 'code_challenge' and
> 'code_challenge_method' on the authorization request but does send the
> 'code_verifier' on the token request should consider that the client has
> implemented PKCE correctly and hence can rely on it for CSRF.
>
> My point is not, that a client behaves that way. The problem is that an
> attacker could get a user (through social engineering) to start the
> authorization process and then click a link with an authorization response
> that the attacker provides.
>
> Then the client has send the 'code_challenge' and 'code_challenge_method'
> in the authorization request, but the authorization response belongs to an
> authorization request that does not have these parameters.
>
> When the client sends the token request based on the malicious
> authorization request but with the ‘code_verifier’ for the original
> authorization request.
>
> When the AS behaves as described the client has no way to know that an
> attacker has interfered.
>
>
>
> Best Regards,
>
> Benjamin Häublein
>
> *Von:* George Fletcher 
> *Gesendet:* Dienstag, 4. Januar 2022 14:51
> *An:* Benjamin Häublein ; oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies
> code_verifier facilitates Login-CSRF
>
>
>
> My guess is that for an Authorization Server that doesn't receive a
> 'code_challenge' and 'code_challenge_method' as part of the authorization
> request, they treat the request as a non-PKCE authorization request. Therefore
> when the 'code_verifier' is presented at the /token endpoint, the AS
> ignores the parameter because it doesn't consider the request to be a PKCE
> request. I can also see the AS returning an error regarding an "unexpected
> parameter" or "invalid request" error in this case.
>
> I agree with your recommendation for the AS to require specific clients to
> use PKCE and consider an authorization request without PKCE to be an error.
>
> Finally, I'm not sure a client that doesn't send the 'code_challenge' and
> 'code_challenge_method' on the authorization request but does send the
> 'code_verifier' on the token request should consider that the client has
> implemented PKCE correctly and hence can rely on it for CSRF.
>
> Thanks,
> George
>
> On 1/4/22 5:45 AM, Benjamin Häublein wrote:
>
> 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:///auth?client_id=_type=code=openid+profile_uri=https://localhost
>
> Subsequent Token Request:
>
> POST /token HTTP/1.1
> Host: 
> Content-Length: 256
>
>
> code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_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/
> suggests, that neither state nor nonce are necessary when PKCE is used).
> However, when the authorization server is not configured to require

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

2022-01-05 Thread Benjamin Häublein 
Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
'code_challenge_method' on the authorization request but does send the 
'code_verifier' on the token request should consider that the client has 
implemented PKCE correctly and hence can rely on it for CSRF.
My point is not, that a client behaves that way. The problem is that an 
attacker could get a user (through social engineering) to start the 
authorization process and then click a link with an authorization response that 
the attacker provides.
Then the client has send the 'code_challenge' and 'code_challenge_method' in 
the authorization request, but the authorization response belongs to an 
authorization request that does not have these parameters.
When the client sends the token request based on the malicious authorization 
request but with the ‘code_verifier’ for the original authorization request.
When the AS behaves as described the client has no way to know that an attacker 
has interfered.

Best Regards,
Benjamin Häublein

Von: George Fletcher 
Gesendet: Dienstag, 4. Januar 2022 14:51
An: Benjamin Häublein ; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't receive a 
'code_challenge' and 'code_challenge_method' as part of the authorization 
request, they treat the request as a non-PKCE authorization request. Therefore 
when the 'code_verifier' is presented at the /token endpoint, the AS ignores 
the parameter because it doesn't consider the request to be a PKCE request. I 
can also see the AS returning an error regarding an "unexpected parameter" or 
"invalid request" error in this case.

I agree with your recommendation for the AS to require specific clients to use 
PKCE and consider an authorization request without PKCE to be an error.

Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
'code_challenge_method' on the authorization request but does send the 
'code_verifier' on the token request should consider that the client has 
implemented PKCE correctly and hence can rely on it for CSRF.

Thanks,
George

On 1/4/22 5:45 AM, Benjamin Häublein wrote:
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:///auth?client_id=_type=code=openid+profile_uri=https://localhost
Subsequent Token Request:
POST /token HTTP/1.1
Host: 
Content-Length: 256

code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_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/ 
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:

  1.  Enforce usage of PKCE in the client configuration in the Authorization 
Server
  2.  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.
  3.  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,

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

2022-01-05 Thread Daniel Fett 
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:///auth?client_id=_type=code=openid+profile_uri=https://localhost
> 
>
> Subsequent Token Request:
>
> POST /token HTTP/1.1
> Host: 
> Content-Length: 256
>
> code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_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/
> 
> 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

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

2022-01-04 Thread George Fletcher 
My guess is that for an Authorization Server that doesn't receive a 
'code_challenge' and 'code_challenge_method' as part of the 
authorization request, they treat the request as a non-PKCE 
authorization request. Therefore when the 'code_verifier' is presented 
at the /token endpoint, the AS ignores the parameter because it doesn't 
consider the request to be a PKCE request. I can also see the AS 
returning an error regarding an "unexpected parameter" or "invalid 
request" error in this case.


I agree with your recommendation for the AS to require specific clients 
to use PKCE and consider an authorization request without PKCE to be an 
error.


Finally, I'm not sure a client that doesn't send the 'code_challenge' 
and 'code_challenge_method' on the authorization request but does send 
the 'code_verifier' on the token request should consider that the client 
has implemented PKCE correctly and hence can rely on it for CSRF.


Thanks,
George


On 1/4/22 5:45 AM, Benjamin Häublein wrote:


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:///auth?client_id=_type=code=openid+profile_uri=https://localhost 



Subsequent Token Request:

POST /token HTTP/1.1
Host: 
Content-Length: 256

code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_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/ 
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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2022-01-04 Thread 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:///auth?client_id=_type=code=openid+profile_uri=https://localhost
Subsequent Token Request:
POST /token HTTP/1.1
Host: 
Content-Length: 256

code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_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/ 
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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth