+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 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
