Nothing Special   »   [go: up one dir, main page]

Open Redirection

Download as pdf or txt
Download as pdf or txt
You are on page 1of 4

What Is Open Redirection

A redirect happens when the website or web application changes the URL that
is accessed in the client (usually external – internal redirects are usually called
forwards). There are several ways to do this from the back-end. Usually,
redirects are made by sending specific HTTP headers to the client but you can
also create redirects, for example, using JavaScript code.

An open redirect vulnerability exists when the destination of the redirect is


provided by the client and it is not filtered or validated. Here are some
examples of safe redirects and unsafe redirects:

• If the legitimate website redirects the client to a fixed URL, it is a safe


redirect.
• If the legitimate website safely constructs the redirect URL based on
parameters provided by the user, it is a safe redirect.
• If the legitimate website constructs the redirect URL based on
parameters provided by the user but does not sufficiently validate/filter
input, it is an unsafe redirect (the attacker may manipulate the input).
• If the legitimate website allows the user to specify the destination
redirect URL, it is an unsafe redirect (open redirect).
Types of Open Redirects
We will focus primarily on Open Redirect vulnerabilities that are header and
JavaScript-based. Header-based redirects work even when JavaScript isn’t
interpreted.

Header-Based Open Redirection


First things first, let’s talk about the Header-based Open Redirection since it
works even when a JavaScript doesn’t get interpreted. An HTTP Location
header is a response header that does two things:

• It asks a browser to redirect a URL


• It provides information regarding the location of a resource that was
recently created.

Basically, it’s JavaScript-independent and attackers utilize this tactic to


successfully redirect the targeted user to another website. It’s simple but also
incredibly effective if the user doesn’t carefully examine the URL for any
strange additions to the code.

JavaScript-Based Open Redirection


Server-side code (server-side functions) takes care of tasks like verifying data
and requests and then sending the correct data to the user. While JavaScript-
based Open Redirections won’t always work for a server-side function, an
unexpecting victim and their web browser are susceptible to exploitation.

When an attacker manages to perform a redirect in JavaScript, many


dangerous vulnerabilities are possible. Since Open Redirections are mostly
used in phishing scams, people aren’t aware of the fact that an Open
Redirection can also be a part of a more complex chain of attacks where
multiple vulnerabilities get exploited. And the JavaScript-based Open
Redirection is an important part of that chain. For example, redirecting a user
to javascript: something() ends up being a dangerous Cross-Site Scripting
injection.
How can an open redirect web
vulnerability be exploited?
Abusing user trust in the vulnerable website
Since the domain name in a URL is typically the only indicator for a user to
recognize a legitimate website from a non-legitimate one, an attacker can
abuse this trust to exploit an open redirect vulnerability on the vulnerable
website and redirect the user to a malicious site to execute further attacks, as
explained in the following sections.

Exploiting an open redirect vulnerability to redirect


victims to malicious websites
It is also possible to redirect an otherwise careful web user to a site hosting
attacker-controlled content, like a browser exploit or a page executing a CSRF
attack. As above, the chances that the victim clicks the link are higher if the site
that the link points to is trusted by the victim. An example is an open redirect
in a trustworthy page like a banking site that directs the victim to a page with a
CSRF exploit against a vulnerable WordPress plugin.

Exploiting an open redirection vulnerability to execute


code
An open redirection vulnerability in a web application can also be used to
execute an XSS payload by redirecting to javascript: URIs instead of HTML
pages. These can be used to directly execute JavaScript code in the context of
the vulnerable website

Exploiting an open redirect vulnerability for a phishing


attack
When a user clicks on a link of a legitimate website they often won’t be
suspicious if suddenly a login prompt shows up. To launch a successful phishing
scam, the attacker sends the victim a link, for example via email, which exploits
the vulnerability on the vulnerable website

How To Prevent Open Redirects


The safest way to prevent open redirection vulnerabilities is not to use any
redirections in your web applications. If this is not possible, you can attempt
the following approaches:

• Use a list of fixed destination pages. Store their full URLs in a database
table and call them using identifiers as request parameters, not the URLs
themselves. For example, store http://example2.com in the database
table with the identifier 42 and then use the following call to redirect to
example2.com: https://example.com/redirect.php?redir_id=42.
• If you cannot use a fixed list of redirection targets, filter untrusted input
(if you can, using a whitelist, not a blacklist). Make sure to check for
partial strings, for example, http://example.com.evil.com is a valid URL.
Additionally, disallow all protocols except HTTP and HTTPS. Also note,
that despite your best efforts it is possible that attackers may find a way
around your filters.

References
https://www.acunetix.com/blog/web-security-zone/what-are-open-redirects/

https://www.netsparker.com/blog/web-security/open-redirection-
vulnerability-information-prevention/

https://www.neuralegion.com/blog/open-redirect-vulnerabilities/

You might also like