Researchers have found two vulnerabilities that affect both OAuth 2.0 and the OpenID Connect standards, which could...
allow attackers to bypass both authentication standards. And one expert said the flaws must be fixed in the standards themselves.
The OAuth vulnerabilities can be used to capture credentials, impersonate users or access user data, according to Daniel Fett, Ralf Küsters and Guido Schmitz, researchers at the University of Trier in Germany.
In one attack -- using an HTTP 307 Temporary Redirect status code -- the researchers described how an attacker could learn a user's credentials. An attacker could obtain the credentials when the user logs in at an identity provider (IDP) that uses the wrong HTTP redirection status code. Therefore, this inadvertently forwards user credentials to the relying party (RP) or the attacker, but this attack can be mitigated with the proper setup.
"This severe attack is caused by a logical flaw in the OAuth 2.0 protocol and depends on the presence of malicious IDP," the researchers wrote. "In practice, OAuth setups often allow for selected (and thus, hopefully trustworthy) IDPs only. In these setups, the attack would not apply."
The researchers also described a man-in-the-middle (MitM) attack, which could allow an attacker to change user data and impersonate a legitimate user to an unsuspecting RP.
To perform this attack, an adversary "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," the researchers wrote. "The RP sends the authorization 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 log in at the RP under the user's identity (managed by the honest IDP) or access the user's protected resources at the honest IDP."
The researchers said fixing either of the OAuth vulnerabilities would require changes to standards. To fix the HTTP 307 Temporary Redirect problem, researchers said only the HTTP 303 redirect status code should be permitted in OAuth, because "only the 303 redirect is defined unambiguously to drop the body of an HTTP POST request."
To fix the MitM issue, researchers proposed "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."
Liviu Itoafa, security researcher at Kaspersky Lab, confirmed that changes would need to be made to both the OAuth and HTTP standards in order to fix the vulnerabilities, but noted that the MitM attack can be difficult for attackers to pull off.
"The fix for the 307 Redirect attacks can be either in the OAuth standard or in the HTTP standard. The fix for the second attack, man in the middle, would also be done in the OAuth standard," Itoafa told SearchSecurity. "One assumption of this attack is that the attacker needs to be present in the same network as the victim, and be able to intercept and manipulate requests. This is not easy to achieve without raising other red flags. Moreover, some RPs might require the initial request be over HTTPS. Bypassing this also requires a few more social-engineering tricks."
Learn if OAuth 2.0 can strengthen authentication.
Learn how trust in OAuth can speed up app development.
Dig Deeper on Enterprise Single Sign-On (SSO)
Michael Heller asks:
Does your organization use OAuth for single sign-on?
0 ResponsesJoin the Discussion