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
