Risks

Redirects are a useful function to have when building a website. If a user attempts to access a resource before they are logged in, it is conventional to redirect them to the login page, put the original URL in a query parameter, and after they have logged in, automatically redirect them to their original destination. This type of functionality shows you are putting thought into the user experience and is to be encouraged. However, you need to be sure anywhere you do redirects, they are done safely – otherwise, you are putting your users in harm’s way by enabling phishing attacks.

Modern webmail services are very good at spotting spam and other types of malicious messages. One detection method they use is to parse the outbound links in HTML emails. These links are compared to a black list of banned domains; if the domain is deemed to be malicious, the email is redirected to the junk folder.

This is why spammers and phishers find open redirects so enticing. If they can “bounce” a user off your website (an apparently valid domain), their messages are less likely to be marked as malicious. If the user clicks on the link, they will see your website in the link, but they will end up at whatever site the attacker wants to direct them to. A confused user might download malware or worse, because of the trust they put in your site!

Prevention

Disallow Offsite Redirects

You can prevent redirects to other domains by checking the URL being passed to the redirect function. Make sure all redirect URLs are relative paths – i.e. they start with a single / character. (Note that URLs starting with // will be interpreted by the browser as a protocol agnostic, absolute URL – so they should be rejected too.)

If you do need to perform external redirects, consider whitelisting the individual sites that you permit redirects to.

Check the Referrer When Doing Redirects

Redirects to URLs passed in query parameters should only be triggered by pages on your site. Any other sites triggering a redirect should be treated with extreme suspicion. As a second layer of defense, check that the Referer in the HTTP request matches your domain whenever you perform a redirect.

Code Samples

The code samples below demonstrate how to check that a URL is a relative path.

Python Validate for relative paths with:

import re

def is_relative(url): return re.match(r""^/[^/\]"", url)

Ruby Validate for relative paths with:

def is_relative(url) url =~ /^/[^/\]/ end

Java A redirect like the following is open to abuse:

protected void doGet(HttpServletRequest request, HttpServletResponse response) { String url = request.getParameter(""url""); if (url != null) { response.sendRedirect(url); } }

Make sure you validate the url parameter wherever you invoke the sendRedirect method:

protected void doGet(HttpServletRequest request, HttpServletResponse response) { String url = request.getParameter(""url""); if (url != null && isRelative(url)) { response.sendRedirect(url); } }

// Allow anything starting with ""/"", except paths starting // ""//"" and ""/"". private boolean isRelative(url) { return url.matches(""/[^/\]?.*""); }

.NET Validate URLs with the following snippet:

private bool IsRelativePath(string url) { if (string.IsNullOrEmpty(url)) { return false; } else { if (url.Length == 1) return true;

  // Allow anything starting with ""/"", except paths starting
  // ""//"" and ""/\"". Allow the ""~/"" syntax too.
  return (url[0] == '/' && (url[1] != '/' && url[1] != '\\')) ||
         (url[0] == '~' && url[1] == '/');

} }

.NET allows the syntax ~/ for URLs relative to the domain of your site - you can choose whether to support this in redirects.

Node Validate relative paths with:

function isRelative(url) { return url && url.match(/^/[^/\]/); }