The OAuth 2.0 authentication protocol is widely used on social networking sites, every day billion of users access their profiles on Facebook and Google+ using it.
According to researchers Daniel Fett, Ralf Küsters and Guido Schmitz from the University of Trier, the protocol is affected by a couple of vulnerabilities that could be exploited by attackers to subvert single sign-on authentication capturing login credentials to impersonate a user.
The researchers described a couple of attack scenarios, in the first one known as “the HTTP 307 Temporary Redirect” the identity providers (IdP) inadvertently forward user credentials (ie, username and password) to the relying party (RP) or the attacker, in the second scenario the attacker can impersonate the victim.
“While trying to prove these properties, we discovered two previously unknown attacks on OAuth, which both break authorization as well as authentication. In the first attack, IdPs inadvertently forward user credentials (i.e., username and password) to the RP or the attacker. In the second attack, a network attacker can impersonate any victim. This severe attack is caused by a logical flaw in the OAuth 2.0 protocol and depends on the presence of malicious IdP. In practice, OAuth setups often allow for selected (and thus hopefully trustworthy) IdPs only. In these setups the attack would not apply. The attack, however, can be exploited in OpenID Connect, which, as mentioned, builds directly on OAuth” reads the paper published by the researchers.
When dealing with the “the HTTP 307 Temporary Redirect” attack scenario the researchers explained that an attacker can exploit the flaws to capture the user’s credentials when access an identity provider.
“In this attack, the attacker (running a malicious RP) learns the user’s credentials when the user logs in at an IdP that uses the wrong HTTP redirection status code.”
The experts suggest to permit only HTTP 303 codes in OAuth to solve the issue, since “the 303 redirect is defined unambiguously to drop the body of an HTTP POST request”.
In a second attack scenario, dubbed : IdP Mix-Up, the attacker confuses an RP about which IdP the user chose at the beginning of the authorisation process, in this way he can steal an authentication code or access token and impersonate the victim. The attacker run a man-in-the-middle (MitM) attack on the IdP to obtain the authorisation code or the access token.
“In this attack, the attacker confuses an RP about which IdP the user chose at the beginning of the login/authorization process in order to acquire an authentication code or access token which can be used to impersonate the user or access user data.”
“As a result, the RP sends the authorisation code or the access token (depending on the OAuth mode) issued by the honest IdP to the attacker, who then can use these values to login at the RP under the user’s identity (managed by the honest IdP) or access the user’s protected resources at the honest IdP.”
Also in this case the researchers provided a suggestion to fix the issue, OAuth has to include the identity of the IdP in the redirect.
“More specifically, we propose that RPs provide a unique redirection endpoint for each IdP. Hence, the information which IdP redirected the browser to the RP is encoded in the request and the RP can detect a mismatch.”
As for future work, the researchers will conduct a formal analysis of OpenID Connect.
(Security Affairs – oAuth 2.0, digital identity)
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.