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 <mat...@gmail.com> 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? > > In pure OAuth2 senario, I also think PKCE would be the simplest solution. > > 2016-07-27 15:45 GMT+09:00 tors...@lodderstedt.net < > tors...@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 >> Von: William Denniss <wdenn...@google.com> >> An: John Bradley <ve7...@ve7jtb.com> >> Cc: Oauth Wrap Wg <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, <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 Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for >>> Windows 10 >>> >>> >>> >>> *From: *ve7...@ve7jtb.com >>> *Sent: *July 26, 2016 9:04 PM >>> *To: *Dick Hardt <dick.ha...@gmail.com>; Oauth Wrap Wg <oauth@ietf.org> >>> *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 >>> >>> >>> >>> *From: *Dick Hardt <dick.ha...@gmail.com> >>> *Sent: *July 26, 2016 8:15 PM >>> *To: *Oauth Wrap Wg <oauth@ietf.org> >>> *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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
