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 > <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 > <mailto: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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
