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: ve7...@ve7jtb.com [mailto:ve7...@ve7jtb.com] Sent: Wednesday, July 27, 2016 5:53 AM To: nov matake; tors...@lodderstedt.net Cc: oauth@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:mat...@gmail.com"nov matake Sent: July 27, 2016 3:19 AM To: HYPERLINK "mailto:tors...@lodderstedt.net"tors...@lodderstedt.net Cc: HYPERLINK "mailto:wdenn...@google.com"William Denniss; HYPERLINK "mailto:ve7...@ve7jtb.com"John Bradley; HYPERLINK "mailto:oauth@ietf.org"oauth@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:tors...@lodderstedt.net"tors...@lodderstedt.net <HYPERLINK "mailto:tors...@lodderstedt.net"tors...@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:wdenn...@google.com"wdenn...@google.com> An: John Bradley <HYPERLINK "mailto:ve7...@ve7jtb.com"ve7...@ve7jtb.com> Cc: Oauth Wrap Wg <HYPERLINK "mailto:oauth@ietf.org"oauth@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:ve7...@ve7jtb.com"ve7...@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:ve7...@ve7jtb.com"ve7...@ve7jtb.com Sent: July 26, 2016 9:04 PM To: HYPERLINK "mailto:dick.ha...@gmail.com"Dick Hardt; HYPERLINK "mailto:oauth@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:dick.ha...@gmail.com"Dick Hardt Sent: July 26, 2016 8:15 PM To: HYPERLINK "mailto:oauth@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:OAuth@ietf.org"OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list HYPERLINK "mailto:OAuth@ietf.org"OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- nov matake
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
