XS-Leak in Single Sign-On Redirects

Idea:

Although the Same Origin Policy restricts the access to the response of a cross-origin request, we can use a XS-Leak to determine some information about the response. In this case, we can determine if a redirect was performed or not. This is used in this attack to check if the Authentication Response in OAuth/OIDC actually results in a 302 redirect (which is the case if the victim already used OAuth/OIDC on the SP) or in the return of the consent page (which is the case if the victim did not use OAuth/OIDC on the SP before). Thus, the attacker can check if the victim has an account (using OAuth/OIDC) on any of the tested SPs. In addition, the attacker can start an authentication flow with the login_hint=victim@example.com parameter. If the currently active user on the attacker's website is the victim, the victim is logged in on the IdP, and the victim did give consent to at least one of the tested SPs, i.e., which can be a list of the most-commonly used SPs, the Authentication Response results in an immediate redirect and the attacker can deanonymize the currently active user as victim@example.com. If the currently active user is another person not targeted (i.e., alice@example.com), the Authentication Response does not result in a redirect (because of the unmatched login_hint) and the attacker knows that the currently active user is not the victim.

Requirements:


Identity Leakage Attack

Is the currently active user ?

Result:


Account Leakage Attack

Service Provider Identity Provider Victim has account?