But that's cut-n-paste protection using "state" token endpoint parameter, is it not?
2016年1月29日(金) 14:14 Phil Hunt (IDM) <phil.h...@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 <sakim...@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 <ve7...@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 <sakim...@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 <hzandb...@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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
