Covert Redirect Vulnerability

Overview[1][2]#

Covert Redirect Vulnerability is a Vulnerability based on the premise that "The fragment is not passed to the server as part of the URI so the server could not include it in a redirect."

Covert Redirect Vulnerability is part of a broader Security Consideration concerning Unvalidated redirects and forwards

However, some browsers (User-agents) have changed their behavior to preserve to append the URI Fragment Identifiers to the new URI from the Location HTTP Header Field of a HTTP 302 redirect if it did not contain a URI Fragment Identifiers.

OAuth 2.0 and OpenID Connect#

Covert Redirect Vulnerability describes a process where a malicious attacker intercepts a request from an OAuth Client to an OAuth 2.0 Authorization Server and alters a URI Query parameter in the request called "redirect_uri" with the intention of causing the Authorization Server to direct the resulting OAuth Response to a malicious location rather than to the originally requesting OAuth Client, thus exposing any returned secrets to the attacker. The OAuth 2.0 Threat Model and Security Configurations section-4.2.4 and OAuth 2.0 Security-Closing Open Redirectors in OAuth provides advice.

Risk Assessment [3]#

1 If the Identity Provider (IDP) is OpenID Connect compliant, the risk should be negligible since Relying Party is expected to check that the full redirect_uri is not an open redirect. Even if it is an open redirect, the Relying Party MUST check the nonce and OAuth state parameter as well, so unless another injection vulnerability exists in addition or the Relying Party is not Validation nonce and OAuth state parameter (means it is likely to be XSRF vulnerable), the attacker will not succeed.

2 If the server is OAuth 2.0 compliant, the risk should be low since Relying Party is expected to check that the redirect_uri does not become an open redirect depending on some URI Query component. Even if it is an open redirect, the Relying Party is supposed to check the OAuth 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.

3 If the server is OpenID Connect compliant, and if the OpenID Connect Provider performs Relying Party discovery (and does exact match), the risk should be negligible since Relying Party is expected to check that the full redirect_uri is not an open redirector.

4 If the server is OpenID Connect compliant but does not perform Relying Party discovery, and there is an open redirect in the Relying Party, the risk comes from two aspects: user tracking and the attribute leakage. Note: since there is no access Token equivalent in OpenID Connect, the entire OpenID Connect operation is of lower risk than OAuth variants.

5 If the server is OpenID Connect compliant and Relying Party 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 Connect in exchange to the feature that allows the sub-path to be treated as an independent Relying Party. This was an explicit feature and not a bug. In OpenID Connect, 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.

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!