So, there has been a flurry of worries induced by the CNET and other articles [1] about “Covert Redirect”.
Like Leandro Boffi wrote in his blog post [2], this is not a new attack. It is an attack that has been known for at least 6 years.
It is very disappointing that, after this long years, there still are sites this buggy, but we have to face the reality, so I decided to do a bit of risk analysis on it and providing some recommendations.
But before all: Note that THIS IS NOT A PROTOCOL BUG per se. It is the bad implementation of the RPs.
Now, let the analysis begin:
Threats
Case 1: “redirect_uri” in full including the query parameter is an open redirector. RP really need to make sure that at least this uri is not an open redirector.
Case 2: “redirect_uri” behaves as an open redirector depending on the query component
(a) OpenID Connect is not vulnerable in this case as it MUST performs an exact match per Sec 3.2.2.1
(b) OAuth 2.0 (RFC6749) is a bit softer than this. It allows variance in the query component. However, this still means that only the URI (apart from the query component) needs to be checked by RP to be not an open redirector so it should be easy. This is not much worse than in the case of OpenID Connect.
(c) OpenID 2.0 states in section 13 mentions about RP discovery. However, it does not say SHOULD nor MUST for the OP. To avoid the open redirector problem, the OP MUST perform the RP discovery. However, this is not commonly done and for example, Google’s OpenID 2.0 implementation seems to be vulnerable. Again, the primary responsibility resides in RP: RP should not allow any open redirector in any of its path – an open redirector is bad enough without any OpenID 2.0 or other redirection based authentication capabilities.
Case 3: There is an open redirector in a uri that forward matches “redirect_uri”
(a) OpenID Connect is not vulnerable in this case as it MUST performs an exact match per Sec 3.2.2.1
(b) OAuth 2.0 (RFC6749) is not vulnerable in this case as it MUST perform a match per 6.2.1 of RFC3986 to the URI without the query component.
(c) OpenID 2.0 states in section 13 mentions about RP discovery. However, it does not say SHOULD nor MUST for the OP. To avoid the open redirector problem, the OP MUST perform the RP discovery. However, this is not commonly done and for example, Google’s OpenID 2.0 implementation seems to be vulnerable. Again, the primary responsibility resides in RP: RP should not allow any open redirector in any of its path – an open redirector is bad enough without any OpenID 2.0 or other redirection based authentication capabilities.
Case 4: The RP provides its sub path to other entities to control:
(a) OpenID Connect is not vulnerable in this case as it MUST performs an exact match per Sec 3.2.2.1
(b) OAuth 2.0 (RFC6749) is not vulnerable in this case as it MUST perform a match per 6.2.1 of RFC3986 to the URI without the query component.
(c) OpenID 2.0: Since OpenID 2.0 treats each path to be potentially different RP, if the RP provides its sub-path for a third party to control, the attacker may take advantage of this fact and creates an RP there misleading the user. RP should really think twice before providing such path to a third party while providing a valuable service in the same domain.
Risk analysis:
- If the IdP is OpenID Connect compliant, the risk should be negligible since RP is expected to check that the full redirect_uri is not an open redirector. Even if it is an open redirector, the RP MUST check the nonce and state parameter as well, so unless another injection vulnerability exists in addition or the RP is not checking nonce and state parameter (means it is likely to be XSRF vulnerable), the attacker will not succeed.
- If the server is OAuth 2.0 compliant, the risk should be low since RP is expected to check that the redirect_uri does not become an open redirector depending on some query component. Even if it is an open redirector, the RP is supposed to check the state parameter as well, so unless another injection vulnerability exists in addition or the RP is not checking state parameter (means it is XSRF vulnerable), the attacker will not succeed.
- If the server is OpenID 2.0 compliant, and if the OP performs RP discovery (and does exact match), the risk should be negligible since RP is expected to check that the full redirect_uri is not an open redirector. Note however of the (5) below.
- If the server is OpenID 2.0 compliant but does not perform RP discovery, and there is an open redirector in the RP, the risk comes from two aspects: user tracking and the attribute leakage. Note: since there is not access token equivalent in OpenID 2.0, the entire OpenID 2.0 operation is of lower risk than OAuth variants.
- The risk posed by logging into a rogue web site by itself is not much higher than that of a tracking cookie or other AD Network unless the OP uses PPID. If the OP uses PPID, the risk gets lower and is more or less equivalent as a first party cookie, which is negligible.
- If the OP supports AX, then we would have to consider the risk of attributes leaking to the attacker and the risk depends on what attributes are going to be provided to the attacker while misleading the user to think that he is providing these attributes to the domain of the redirect_uri.
- If the server is OpenID 2.0 compliant and RP lets its subpath to be controlled by a third party, then the confusion attack is possible. However, this has been well known for many years as a downside of OpenID 2.0 in exchange to the feature that allows the sub-path to be treated as an independent RP. This was an explicit feature and not a bug. In OpenID 2.0, the security domain is not the Authority section of the URI but the realm. Thus, the risk is evaluated to be less than in (4).
NOTE: The risk associated with a per site password based authentication is larger in this case because the attacker may obtain the password for the domain by confusing the user.
Recommendations:
The “covert redirect” is not a new attack. It has been there for a long time and has been called “open redirector”. Open redirector is bad for any RP to have without respect to any authentication scheme. This is an RP bug and not that of an authentication protocol. Since it is an RP bug, it should be taken care of by the RP; namely:
(1) RP must check that the redirect_uri is not an open redirector.
(2) RP should check that there is no open redirector under its control.
In addition:
(3) RP should think twice before providing its subpath to be controlled by a third party especially if it is providing something valuable in its root domain.
Although it is not the primary responsibility of the server, the server could help to protect its users from a buggy RP by:
(4) If the server is OpenID Connect compliant, the server should check its compliance to the exact match requirement. Note that if the server claims to be supporting OpenID Connect, it must adhere to the exact match requirement. Otherwise, it is infringing the OpenID trademark as well as it falls into “‘unfair or deceptive acts or practices in or affecting commerce” category facing various consumer protection related law violation.
(5) If the server is OAuth 2.0 compliant but not OpenID Connect, the server should check its compliance to the exact match requirement except for the query component. It is recommended to extend the match requirement to the query component as in OpenID Connect.
(6) If the server is OpenID 2.0, the server should perform an RP discovery. If it fails, the server should warn the user that the RP is not authenticated. Further, if the realm and the authority does not match, it should warn the user that the RP might not be the same as the entity that hosts the domain.
Final Note
As I have explained above, the vulnerability is not that of protocols but of the implementations.
I, however, need to point out that there are vulnerable implementations out there. These need to be fixed, and this is one more reason to have the deployment testing and certification — an identity trust framework.
Nat
[1] http://tetraph.com/covert_redirect/, http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/, etc.
Thanks for the link! It is very sad to hear about this kind of vulnerabilities after so many years!
You are welcome. I liked your article very much.
Indeed, it is very sad to see this kind of attack being still possible. More developer education probably through mass-media is in order, I suppose.
hope for better world