Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS

From: Dick Hardt <[email-masked]>
Date: Tue, 26 Jul 2016 17:15:21 -0700

http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/

Access tokens included as a URL query parameter when accessing a resource
are susceptible to this attack.

Authorization codes are also visible. From what I know, we have not
depended on the confidentiality of the authorization code.

What are the best current practices that we can point people towards to
ensure they are not susceptible to this attack?

-- Dick
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!

---

From: <[email-masked]>
Date: Tue, 26 Jul 2016 21:04:08 -0400

I need to think about it a bit,  however off the top of my head based on the attack described the code flow should still be safe if the code is truly single use.   (Some implementations fudge that)

If the attacker can stop the browser from delivering the code to the client then the client would be susceptible to the cut and paste attack for injecting the code back into the client.  

The OpenID Connect “code id_token” flow is not vulnerable to this if the client is properly validating the id_token.

I suspect that this would work against the implicit flow if the JS is sending the code back to its web server via a GET.  
That I think we recommend against doing, or should.

The Token binding proposals would stop a leaked code from being used, but not from being stolen in this attack.

The attack against a confidential client would be the cut and paste one that we have identified.  Currently the only mitigation we have is “code id_token”  so the blog post at.
http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/

I the most relevant current advice.
The thing to add is that the code leaked in this way should not be repayable at the client 

I don’t think that native apps are vulnerable to this if they are using custom scheme redirects.  

I don’t know what the risk is if they are using loopback or claimed URI.  It may be that a browser might leak them in the same way. 
That would need to be tested.

John B.

Sent from Mail for Windows 10

From: Dick Hardt

---

From: <[email-masked]>
Date: Tue, 26 Jul 2016 21:11:36 -0400

PS   Using PKCE S256 would prevent this attack on web server clients, as long as the client uses a different PKCE vale for each request.    Even if the attacker can observe both the request and response, they would not have the code_verifyer and if replaying the code to the client the client will use the wrong verifier value to exchange the code and will get an error.

That is probably the simplest mitigation against this for the code flow on web servers and native apps.

I will think about it overnight.

John B.

From: [email-masked]

---

From: William Denniss <[email-masked]>
Date: Tue, 26 Jul 2016 18:18:05 -0700

PKCE S256 was indeed designed to protect against eavesdropping of both the
authorization request & response.  It was originally created for native
apps where URL leakage was deemed more likely (since it goes over
inter-process communication channels), perhaps the practice should be
expanded to all clients.

On Tue, Jul 26, 2016 at 6:11 PM, <[email-masked]> wrote:

> PS   Using PKCE S256 would prevent this attack on web server clients, as
> long as the client uses a different PKCE vale for each request.    Even if
> the attacker can observe both the request and response, they would not have
> the code_verifyer and if replaying the code to the client the client will
> use the wrong verifier value to exchange the code and will get an error.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: [email-masked]
> *Sent: *July 26, 2016 9:04 PM
> *To: *Dick Hardt <[email-masked]>; Oauth Wrap Wg <[email-masked]>
> *Subject: *RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
> overHTTPS
>
>
>
> I need to think about it a bit,  however off the top of my head based on
> the attack described the code flow should still be safe if the code is
> truly single use.   (Some implementations fudge that)
>
>
>
> If the attacker can stop the browser from delivering the code to the
> client then the client would be susceptible to the cut and paste attack for
> injecting the code back into the client.
>
>
>
> The OpenID Connect “code id_token” flow is not vulnerable to this if the
> client is properly validating the id_token.
>
>
>
> I suspect that this would work against the implicit flow if the JS is
> sending the code back to its web server via a GET.
>
> The attack against a confidential client would be the cut and paste one
> that we have identified.  Currently the only mitigation we have is “code
> id_token”  so the blog post at.
>
> I don’t know what the risk is if they are using loopback or claimed URI.
> It may be that a browser might leak them in the same way.
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Dick Hardt <[email-masked]>
> *Sent: *July 26, 2016 8:15 PM
> *To: *Oauth Wrap Wg <[email-masked]>
> *Subject: *[OAUTH-WG] URGENT: WPAD attack exposes URL contents even over
> HTTPS
>
>
>
>
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn
> about projects I am working on!
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 27 Jul 2016 08:45:42 +0200

+1

I also think PKCE is currently the simplest way to protect OAuth clients from injection.

Sent by MailWise – See your emails as clean, short chats.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 27 Jul 2016 08:45:42 +0200

+1

---

From: nov matake <[email-masked]>
Date: Wed, 27 Jul 2016 16:19:30 +0900

In Connect, if RP verifies nonce value in ID Token issued from Token
Endpoint, code cut & paste attack can be mitigated in "code" flow, not in
"code id_token", can't it?

In pure OAuth2 senario, I also think PKCE would be the simplest solution.

2016-07-27 15:45 GMT+09:00 [email-masked] <[email-masked]>
:

> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your
> emails as clean, short chats.
>
>

-- 
nov matake

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Jul 2016 09:00:41 +0100

Is there any information as to what percentage of browsers have a
vulnerable configuration? That's not clear to me and seems relevant.
My impression was that wpad wasn't that widely enabled in browsers
nowadays, but that may well be wrong.

S.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Jul 2016 06:21:10 -0600

Yeah, in a Connect "code" only flow, the nonce is optional but if the
client/RP sends and checks it, that should mitigate this.

On Wed, Jul 27, 2016 at 1:19 AM, nov matake <[email-masked]> wrote:

> 2016-07-27 15:45 GMT+09:00 [email-masked] <
> [email-masked]>:
>
>> +1
>>
>> PKCE S256 was indeed designed to protect against eavesdropping of both
>> the authorization request & response.  It was originally created for native
>>> The Token binding proposals would stop a leaked code from being used,
>>> but not from being stolen in this attack.
>>>
>>>
>>>
>>> I don’t know what the risk is if they are using loopback or claimed
>>> URI.  It may be that a browser might leak them in the same way.
>>>
>>> *Subject: *[OAUTH-WG] URGENT: WPAD attack exposes URL contents even
>>> over HTTPS
>>>
>>>
>>>
>>>
>>> Access tokens included as a URL query parameter when accessing a
>>> resource are susceptible to this attack.
>>>
>>>
>>>

---

From: <[email-masked]>
Date: Wed, 27 Jul 2016 08:52:58 -0400

With the mix up attack we assumed that the attacker is able to modify the request.   In that case checking nonce in the code flow is not sufficient as the attacker can modify nonce. 

In this attack the attacker as I understand it can only view request and response, so checking nonce in code will prevent the paste of the code.   Unfortunately (Torsten) checking nonce in the code flow is optional.

What I  don’t know is if there is a variation of the attack where the client uses the attackers proxy and the attacker can modify the request.

One other mitigation is to use the Connect post response mode.  That would stop the code leak as long as the client is not going through the proxy. 

Post response mode to stop referrer leaking etc is looking like a good idea in general.

PKCE S256 still seems like the best idea.  However if a browser is using a malicious proxy that could also probably be circumvented.
Basically in that situation the attacker has access to cookies etc so OAuth may not be the largest problem.

John B.

From: nov matake

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 Jul 2016 16:23:48 -0400

I’ve been thinking that we could, in some eventual rewrite of OAuth and its kin, collapse the “state”, “nonce”, and “code_challenge” values all into a single thing. They’re all serving similar purposes but being used differently. There was even talk of replaying the “state” value at the token endpoint, just like we do with PKCE “plain”. So why not just use them all together? Like so:

Client creates a value, we’ll call it the “request_tag” because I want something that doesn’t sound like any of the existing values on its own and I don’t care what it’s actually called in the long run. Client stores this for later use.

Client sends a request to the AS front channel and hashes the request_tag in that request, let’s call this “request_hash”. Client also sends a kind of “request_hash_method” to tell the AS how it hashed things. [This functions just like the code_challenge_method today.]

AS returns to the client front channel and includes the request_hash. [This functions just like state today.] The client can verify this hash using its stored tag.

	- If AS is doing implicit OIDC, it adds the request_hash to the ID Token here. [This functions just like nonce today.] The client can verify this hash using its stored tag.

If the client is doing code flow, it now talks to the token endpoint and includes the request_tag in its request. [This functions just like code_verifier and the proposed include-the-state-in-token-request mitigation.] The AS can verify this tag against its stored hash.

	- If the AS is doing code OIDC, it adds the request_hash to the ID token value here. [This functions just like nonce today.] The client can verify this hash using its stored tag.

The token response can include the request_hash in its response JSON, because why not.

Yes I realize this requires redoing a lot of plumbing, but if we get to this point with the protocol I think this would be simpler than the functional patchwork we’ve got going right now.

 — Justin

> On Jul 27, 2016, at 8:21 AM, Brian Campbell <[email-masked]> wrote:
> 
> Yeah, in a Connect "code" only flow, the nonce is optional but if the client/RP sends and checks it, that should mitigate this. 
> 
> On Wed, Jul 27, 2016 at 1:19 AM, nov matake <[email-masked] <mailto:[email-masked]>> wrote:
> In Connect, if RP verifies nonce value in ID Token issued from Token Endpoint, code cut & paste attack can be mitigated in "code" flow, not in "code id_token", can't it?
> 
> 2016-07-27 15:45 GMT+09:00 [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>:
> +1
> 
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails as clean, short chats.
> 
> 
> 
> Von: William Denniss <[email-masked] <mailto:[email-masked]>>
> An: John Bradley <[email-masked] <mailto:[email-masked]>>
> Cc: Oauth Wrap Wg <[email-masked] <mailto:[email-masked]>>
> 
> 
> PKCE S256 was indeed designed to protect against eavesdropping of both the authorization request & response.  It was originally created for native apps where URL leakage was deemed more likely (since it goes over inter-process communication channels), perhaps the practice should be expanded to all clients.
> 
> On Tue, Jul 26, 2016 at 6:11 PM, <[email-masked] <mailto:[email-masked]>> wrote:
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
>  
> 
> From: [email-masked] <mailto:[email-masked]>
> Sent: July 26, 2016 9:04 PM
> To: Dick Hardt <mailto:[email-masked]>; Oauth Wrap Wg <mailto:[email-masked]>
> Subject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
> 
>  
> 
> http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/ <http://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/>
>  
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
>  
> 
> From: Dick Hardt <mailto:[email-masked]>
> Sent: July 26, 2016 8:15 PM
> To: Oauth Wrap Wg <mailto:[email-masked]>
> Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS
> 
>  
> 
> http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/ <http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/>
>  
> 
> Access tokens included as a URL query parameter when accessing a resource are susceptible to this attack.
> 
>  
> 
> Authorization codes are also visible. From what I know, we have not depended on the confidentiality of the authorization code. 
> 
>  
> 
> What are the best current practices that we can point people towards to ensure they are not susceptible to this attack?
> 
>  
> 
> -- Dick 
> 
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!
> 
>  
> 
>  
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> 
> -- 
> nov matake
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Vivek Biswas <[email-masked]>
Date: Thu, 28 Jul 2016 15:38:35 -0700 (PDT)

PKCE256 becomes mandatory in that case. PKCE plain is prone to same attack as that of state or none.

Also PKCE256 should generate new code challenge for every Authorization request.

-Vivek Biswas

Consulting Member@Security

Oracle.

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2016 5:53 AM
To: nov matake; [email-masked]
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHTTPS

John B.

Sent from HYPERLINK "https://go.microsoft.com/fwlink/?LinkId=550986"Mail for Windows 10

From: HYPERLINK "mailto:[email-masked]"nov matake
Sent: July 27, 2016 3:19 AM
To: HYPERLINK "mailto:[email-masked]"[email-masked]
Cc: HYPERLINK "mailto:[email-masked]"William Denniss; HYPERLINK "mailto:[email-masked]"John Bradley; HYPERLINK "mailto:[email-masked]"[email-masked] WG
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHTTPS

2016-07-27 15:45 GMT+09:00 HYPERLINK "mailto:[email-masked]"[email-masked] <HYPERLINK "mailto:[email-masked]"[email-masked]>:

+1

Sent by HYPERLINK "http://www.mail-wise.com/installation/2"MailWise – See your emails as clean, short chats.

-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
Von: William Denniss <HYPERLINK "mailto:[email-masked]"[email-masked]>
An: John Bradley <HYPERLINK "mailto:[email-masked]"[email-masked]>
Cc: Oauth Wrap Wg <HYPERLINK "mailto:[email-masked]"[email-masked]>

On Tue, Jul 26, 2016 at 6:11 PM, <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

John B.

Sent from HYPERLINK "https://go.microsoft.com/fwlink/?LinkId=550986"Mail for Windows 10

From: HYPERLINK "mailto:[email-masked]"[email-masked]
Sent: July 26, 2016 9:04 PM
To: HYPERLINK "mailto:[email-masked]"Dick Hardt; HYPERLINK "mailto:[email-masked]"Oauth Wrap Wg
Subject: RE: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS

John B.

Sent from HYPERLINK "https://go.microsoft.com/fwlink/?LinkId=550986"Mail for Windows 10

From: HYPERLINK "mailto:[email-masked]"Dick Hardt
Sent: July 26, 2016 8:15 PM
To: HYPERLINK "mailto:[email-masked]"Oauth Wrap Wg
Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS

-- Dick 

Subscribe to the HYPERLINK "http://hardtware.com/"HARDTWARE mail list to learn about projects I am working on!

_______________________________________________
OAuth mailing list
HYPERLINK "mailto:[email-masked]"[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
HYPERLINK "mailto:[email-masked]"[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

-- 

nov matake