Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

But that's cut-n-paste protection using "state" token endpoint parameter,
is it not?

2016年1月29日(金) 14:14 Phil Hunt (IDM) <phil.hunt@oracle.com>:

> We discussed that redirecr helps but we wanted the Token endpoint to also
> be able to detect assuming many client devs won't implement the check.
>
>
> Phil
>
> On Jan 28, 2016, at 20:54, Nat Sakimura <sakimura@gmail.com> wrote:
>
> My preferred way of dealing with mix-up has been to use separate
> redirection URI but your using issuer instead is for the backward
> compatibility?
>
> Nat
>
> 2016年1月29日(金) 2:53 John Bradley <ve7jtb@ve7jtb.com>:
>
>> Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01
>> will stop this attack.
>>
>> White listing AS seems tempting, but is just sweeping the problem
>> partially under the rug.
>> There are probably good policy reasons to whitelist AS but
>> we shouldn’t let this AS mixup be one of them.
>>
>> John B.
>>
>> On Jan 27, 2016, at 10:42 PM, Nat Sakimura <sakimura@gmail.com> wrote:
>>
>> I see. That's like double cut-n-paste.
>>
>> I tried to capture this case of used-to-be-good AS turning Compromised AS
>> (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
>>
>> Given this, just relying on not using random AS is not good enough. You
>> would probably require AS w/ISMS with the policy of not logging un-masked
>> credentials and has strict access control on the log ;-)
>>
>> Nat
>>
>> 2016年1月28日(木) 9:38 Hans Zandbelt <hzandbelt@pingidentity.com>:
>>
>>> indeed, if the attacker is able to phish the user, he can put up a
>>> script that first triggers the authorization request to the compromised
>>> AS (i.e. the AS at which he has access to the logs and gathers the state
>>> value from) through the Client, and subsequently trigger the redirect to
>>> the good AS using an auto-refresh of that same phishing page (with the
>>> stolen state value); no need to control the authorization endpoint of
>>> the compromised AS itself
>>>
>>> Hans.
>>>
>>> _______________________________________________
>> 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
>
>