This link says it's from YouTube but it's not | Hacker News Reader

This link says it's from YouTube but it's not

youtube.com

277 pointsPhantom57 comments

My first computer job as a teen was working at a small SEO shop (3 people) writing little cgi/perl scripts for this and that.

Yahoo's http server at that time used to take redirect URLs in this format: "http://yahoo/url/*http://exiturl/. They were using these URLs on all search results, I'm guessing to track click-throughs to improve rankings. So I set up a script on our site to load an image using this format with the img src in the exit-url, and for the yahoo-url and we would round robin 'client' links though. Essentially spoofing legitimate search&clicks on yahoo from unique IPs from our site visitors. Over the next two weeks all our sites started bubbling up in the results. This worked for about a month before Yahoo changed something (I'd guess they started validating the http-referrer or the exit-url), and it all stopped working.

But, for that brief window of time when it was working, I was the king of the high fives.

(FWIW, I don't do SEO work of any kind anymore, and I certainly don't advocate 'blackhat seo'.)

This is a common exploit. So common that it's #8 on the 2010 OWASP top 10 most critical web application security risks: "Unvalidated Redirects and Forwards".

http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projec...

Every web app developer should review these vulnerabilities before releasing their code to the world.

Interesting. Facebook had a similar exploit earlier but they seem to have solved it easily by attaching a hash to the redirect:

site.com/redirect?l=<url>&h=hash(secret,url)

I do the same on my own website. I built a redirector using Apache mod_rewrite, and then secured it using a token and some mod_security configuration. See here:

https://secure.grepular.com/Secure_URL_Redirects_using_Apach...

Is the primary motivation behind redirection to another website to track clicks? In situations like Facebook, a redirect effectively changes the REFERRER header so that it doesn't leak any information (about the origin of the request, like: facebook.com/profile.php?id)

I'd imagine you are right, primarily click-tracking. Secondarily linkjuice control I expect.

that doesn't seem to solve it. the youtube redirect also has a signature, but generating a signed link is trivial.

Good point. Clearly there's a pretty serious problem with however they're creating those hashes.

Aha, that's a good idea.

We have an open redirect on our site that I've been looking at fixing, but while verifying all the possible links against a whitelist would work, it would be a pain.

it's better to call it a hmac - http://en.wikipedia.org/wiki/HMAC - since reinventing them using hashes can lead to weaknesses (see "design principles" on that page).

Facebook also presents you with a warning page before redirecting you:

http://www.facebook.com/l.php?u=http%3A%2F%2Fnews.ycombinato...

https://www.google.com/accounts/CheckCookie?continue=http%3A...

This link looks like it's from google.com but it's not.

Incidentally I think this only works if you're currently signed in to a Google account, oh yeah it's bouncing from an HTTPS address as well.

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.

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?

I don't know a single non-technical but non-internet-ignorant user who wouldn't be suckered in by this. I've taught people how to scan for valid links, and now they can't even trust that.

How do you tell civilians to scan for valid links? I say "if you see another domain name/IP address in the URL, don't do it". Maybe that is over-broad, but it works.

> domain name/IP address in the URL

civilian what's a domain? Is that like a mailing address? the Uwhat? Stop being so technical!

On proggit, we just found that even techical, internet savvy users can be suckered in by this.

http://www.reddit.com/r/programming/comments/bpy7h/think_you...

1 in 5 attempted to sign in. The results are hardly scientific, but the comments are full of users who were fooled.

Looks like google fixed this one.

Sorry but I'm not sure users from reddit are all web savvy. It's still interesting that people don't look at urls when asked for passwords.

Maybe not reddit as whole, but surely the people reading the programming subreddit are a bit more web savvy than the average person?

URLs are not a security mechanism. They are a non-canonical resource locator, where each part is resolved by a different server. It's a way to write a "program" that does a DNS lookup and HTTP query in a simple way.

Nothing more, nothing less.

If you want security, start a CA, give each site you like its own SSL cert (signed by you), and enjoy.

I've looked at the costs of starting a CA and they are absolutely astronomical for the average person. Not that every person should be able to start a full-fledged CA, but the whole thing is scammy on the tail-end.

Wow, I don't like this. My usual tactic of looking for the / after the .tld isn't a general solution anymore. I hope my bank doesn't implement this functionality.

Exactly! Imagine if your bank had such a redirect URL available, Phishing would be so simple.

Some banks display a customer preselected image after the user name & before entering a password. This seems to be a good solution to phishing if one keeps the username private. Otherwise a site could give you the option of using two part passwords.

... and a study a while back showed that, if you simply don't show that image, a large majority of users don't notice. For this reason, the whole "sitekey" phenomenon strikes me as a waste of time.

This? http://usablesecurity.org/emperor/ - it is an interesting read.

It should also be noted that it's not even a 25% benefit for them, but it does help security, even if slightly. I think lowering phishing 1% could be massive for any major bank.

Isn't this incredibly simple to defeat? The phishing site can send your username to the real bank's website and retrieve the image.

If you do that, the bank will notice a bunch of connections from the same IP for different usernames.

You could use a botnet to do the lookups, but that still makes the attack substantially more difficult.

So it is important to also check the URL in your address bar _after_ you click, as well. This trick won’t be able to fake that.

But would you always catch it if you were redirected to www.youtube.com.you1ube.com/something?

Or possibly worse - http://www.youtube.com⁄bad-site.com/something_else

In this I rely on my browser to filter deceptive characters in domain names.

When I hover over the link you gave (or click it and see it in the address bar), it looks like http://www.youtube.xn--combad-site-hx3f.com/something_else (which lets off plenty of flags for me).

When hovered, then clicked in Opera:

opera:illegal-url-24

Error!

Invalid URL

The URL http://www.youtube.com⁄bad-site.com/something_else contains characters that are not valid in the location they are found.

The reason for their presence may be a mistyped URL, but the URL may also be an attempt to trick you into visiting a Web site which you might mistake for a site you trust.

This is hardly new, but I agree it is an issue.

The answer to this security issue is either:

1) The bit.ly route - store off-site urls your organization wants to link to as a value and give the user an url with just the key in it.

2) Create a secret salted hash of the url and include that with the url in the args. Upon request, the receiver would re-hash the url and compare it to the hash given. Unless someone reverse engineered your hash this system prevents someone casually manipulating a url.

If you're going to that much trouble, perhaps you could set up permissions to add target URLs?

This is not new. Various 'recognized' websites have redirect urls that are not protected. Once the redirect is complete the site it properly identified.

If you have to be afraid of what links you click on you are running the wrong software.

It's not about technical exploits, it's about making it eassier to social engineer and phish. For instance, redirecting to a fake youtube login page. Even slightly more savvy users will look at the original link, click it, then click through and follow instructions. Single signon systems that have redirects aren't uncommon, so the user can be used to seeing that sort of behaviour.

I'm surprised youtube has such a basic problem on their site.

Isn't this what SSL is for, proving identity? In this case, even a cursory look at the URL would indicate that something was up.

Sure, this makes fishing a little easier, but users need to watch out for themselves. It's a big bad world out there :)

Yes, but it's not hard to get an SSL cert for some random domain. So user clicks a youtube link, ends up on "centralised-video-authentication.com", sees SSL icon, all good?

I agree with you in general, but youtube shouldn't be making things harder for security.

you need to watch out, certainly, however you should also encourage webapp providers to write secure code.

SSL doesn't prove identity. It just proves that the connection is encrypted. CA's try to add a layer of trust on top of this with their different levels of certification, but that doesn't guarantee identity.

But the real danger is phising. You won't get a virus when you click, but you might trust the website you're redirected to and type in your password.

You should always check the URL in the browser before entering your secrets.

I wonder how many sites have a similar redirect feature for post-login pages instead of outbound click tracking. This feature makes it easy to login from any page, and immediately return to the page upon success. How many sites don't validate the full url before redirecting? Scary thought...

This title makes me definitely not want to click it.

Can you suggest something better?

Say where it is sending you, not just where it's not sending you.

It may suffice to point out in the comments that it redirects to http://securitytube.net/Social-Engineering-Attacks-using-Sim... . (As of this posting nobody else has posted this yet.)

Also, despite having "video" in the URL, the text says all you need to know. I don't think very many people around here will have a hard time figuring out how this happened. I don't need a video.

This is a case where the web is only as secure as its most insecure link. Even if your site uses a hash to prevent abusing redirects people can still abuse them. They need only find a site that uses hashless redirects, generate some redirect link using that site, and then create a legit redirect link using your site. Blacklisting certain domain strings in the url would not solve this- new domains are too easy to obtain. Whitelisting would help but may be prohibitive depending on what you are building...

This is why I'm using the RequestPolicy addon on Firefox : http://www.requestpolicy.com/

It asks for confirmation when a page tries to redirect unexpectedly like this.

Reply on news.ycombinator.com