This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Covert Redirect Vulnerability
Covert Redirect Vulnerability

Version management

Difference between version and

At line 1 added 56 lines
!!! Overview[1][2]
[{$pagename}] 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|URL redirection]."
[{$pagename}] 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]
[{$pagename}] 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|Data Leakage]. Note: since there is no [access Token] equivalent in [OpenID Connect], the entire [OpenID Connect] 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 [Data Leakage] 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].
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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [OAuth 2 and Fragment encoding|http://www.thread-safe.com/2014/05/oauth-2-and-fragment-encoding.html|target='_blank'] - based on information obtained 2018-03-04
* [#2] - [OAuth Security Advisory: 2014.1 "Covert Redirect"|https://oauth.net/advisories/2014-1-covert-redirect/|target='_blank'] - based on information obtained 2018-03-04
* [#3] - [Covert Redirect is not new but|https://nat.sakimura.org/2014/05/08/covert-redirect-is-not-new/|target='_blank'] - based on information obtained 2018-03-21-
* [#4] - [Insufficient Redirect URI Validation|https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.1|target='_blank'] - based on information obtained 2019-12-24
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop