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

[Dick Hardt]

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!

[v***@ve7jtb.com]

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

[v***@ve7jtb.com]

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.

Sent from Mail for Windows 10

From: ***@ve7jtb.com

[William Denniss]

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.

Post by v***@ve7jtb.com
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.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 9:04 PM
*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.
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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 8:15 PM
*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/
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!
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[t***@lodderstedt.net]

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

-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS

Post by William Denniss
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.

Post by v***@ve7jtb.com
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.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 9:04 PM
*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.
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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 8:15 PM
*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/
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!
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[nov matake]

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.

Post by t***@lodderstedt.net
+1
I also think PKCE is currently the simplest way to protect OAuth clients from injection.
Sent by MailWise <http://www.mail-wise.com/installation/2> – See your
emails as clean, short chats.
-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
overHTTPS
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.

Post by v***@ve7jtb.com
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.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 9:04 PM
*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.
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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 8:15 PM
*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/
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!
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

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

Post by nov matake
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.

Post by t***@lodderstedt.net
+1
I also think PKCE is currently the simplest way to protect OAuth clients from injection.
Sent by MailWise <http://www.mail-wise.com/installation/2> – See your
emails as clean, short chats.
-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even
overHTTPS
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.

Post by v***@ve7jtb.com
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.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 9:04 PM
*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.
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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *July 26, 2016 8:15 PM
*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/
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!
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
nov matake
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

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

Yeah, in a Connect "code" only flow, the nonce is optional but if the client/RP sends and checks it, that should mitigate this.
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.
+1
I also think PKCE is currently the simplest way to protect OAuth clients from injection.
Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails as clean, short chats.
-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
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.
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.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
Sent: July 26, 2016 9:04 PM
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.
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/ <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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
Sent: July 26, 2016 8:15 PM
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!
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
--
nov matake
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[v***@ve7jtb.com]

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.


Sent from Mail for Windows 10

From: nov matake

[Vivek Biswas]

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 ***@Security

Oracle.

 

From: ***@ve7jtb.com [mailto:***@ve7jtb.com]
Sent: Wednesday, July 27, 2016 5:53 AM
To: nov matake; ***@lodderstedt.net
Cc: ***@ietf.org WG
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHTTPS

 

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.

 

 

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

 

From: HYPERLINK "mailto:***@gmail.com"nov matake
Sent: July 27, 2016 3:19 AM
To: HYPERLINK "mailto:***@lodderstedt.net"***@lodderstedt.net
Cc: HYPERLINK "mailto:***@google.com"William Denniss; HYPERLINK "mailto:***@ve7jtb.com"John Bradley; HYPERLINK "mailto:***@ietf.org"***@ietf.org WG
Subject: Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents evenoverHTTPS

 

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 HYPERLINK "mailto:***@lodderstedt.net"***@lodderstedt.net <HYPERLINK "mailto:***@lodderstedt.net"***@lodderstedt.net>:

+1

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

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:***@google.com"***@google.com>
An: John Bradley <HYPERLINK "mailto:***@ve7jtb.com"***@ve7jtb.com>
Cc: Oauth Wrap Wg <HYPERLINK "mailto:***@ietf.org"***@ietf.org>

 

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, <HYPERLINK "mailto:***@ve7jtb.com"***@ve7jtb.com> 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.

 

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.

 

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

 

From: HYPERLINK "mailto:***@ve7jtb.com"***@ve7jtb.com
Sent: July 26, 2016 9:04 PM
To: HYPERLINK "mailto:***@gmail.com"Dick Hardt; HYPERLINK "mailto:***@ietf.org"Oauth Wrap Wg
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. 

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 HYPERLINK "https://go.microsoft.com/fwlink/?LinkId=550986"Mail for Windows 10

 

From: HYPERLINK "mailto:***@gmail.com"Dick Hardt
Sent: July 26, 2016 8:15 PM
To: HYPERLINK "mailto:***@ietf.org"Oauth Wrap Wg
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/

 

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 HYPERLINK "http://hardtware.com/"HARDTWARE mail list to learn about projects I am working on!

 

 


_______________________________________________
OAuth mailing list
HYPERLINK "mailto:***@ietf.org"***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
HYPERLINK "mailto:***@ietf.org"***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





 

[Stephen Farrell]

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.

Post by Dick Hardt
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!
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth