OAuth 2.0 Vulnerabilities

Overview [2]#

Attackers both "white-Hat and others will find the Vulnerability of all systems.

Without a doubt, the biggest weaknesses in OAuth 2.0 reside within the implementation details.

Beyond that, a few OAuth 2.0 Vulnerabilities have been discovered and are worth mentioning.

OAuth 2.0 Controversy [4]#

In July 2012, Eran Hammer resigned his role of lead author for the OAuth 2.0 project, withdrew from the IETF working group, and removed his name from the specification.

Since then Eran Hammer has become a potty mouthed bitter individual. His posts must be considered adult material.

General Guidelines#

You should be using the Authorization Code Grant if it is a server based client.

There are some issues Browser JS, For the moment the only standard for the in browser client is fragment encoding. In the future we hope to have more modern methods based on post message.

For people using openID Connect who want a Identity Token in the Hybrid Flow they should use the form post response mode. Browsers now re-append fragments across HTTP 302 URL redirection unless they are explicitly cleared this makes fragment encoding less safe than it was when originally specified.

Do NOT use HTTP GET for Authorization Response (from Authorization Server) which has Data Leakage issues. OpenID Connect OpenID Connect formally defined a HTTP POST response mode.

A Comprehensive Formal Security Analysis of OAuth 2.0[3]#

A Comprehensive Formal Security Analysis of OAuth 2.0 (FETT) was performed by Daniel Fett, Ralf Küsters, Guido Schmitz in which they summarize:

The OAuth 2.0 protocol is one of the most widely deployed authorization/single sign-on (SSO) protocols and also serves as the foundation for the new SSO standard OpenID Connect. Despite the popularity of OAuth, so far analysis efforts were mostly targeted at finding bugs in specific implementations and were based on formal models which abstract from many web features or did not provide a formal treatment at all. In this paper, we carry out the first extensive formal analysis of the OAuth 2.0 standard in an expressive web model. Our analysis aims at establishing strong authorization, authentication, and session integrity guarantees, for which we provide formal definitions. In our formal analysis, all four OAuth Grant Types (authorization code grant, implicit grant, resource Owner Password Credentials Grant, and the client Credentials Grant) are covered. They may even run simultaneously in the same and different relying parties and Identity Provider (IDP), where malicious relying parties, identity providers, and browsers are considered as well. Our modeling and analysis of the OAuth 2.0 standard assumes that security recommendations and Best Practices are followed, in order to avoid obvious and known attacks.

When proving the security of OAuth in our model, we discovered four attacks which break the security of OAuth. The vulnerabilities can be exploited in practice and are present also in OpenID Connect. We propose fixes for the identified vulnerabilities, and then, for the first time, actually prove the security of OAuth in an expressive web model. In particular, we show that the fixed version of OAuth (with security recommendations and best Practices in place) provides the authorization, authentication, and session integrity properties we specify.

The most prevalent Attacks was a related to Malicious Endpoints

Four Attacks on OAuth – How to Secure Your OAuth Implementation#

Although primarly aimed at the OAUth] 1 implementations there are some that need to be looked at for the OAuth 2.0.

Lack Of Data Confidentiality and Server Trust [2]#

The paper[2] discusses several items relating to the protocol not insisting on the use of TLS/HTTPS. Of course everyone should use TLS/HTTPS.

Insecure Storage of Secrets[2]#

This is a real implementation issue and a lot of discussions on the Insecure Storage of Secrets is present in the forums are on this subject. The paper[2] does provide several good suggestions.

Attack: HTTP 307 URL redirection[1]#

In this attack, the Attacker (running a malicious Relying Party) learns the user’s credentials when the user logs in at an Identity Provider (IDP) that uses the wrong HTTP redirection status code.

The Attack: HTTP 307 URL redirection attack applies to the Authorization Code Grant mode and the Implicit Grant of OAuth 2.0. (more of the Malicious Endpoints theme)

Fix#

The fix it to be certain that OAuth 2.0 implementations require HTTP 303 redirects for the steps mentioned above in order to fix this problem.

Attack: Identity Provider (IDP) Mix-Up[1]#

The attacker confuses an Relying Party about which Identity Provider (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.

Just as the previous attack, the Identity Provider (IDP) mix-up attack applies to the Authorization Code Grant mode and the Implicit Grant of OAuth 2.0. (more of the Malicious Endpoints theme)

To launch the attack, the attacker manipulates the first request of the user such that the Relying Party thinks that the user wants to use an identity managed by an Identity Provider (IDP) of the attacker while the user instead wishes to use her identity managed by an honest Identity Provider (IDP). As a result, the Relying Party sends the authorization code or the access token (depending on the OAuth mode) issued by the honest Identity Provider (IDP) to the attacker, who then can use these values to login at the Relying Party under the user’s identity (managed by the honest Identity Provider (IDP)) or access the user’s protected resources at the honest Identity Provider (IDP).

Fix#

A fundamental problem in the Implicit Grant of the OAuth 2.0 standard (and similarly for the Authorization Code Grant) is that the redirect in Steps 6 and 7 in Figure 2 does not contain information from where the redirect was initiated. And hence, the RP cannot check whether the information contained in the redirect stems from the IdP that was indicated in Step 1. (This attack is fairly sophisticated and details will not be detailed here. See the reference [1])

Our fix therefore is to include the identity of the Identity Provider (IDP) in the redirect in some form. More specifically, we propose that Relying Partys provide a unique redirection endpoint for each Identity Provider (IDP). Hence, the information which Identity Provider (IDP) redirects the browser to the Relying Party is encoded in the request and the Relying Party can detect a mismatch.[1]

The communication at this point in the protocol is secured with HTTPS (as when following the OAuth security recommendations) and cannot be manipulated by the attacker.
Note that the communication at this point in the protocol is secured with HTTPS (when following the OAuth security recommendations) and cannot be manipulated by the attacker.

We show in Section 5 that this fix is indeed sufficient. In addition, one could try to prevent the Identity Provider (IDP) mix-up directly at the beginning of the protocol. (Nonetheless, in any case the Relying Party should be able to check consistency in Step 7) We have not considered such additional countermeasures because, as we show, our fix is sufficient for the security of OAuth 2.0 (as far as authorization and authentication goes).

An Internet Draft OAuth 2.0 Mix-Up Mitigation has been presented.

Implications to OpenID Connect [1]#

Both, the 307 redirect attack and the Identity Provider (IDP) mix-up attack, can be applied to OpenID Connect as well.

More Information#

There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!