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
