RESEARCH REPORT
ON
OPEN REDIRECTION
VULNERABILITY
• An open redirect vulnerability occurs when an application
allows a user to control a redirect or forward to another
URL. If the app does not validate untrusted user input, an
attacker could supply a URL that redirects an unsuspecting
victim from a legitimate domain to an attacker’s phishing
site.
• Attackers exploit open redirects to add credibility to their
phishing attacks. Most users see the legitimate, trusted
domain, but do not notice the redirection to the phishing
site.
• Although this vulnerability doesn’t always directly impact
the legitimate application, the company's reputation can be
negatively impacted. In addition, open redirects may not
seem like a high impact on the organization itself, it’s
important to avoid damaging the trust users have in the
business. It’s worth noting, an open redirect in your own
site may very well be used against your own employees!
Remediation
If possible, applications should avoid incorporating user-
controllable data into redirection targets. In many cases, this
behavior can be avoided in two ways:
• Remove the redirection function from the application,
and replace links to it with direct links to the relevant
target URLs.
• Maintain a server-side list of all URLs that are permitted
for redirection. Instead of passing the target URL as a
parameter to the redirector, pass an index into this list.
If it is considered unavoidable for the redirection function to
receive user-controllable input and incorporate this into the
redirection target, one of the following measures should be used
to minimize the risk of redirection attacks:
• The application should use relative URLs in all of its
redirects, and the redirection function should strictly
validate that the URL received is a relative URL.
• The application should use URLs relative to the web root for
all of its redirects, and the redirection function should
validate that the URL received starts with a slash
character. It should then prepend
http://yourdomainname.com to the URL before issuing the
redirect.
• The application should use absolute URLs for all of its
redirects, and the redirection function should verify that the
user-supplied URL begins with
http://yourdomainname.com/ before issuing the redirect.
Vulnerability Classification
• CWE-601: URL Redirection to Untrusted Site ('Open
Redirect')
Severity
• Low.
Example
For example, if your domain is example.com, the attacker may
create the following URL:
https://example.com/redirect.php?url=http://attacker.com
The attacker may then send this URL as part of a phishing attempt
to redirect the victim to a malicious website attacker.com. The
attacker would be hoping that example.com at the beginning will
have a trustworthy appearance and make them fall for the
phishing scam.
The following simple PHP code creates an open redirect:
$redirect = $_GET['url']; header("Location: " . $redirect);
This is an open redirection vulnerability because the attacker may
supply a malicious website URL in the url parameter value of the
GET request and this target URL will then be sent as
the Location header, redirecting the client to a malicious web
page.
Reference
• https://www.acunetix.com/blog/web-security-
zone/what-are-open-redirects/
• https://portswigger.net/kb/issues/00500100_open-
redirection-reflected
• https://learn.snyk.io/lessons/open-redirect
