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

[Nat Sakimura <[e-mail]>]

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 <[e-mail]>:

> 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 <[e-mail]> 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 <[e-mail]>:
>
>> 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
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>