!!! Overview[1][2]
[{$pagename}] (may be referred to as [Covert Redirect] or [open redirect]) are possible when a [web] [application] accepts untrusted input that could cause the web application to redirect the request to a [URL] contained within untrusted input. [{$pagename}] is a [Security Consideration] and [Privacy Consideration] for any [Website] or [Web] [Application][{$pagename}]s happen when [URI Query] values (the portion of URL after "?") in an [HTTP GET] allow for information that will redirect a user to a new [website] without any validation of the target of [redirect|URL redirection]. 

By modifying untrusted [URL] input to a malicious site, an [attacker] may successfully launch a [phishing] scam and steal user [credentials]. 

Because the server name in the modified link is identical to the original site, [phishing] attempts may have a more trustworthy appearance. 

[{$pagename}] and forward attacks can also be used to maliciously craft a [URL] that would pass the [Application]'s [Access Control] check and then forward the [attacker] to privileged functions that they would normally not be able to access.!! [{$pagename}] and [Phishing]
When an Open Redirect is used in a [phishing] [attack], the victim receives an email that looks legitimate with a link that points to a correct and expected [DNS Domain]. What the victim may not notice, is that in a middle of a long [URL] there are parameters that manipulate and change where the link will take them. To make identification of the Open Redirect even more difficult, redirection could take place after victim provides login on a legitimate website first. Attackers have found that an effective way to trick a victim is to [redirect|URL redirection] him to a fake website after they enter their [credentials] on a legitimate page. The fake website would look identical to a legitimate [website], and it would ask the victim to re-enter their password. After the victim re-enters their password it would be recorded by the attacker and victim would be redirected back to a valid [website]. If done correctly, victim would think that he mistyped [password] once and would not notice that his username and [password] were stolen.

Phishing is used in most successful targeted hacks and also regularly in opportunistic attacks. Considering how prominent phishing is in our daily lives, Open Redirect vulnerabilities should not be dismissed.

!! [Attacks] via the [HTTP Referer] [HTTP Request Header][3]
As described in the previous section, the injection point for the [Open redirect] in Moodle was the [HTTP Referer] header.  A lot of countermeasures do not implement any restriction or validation for this injection point. It’s recommended to do what Moodle did — prevent redirection to non-local websites.

According to my survey, most [Websites] [applications] do not allow [Cross-domain] redirections intentionally. If that is the case, developers should implement robust input [validation] strategies, which will decline or rewrite all the [URL redirection] requests to different domains. If you want to make redirection under several domains, it is a good practice to add the [DNS Domains] in the whitelist and only allow redirection to the links originating from these whitelists. If you have to make redirection to some [Third-party] [websites], it is important to clearly remind the users that they are being redirected to a [Third-party] [website].[4]!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Unvalidated Redirects and Forwards Cheat Sheet|https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md|target='_blank'] - based on information obtained 2019-06-29 
* [#2] - [CWE-601: URL Redirection to Untrusted Site ('Open Redirect')|https://cwe.mitre.org/data/definitions/601.html|target='_blank'] - based on information obtained 2018-03-21- 
* [#3] - [Understanding and Discovering Open Redirect Vulnerabilities|https://www.trustwave.com/Resources/SpiderLabs-Blog/Understanding-and-Discovering-Open-Redirect-Vulnerabilities/|target='_blank'] - based on information obtained 2018-03-21- 
* [#4] - [How Open Redirection Threatens Your Web Applications|https://blog.qualys.com/securitylabs/2016/01/07/open-redirection-a-simple-vulnerability-threatens-your-web-applications|target='_blank'] - based on information obtained 2018-03-21- 
* [#5] - [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-