Link Search Menu Expand Document

Open Redirect

  1. Open Redirect
    1. Description
    2. Impact
    3. Scenarios
    4. Prevention
    5. Testing

Description

Open Redirect vulnerabilities are possible when a web application accepts untrusted input to redirect the user to a new arbitrary (external) website. Without proper validation, malicious actors can leverage this flaw by surreptitiously redirecting victims to malware or phishing sites or forwarding them to unauthorised pages.

This attack was featured on the OWASP Top 10 list web application security risks for many years, and although it has been dropped in the most recent iteration, it remains an important risk to mitigate, as it can be used as the genesis of a chain of escalating attacks.

Impact

Open Redirect can be used by malicious actors to carry out phishing attacks by redirecting the user to a malicious site and stealing user credentials. Unless users are extremely observant, it’s very likely they won’t notice the redirection to a different domain, especially if the attacker has taken pains to ensure the forged page precisely mimics the legitimate login page.

Additionally, Open Redirect may facilitate other types of attacks such as:

  • Cross Site Scripting: an XSS vulnerability may be introduced if the user’s browser supports data: or javascript: protocols in redirects.
  • Server Side Request Forgery: SSRF filters can be evaded with open redirects

Whether it be a small scale scam, or a much larger compromise that result from an Open Redirect opening the door, developers have a responsibility to ensure they maintain high web application security standards by choosing best security standard functions.

Scenarios

The following exemplifies what is possible when an attacker is able to redirect the browser to a malicious site using a trustworthy-looking domain name to gain the victim’s trust.

The following snippet of code suffers from Open Redirect vulnerability:

string url = request.QueryString["url"];
Response.Redirect(url);

Which can be exploited by an attacker that crafts the following URL:

http://www.vulnerableapp.com/verify?url=http://www.attackerwebsite.com

If inserted in a convincing enough phishing attempt, an unwitting user may only pay attention to the domain name and click on the link, not realising he or she is redirected to the malicious website http://www.attackerwebsite.com.

Prevention

The most obvious solution to this issue is to cease the use of redirects that depend on user-provided input. Of course, sometimes this is not possible for sites that require this facility in order to function properly.

In cases where user input absolutely cannot be avoided, developers must ensure that the supplied value is mapped to an actual value (rather than the actual URL) and that the server-side code translates this value to the target URL. This approach allows for the maintenance of a permitted redirection URL allow list.

If the redirect is local to the application, ensure that the URL used for redirection is a relative URL.

Testing

Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.


Table of contents