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
