Open Redirection, Arbitrary Supplied Request Parameter

CloudScan Vulnerability Crawler | Open Redirection Example PoC

The DORK Report

Summary

Severity:

Low

Confidence:

Certain

Host:

http://ib.adnxs.com

Path:

/getuid

Issue detail

The name of an arbitrarily supplied request parameter is used to perform an HTTP redirect. The payload http%3a//a21176f6ce064ea74/a%3f1 was submitted in the name of an arbitrarily supplied request parameter. This caused a redirection to the following URL:

http://a21176f6ce064ea74/a?1=1

Issue background

Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application which causes a redirection to an arbitrary external domain. This behaviour can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targetting the correct domain with a valid SSL certificate (if SSL is used) lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.

Issue remediation

If possible, applications should avoid incorporating user-controllable data into redirection targets. In many cases, this behaviour 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.