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

Reply via email to