Avoiding Attacker Supplied URL Vulnerabilities

The attacker may provide a link which looks trusted to a casual observer. Imagine an online bank with customer logins, which offers a url like:

	 www.bank.com?next=login.html

The bank site expects this to direct the user to a login page. An attacker might post a link (via email or the internet) to

	 www.bank.com?next=attackersite.html

This link will actually put the users who click on it on the attacker's website, even though the URL appears authentic. This could be made to look identical to the real bank site, thus stealing users login credentials when they try to login.

Over time, if this is not addressed, users may come to view your site with suspicion. Additionally, the vulnerability which allows the redirect attack may be used in other types of cross site scripting attacks, which can be more dangerous to your site or users. In some cases, search engines may decide that your site is dangerous, and will lower your ranking as a result.

More critically, users run a real risk of having their accounts or information stolen. Consider the banking example above. If the customer was expecting a login form, and the attacker creates a fake login form, then any legitimate customer who tries to log in using the attacker website will have her username and password stolen. That could leave a business on the hook for any losses incurred as a result of fraud!

The root cause of a redirect attack is improperly validated input from a GET or POST request which is then supplied into a redirect command. In PHP, you might see the following code which is vulnerable to a redirection attack:

<?PHP
header('Location: ',$_GET['myurl']);
?>

The GET indicates data submitted in the URL, so your site might have a legitimate URL for customers like so:

	http://www.mysite.com?myurl=see_products.html

An attacker could instead convince people to use the following link, which would really take them to an attackers site:

	http://www.mysite.com?myurl=http://www.doing_evil.com/infect_this_pc

The same thing can be accomplished with POST parameters, but the attacker site won't show up anywhere in the URL, making it harder to spot for users (the PHP code above would include POST instead of GET in this case).

To correct this issue, you need to validate the GET or POST input to ensure it contains only URL's you want users to go to.

There are three main ways to correct for this type of attack.

1. Whitelist input by creating a list of patterns for pattern matching the input to URL's you trust, or use an explicit list of URL's.
2. Create a mapping of unique identifiers to URL's. For instance ID 1 might map to mysite.com/page1, then only accept input which conforms to a known number, and discard all other input.
3. Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

URL Redirector Abuse
HTTP Response Splitting
URL Redirection to Untrusted Site (Analysis)

Golem Technologies includes numerous different server setting scans to help you reduce your exposure to attack with thorough security scanning, including insecure application parameters. See how the Golem Scan can help your business today.