• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


URL Redirector Abuse

Page history last edited by Robert Auger 13 years, 5 months ago

Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-38


URL Redirector Abuse

URL redirectors represent common functionality employed by web sites to forward an incoming request to an alternate resource. This can be done for a variety of reasons and is often done to allow resources to be moved within the directory structure and to avoid breaking functionality for users that request the resource at its previous location. URL redirectors may also be used to implement load balancing, leveraging abbreviated URLs or recording outgoing links. It is this last implementation which is often used in phishing attacks as described in the example below. URL redirectors do not necessarily represent a direct security vulnerability but can be abused by attackers trying to social engineer victims into believing that they are navigating to a site other than the true destination.



Phishing Example

In the example below, assume that original_site.com wants to log external links that visitors follow when leaving the site. This information would not ordinarily be captured in the server logs as the browser would simply make a request to the external site and not communicate further with the original site. One way that sites keep track of external links followed is to redirect the user from a local resource rather than linking directly to the external site. In the example below, instead of linking directly to external_site.com, a link points to redirect functionality at the local redirect.html page and passes in the ultimate destination as a parameter.




When such functionality is identified on popular websites, phishers will take advantage of it to fool unsuspecting users into believing that they are navigating to the well known site as opposed to the attacker controlled site. For example, an attacker could leverage the previous redirect to trick a user into surfing to the attacker controlled evil.com website by embedding the following URL in an HTML email message:



When the victim checks the destination URL perhaps by hovering over the link and noting the address in the status bar they may mistakenly believe that they were surfing to the trusted origial_site.com, not the evil.com site. This may succeed because users are accustomed to only recognizing the initial domain name or perhaps lengthy URLs will be truncated in the display. Attackers can also enhance such a social engineering attack by further obfuscating the redirected URL through various obfuscation techniques. For example, the URL below displays the same redirected URL but the 'evil.com' domain has been converted to its hexadecimal equivalent.



Implementing URL Redirectors

There are multiple ways to implement URL redirectors. A brief overview of each is described below.


1. HTTP 3xx Status Codes - RFC 2616 - "Hypertext Transfer Protocol - HTTP/1.1" defines a variety of 3xx status codes that will cause a browser to redirect to a specified location:


  • 300 Multiple Choices - Multiple possible destinations selected either by the user or user agent determined by agent-driven negotiation information.

  • 301 Moved Permanently - Indicates that the resource has been permanently moved and that the redirected URI should be used for future requests.

  • 302 Found - Indicates that the resource has been temporarily moved and that future requests should therefore continue to use the initially requested URI.

  • 303 See Other - The response can be requested from an alternate URI which should be requested using a GET method. This is generally used by the output of POST driven scripts.

  • 307 Temporary Redirect - Much like the 302 status code, 307 indicates a temporary redirection. While 302 was originally intended to require that the redirected request not alter the request method, in practice many clients changed the redirected request method to a GET request. Therefore, status code 307 was added to explicitly indicate that the redirected request method should not be altered.


The destination of the redirection is determined by the Location header.


2. Client Side Scripting - A variety of client side scripting languages can be used to implement URL redirection. The following examples uses JavaScript to redirect the browser to example.com:


<script language="JavaScript" type="text/javascript">
document.location.href = 'http://example.com';


3. META REFRESH Tag - An HTML meta element which specifies the time in seconds before the browser is to refresh the page. Providing an alternate URIallows the element to be used as a timed URL redirector. For example, in the following example the browser will redirect to example.com after 5 seconds:


          <meta http-equiv="refresh" content="5;url=http://example.com">

4. Refresh Header - The Refresh header is not detailed in any HTTP RFCs but was instead introduced by Netscape in a paper entitled An Exploration of

Dynamic Documents. It was implemented as a feature in Netscape Navigator 1.1 and is now supported by most modern browsers. A sample Refresh header is shown below:


Refresh: 10; URL=http://example.com


In this example, after 10 seconds, the browser would redirect to http://example.com. In situations where the Refresh header is dynamically generated using user supplied content, it could leave an application vulnerable to an HTTP Response Splitting attack as was the case in a PhpBB vulnerability discovered by Ory Segal in 2004.




"A Refreshing Look at Redirection", Amit Klein

[1] http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2006-November/001808.html


"Google Redirection Hole Used For Phishing", RSnake

[2] http://ha.ckers.org/blog/20060822/google-redirection-hole-used-for-phishing/


"An Exploration of Dynamic Documents", Netscape

[3] http://www.citycat.ru/doc/HTML/Netscape/pushpull.html


"RFC 2616"

[4] http://www.w3.org/Protocols/rfc2616/rfc2616.html


URL Redirection to Untrusted Site ('Open Redirect')

[5] http://cwe.mitre.org/data/definitions/601.html

Comments (0)

You don't have permission to comment on this page.