Redirects happen all the time. Whether you’re trying to redirect a browser to an SSL version of the website, or whether you are trying to redirect to a different landing page or function all together, there are still precautions to take in order to protect your redirects. If a redirect is exploited, an attacker can utilize an external site that appears as if it was part of the original domain, a key component of Phishing attacks.

Redirect scripts usually have three components:

  • redirect.cgi                                                   (The name of the script)
  • redirect.cgi?url=                                         (The parameter of the script)
  • redirect.cgi?url=httphacker.com        (The value of the parameter)

In this example, I’m redirecting the request for domain.com to httphacker.com:

GET /redirect.html?url=httphacker.com HTTP/1.1
Referer: domain.com/index.html
Accept: */*
Pragma: no-cache
User-Agent: Mozilla/5.0 Gecko/20110614 Firefox/3.6.18
Host: domain.com
Connection: Keep-Alive
Cookie: JSESSIONID=272DDD88


The redirect occurs as expected. If this were a malicious site, then the end user could be vulnerable to many attack vectors (e.g. Phishing, Malware, Clickjacking).

HTTP/1.1 302 Found
Date: Mon, 28 Oct 2013 12:50:23 GMT
Server: Apache/2.2.22 (Ubuntu)
Location: httphacker.com
Content-Language: en-US
Content-Length: 0
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=95
Connection: Keep-Alive
Content-Type: text/html


To prevent these issues,  adopt secure programming techniques which do not rely on utilizing the HTML meta refresh tag or HTTP redirection capabilities as a method of redirecting users to other sites specified by the browser. You can also implement DNS Redirecting instead of HTTP Redirecting as a means of mitigating these issues.  Redirecting at the DNS Level also helps aid other potential security issues such as SSL Policy Enforcement.

Additional mitigation techniques include:

  • Always sanitize data returned from a user or other application components before storing or processing it, or presenting it back to the application user.
  • Maintain a list of valid “redirection” URL’s.
  • Ensure that all characters that could be interpreted as an executable language are replaced with their corresponding HTML encoded versions.
  • Do not accept session information from within a URL.
  • Do not reference redirection URL’s or alternative file paths within the browser’s URL path.
  • Do not utilize the Referrer header (or an equivalent) as a method of authorization or authentication.