It's the Little Things That Matter (or How Google Sent Me To Bing)

One of the beauties of automation is that it is tireless, looking in all kinds of strange places that a human may miss. The Tinfoil scanner primarily bangs only against our customer’s websites, but we occasionally also set it loose (with a great deal of constraint!) on the internet at large to see what it can find and to alert people to any vulnerabilities. The scanner can only run a very small subset of testing when running in its “greater internet” mode, but even so we often find surprising results.

Recently, we happened to be examining Google, and found a pretty interesting unvalidated redirect. Going to will suddenly load up Bing instead. Craft the link to go someplace even more seemingly legitimate or hide behind a few layers of redirection and users can be genuinely confused.

Google was notified of the vulnerability on 9/20/2012 and responded thanking us for the disclosure but iterating that they felt it wasn’t necessary to patch the hole. While it’s their prerogative to ignore our advice, we at Tinfoil still feel that an unvalidated redirect can be abused and we classify it as a Medium vulnerability. OWASP agrees, considering it to have a moderate impact on most sites. What’s so dangerous you ask? Well, it’s the little things that matter.

An unvalidated redirect is a request where the user supplies a parameter that tells the webserver what to set the Location field to in the response headers. Simply put, you can tell it where you want to go and you’ll be sent there. By itself fairly innocuous but it’s been exploited before.

A good example of how this can be used to attack your users: the Vermont state website uses a framework that has an unvalidated redirect vulnerability. mysteriously redirects you to Google, although you thought you were perhaps going to a Vermont government page. This alone is enough to trick many people into clicking on a phishing site and having their password stolen, but it gets worse. runs a special URL shortener for links ending in .gov, using the domain in the shortened link. Suddenly any page can be one of these special URLs using the Vermont vulnerability, passing some of the trust given to the redirector to any other site. Who knew that clicking a link to a government page would actually take you to a phishing site?

Though it is unfortunate to click on a link and end up somewhere else, the updated URL tends to appear in the address bar. An observant user will notice this, but there have been plenty of browser-based attacks that let a site spoof the URL in the address bar. Javascript can also be used on Mobile Safari to hide the address bar as soon as the site loads. Given a copycat URL and a copycat login page, an attacker would likely get some user’s login credentials, and any is better than none. The attacker could even potentially be sneaky enough to sign them in after collecting the information so seemingly nothing went wrong.

Unvalidated redirects can be fixed in a couple of different ways:

  1. Provide an intermediate page showing the user where exactly they are going. Some variants of this include using a filter to only display the intermediate page when leaving the host website or redirecting the user anyway after a number of seconds. The potential downside here is that the user experience suffers a bit.

    Google actually does this in other places! There’s no reason they shouldn’t also apply it to their Google Finance product. Here’s an example:

  2. Use a secure token, in a manner similar to a CSRF token. Only the host website should be able to generate tokens for URLs it wishes to redirect to, thus giving you more fine grained control over where people can go. Downside here include having to keep the secret used to generate the token actually secret, and making sure that users can’t influence this link generation somewhere else in the application.

It’s easy, even for big companies with incredibly good engineering teams, to forget about the little things. “Oh, what’s a single unvalidated redirect?” or “Oh well, I’ll make sure to sanitize those inputs later...” are common things many developers say when they’re building software - the problem is that the little things you leave until later matter a lot. Using an automated tool that doesn’t care whether you have a ton of engineering to do this sprint to tell you when you’ve forgotten something is a great idea - automation is unforgiving and unrelenting. You can still choose to fix it later, but with full knowledge that you have a vulnerability. It’s the little things that matter.

The Tinfoil scanner will always inform you of any unvalidated redirects you have, even in our free trial, so sign up today!


Ben Sedat

Ben Sedat is the Engineering Wizard of Tinfoil Security. He's a bit of a blend between a traditional software engineer (builder) and security engineer (breaker). He spends a lot of time thinking about security: both detection as well as creating solutions for the security issues that exist in software and the internet. He also plays lots of video games. Lots.