Access Token Substitution

Severity [Critical]

Description

The vulnerability is caused by the improper implementations in the RP server. In Fig. 1, right after Step 7, the RP server should compare the received user data from Step 7 with the user information from Step 3 and check the binding between itself and the access token. However, the verification is usually missing, so that the attacker can inject the stolen (network Attacker) / obtained (malicious RP attacker) access token of the victim into his own session, e.g., Step 3 in Fig. 1, to cheat the RP server into the wrong authentication.

Fig. 1
Fig. 2

Impact

The attacker can impersonate as the RP and is able to exchange the stolen code for a valid access token and further extract victim’s user profile on the IdP server with the token. In addition, since Facebook utilizes the same secret to sign the user profile, the attacker is capable of forging a valid signature to launch the profile attack.

Solution

Reference

[1] Hu, Pili, et al. "Application impersonation: problems of OAuth and API design in online social networks." Proceedings of the second ACM conference on Online social networks. ACM, 2014.