jspωiki
Unvalidated redirects and forwards

Overview[1][2]#

Unvalidated redirects and forwards (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.

Unvalidated redirects and forwards is a Security Consideration and Privacy Consideration for any Website or Web Application

Unvalidated redirects and forwardss 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.

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.

Unvalidated redirects and forwards 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.

Unvalidated redirects and forwards 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 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: