Hacker News Reader

Comment by chacha102 | Hacker News Reader

It is technically a YouTube link, but it is redirecting to securitytube.net. I know this because the Internet I am on blocks YouTube, but not SecurityTube, so going directly to the redirect link works, but the YouTube link does not.

At least that is what my browser says:

http://www.youtube.com/redirect?username=digitalhook&q=h...

Looks like someone found a YouTube exploit.

View on HN

correct! Basic idea is to show how easy it is to use this simple redirect against users of social media sites. Most people on HN would have seen this link and trusted it to be from YouTube.

This is why redirect links should limit themselves to relative URLs, or limit it to a whitelisted set of domains.

(Can anyone think of downsides to limiting yourself to relative URLs or a whitelist of domains?)

It is very interesting that Youtube has this vulnerability. Almost every time I implement something like this, I double check the domain name. (This is really easy in PHP)

The redirect I found on https://www.google.com seems like it did have a whitelist. Luckily youtube.com was on the whitelist, so I could re-use the exploit from there. So even whitelists aren't totally safe (and YouTube isn't using the redirect for known friendly sites - seems to be more for tracking purposes).

http://news.ycombinator.com/item?id=1259844 for the google.com URL

Furthermore, I can see browsers detecting this type of behavior and prompting the user about it.

If a browser sees an encoded URL in the query string, and then gets a location header to go to that URL, and that URL is not on the same domain, it would prompt the user that you are leaving that domain.

I can't see many sites that are legitimate, and use redirection techniques that meet all of my criteria.

http://voice.google.com/ redirects to http://google.com/voice. Technically different domains, but I would be really annoyed if I had to confirm this every time. I suppose you could add a white list, but now we are just annoying people when they first start using a particular install of a browser.

No, I'm talking about seeing something like:

http://voice.google.com/?r=google.com/voice, where the resulting URL is inside the query_string

So then we start obfuscating the URL parameters? Or what if google.com/voice is just one step in a series of redirects? What if some "clever" dude decides to protect against this and say base64 encode the r argument to "protect" his app?

Reply on news.ycombinator.com