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.<p>Yahoo's http server at that time used to take redirect URLs in this format: "<a href="http://yahoo/url/*http://exiturl/" rel="nofollow">http://yahoo/url/*http://exiturl/</a>. 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.<p>But, for that brief window of time when it was working, I was the king of the high fives.<p>(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".<p><a href="http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project" rel="nofollow">http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projec...</a><p>Every web app developer should review these vulnerabilities before releasing their code to the world.
<a href="https://www.google.com/accounts/CheckCookie?continue=http%3A%2F%2Fwww.youtube.com%2Fredirect%3Fusername%3Ddigitalhook%26q%3Dhttp%253A%252F%252Fsecuritytube.net%252FSocial-Engineering-Attacks-using-Simple-Redirections-video.aspx%26video_id%3DVgc3NVVpb8c%26event%3Durl_redirect%26url_redirect%3DTrue%26usg%3DUE0DOmwjBRK-mgheFtW1hMTEvh4%3D%2F&chtml=LoginDoneHtml" rel="nofollow">https://www.google.com/accounts/CheckCookie?continue=http%3A...</a><p>This link looks like it's from google.com but it's not.<p>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.<p>At least that is what my browser says:<p><a href="http://www.youtube.com/redirect?username=digitalhook&q=http%3A%2F%2Fsecuritytube.net%2FSocial-Engineering-Attacks-using-Simple-Redirections-video.aspx&video_id=Vgc3NVVpb8c&event=url_redirect&url_redirect=True&usg=UE0DOmwjBRK-mgheFtW1hMTEvh4=" rel="nofollow">http://www.youtube.com/redirect?username=digitalhook&q=h...</a><p>Looks like someone found a YouTube exploit.
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.
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.<p>Nothing more, nothing less.<p>If you want security, start a CA, give each site you like its own SSL cert (signed by you), and enjoy.
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.
This is hardly new, but I agree it is an issue.<p>The answer to this security issue is either:<p>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.<p>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.
This is not new. Various 'recognized' websites have redirect urls that are not protected. Once the redirect is complete the site it properly identified.<p>If you have to be afraid of what links you click on you are running the wrong software.
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 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 : <a href="http://www.requestpolicy.com/" rel="nofollow">http://www.requestpolicy.com/</a><p>It asks for confirmation when a page tries to redirect unexpectedly like this.