Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

youtube.com

Post reply on HN
Print view View original

21–30 of 60 posts

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

#21

Post by MichaelGG »

bcl wrote: post #12

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.

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

#22

Post by deno »

bcl wrote: post #12

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.

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.

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

#23

Post by mike-cardwell »

xtacy wrote: post #20
tednaleid wrote: post #15

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= &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...

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

#24

Post by xtacy »

mike-cardwell wrote: post #23
xtacy wrote: post #20

Earlier quoted context omitted.

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= &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)

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

#25

Post by jluxenberg »

MichaelGG wrote: post #21
bcl wrote: post #12

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 bas…

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 :)

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

#26

Post by exit »

xtacy wrote: post #20
tednaleid wrote: post #15

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= &h=hash(secret,url)

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

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

#27

Post by dotBen »

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.

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

#28

Post by pbhjpbhj »

xtacy wrote: post #24
mike-cardwell wrote: post #23

Earlier quoted context omitted.

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.

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

#29

Post by MichaelGG »

jluxenberg wrote: post #25
MichaelGG wrote: post #21

Earlier quoted context omitted.

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 bas…

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.

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

#30

Post by lsc »

jluxenberg wrote: post #25
MichaelGG wrote: post #21

Earlier quoted context omitted.

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 bas…

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 :)

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