Open Redirection

Open Redirection

According to the Open Web Application Security Project, an open redirection occurs when an application takes a parameter and redirects a user to that parameter value without any conducting any validation on the value.

This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it, abusing the trust of a given domain to lead users to another. The malicious website serving as the redirect destination could be prepared to look like a legitimate site and try to collect personal / sensitive information.

Check out the OWASP Unvalidated Redirects and Forwards Cheat Sheet

Finding and Exploiting Open Redirection Vulnerabilities

The fi rst step in locating open redirection vulnerabilities is to identify every instance within the application where a redirect occurs. An application can cause the user’s browser to redirect to a different URL in several ways:

  • An HTTP redirect uses a message with a 3xx status code and a Location header specifying the target of the redirect:

HTTP/1.1 302 Object moved
Location: http://mdsec.net/updates/update29.html

  • The HTTP Refresh header can be used to reload a page with an arbitrary URL after a fi xed interval, which may be 0 to trigger an immediate redirect:

HTTP/1.1 200 OK
Refresh: 0; url=http://mdsec.net/updates/update29.html

  • The HTML tag can be used to replicate the behavior of any HTTP header and therefore can be used for redirection:

HTTP/1.1 200 OK
Content-Length: 125

<html> <head> <meta http-equiv=”refresh” content=”0;url=http://mdsec.net/updates/update29.html”> </head> </html>

  • Various APIs exist within JavaScript that can be used to redirect the browser to an arbitrary URL:

HTTP/1.1 200 OK
Content-Length: 120

<html> <head> <script> document.location=”http://mdsec.net/updates/update29.html”; </script> </head> </html>

In each of these cases, an absolute or relative URL may be specified.

Preventing Open Redirection Vulnerability

The most effective way to avoid open redirection vulnerabilities is to not incorporate user-supplied data into the target of a redirect. Developers are inclined to use this technique for various reasons, but alternatives usually are available. For example, it is common to see a user interface that contains a list of links, each pointing to a redirection page and passing a target URL as a parameter. Here, possible alternative approaches include the following:

  • Remove the redirection page from the application, and replace links to it with direct links to the relevant target URLs.
  • Maintain a list of all valid URLs for redirection. Instead of passing the target URL as a parameter to the redirect page, pass an index into this list. The redirect page should look up the index in its list and return a redirect to the relevant URL.

If it is considered unavoidable for the redirection page to receive user-controllable input and incorporate this into the redirect target, one of the following measures should be used to minimize the risk of redirection attacks:

  • The application should use relative URLs in all its redirects, and the redirect page should strictly validate that the URL received is a relative URL. It should verify that the user-supplied URL either begins with a single slash followed by a letter or begins with a letter and does not contain a colon character before the fi rst slash. Any other input should be rejected, not sanitized.
  • The application should use URLs relative to the web root for all its redirects, and the redirect page should prepend http://yourdomainname.com to all user-supplied URLs before issuing the redirect. If the user-supplied URL does not begin with a slash character, it should instead be prepended with http://yourdomainname.com/.
  • The application should use absolute URLs for all redirects, and the redirect page should verify that the user-supplied URL begins with http://yourdomainname.com/ before issuing the redirect. Any other input should be rejected.

As with DOM-based XSS vulnerabilities, it is recommended that applications not perform redirects via client-side scripts on the basis of DOM data, because this data is outside of the server’s direct control.

POC

HackerOne Interstitial Redirect
Difficulty: Medium
Url: N/A
Report Link: https://hackerone.com/reports/111968 4
Date Reported: January 20, 2016
Bounty Paid: $500

Summary:-

Open Redirection allow a malicious attacker to redirect people unknowingly to a malicious website. Finding them, as these examples show, often requires keen observation. This sometimes occurs in a easy to spot redirect_to=, domain_name=, checkout_url=, etc. This type of vulnerability relies of an abuse of trust, where by victims are tricked into visiting an attackers site thinking they will be visiting a site they recognize.

Typically, you can spot these when a URL is passed in as a parameter to a web request. Keep an eye out and play with the address to see if it will accept a link to an external site. Additionally, the HackerOne interstitial redirect shows the importance of both, recognizing the tools and services web sites use while you hunt for vulnerabilities and how sometimes you have to be persistent and clearly demonstrate a vulnerability before it is recognized and accepted.

Related posts

Leave a Comment