Paid Advertising
web application security lab

Redirect Holes Are Worse Than They Look

For all it’s faults, the forums have been an excellent resource for looking at real world vulnerabilities. Most of the time it’s the same old alert box or maybe jumping out of a quote or something, but nothing particularly interesting from a new vector perspective. Maluc started a thread looking for redirects. At first I was a little ho-hum about posting redirects, but then I started looking at what he was finding and how and then it started getting more interesting.

First of all there are basically three different ways to do redirects. The first is the most obvious, a 301 or 302 redirect using a “Location” HTTP header. The second is using a META refresh. The third is using JavaScript. The second two have obvious XSS issues that I won’t go into (or shouldn’t have to).

The 301 and 302 redirects are the more interesting ones to me personally. Over a sample of 28 redirect holes that Maluc and others contributed to, I found 7 of them had HTTP Response Splitting issues. Several others had the typical XSS holes as well, but again I’m not going to go into those. By my math that’s 1/4th of all redirects tested were vulnerable to HTTP Response Splitting to inject HTML that contained JavaScript.

Okay, let’s start over. How do we go about finding redirect holes? Redirects are used generally for tracking purposes. Companies want to see what you clicked on. So instead of using an onclick event they redirect them through their infrastructure and spit them out on the other side with some form of redirection. Maluc used something like inurl:redir (with some additional search parameters). Previously I wrote my own Greasemonkey script to do the same. However it happens, they’re everywhere and pretty easy to find just by looking at the URL structure.

Okay, so that part is easy, what about the exploitation itself? Of the 7 vulnerable sites, there were only three variations of vulnerable response splitting:


There are reasons for each and there are more variants - some systems may require %0D%0A instead of just %0A but the point is the same. These are very real attack vectors allowing JavaScript to be injected on input parameters that contain typically nothing but an innocuous URL string.

So yes, there will be some people out there that say “redirects are safe, it’s HTTP Response splitting that’s not” and I’ll smile and nod and wait for the next attack vector against them to come out. Personally I don’t think it’s worth the risk.

Comments are closed.