How Not To Whitelist
- Posted by Ryan on Saturday, July 18, 2009, in Security
I started using Fluid for site-specific browsers on my Mac. As the name implies, Fluid SSBs only allow you to visit pages on a single site, but allows you to extend the site with your own scripts and stylesheets to integrate web apps into Mac OS X, effectively transforming them into desktop applications. For instance, I have a SSB for Campfire with a script that updates the dock badge whenever a new message is received, and puts up a Growl notification when my name is mentioned.
I should note that I’m trying out SSBs after reading up a bit about the security benefits they may or may not provide. The thought is that if your browser can’t be redirected to a malicious site, then it will be harder to pass your credentials to an attacker. Combined with Choosy (which I haven’t tried yet), SSBs may be a large step towards preventing account theft through cross-site scripting and request forgery attacks.
Unfortunately, after spending a few minutes with Fluid’s whitelisting I determined that it won’t do any good in it’s current state. I’ll illustrate with an SSB for viewing Apple’s website:
Above shows the UI for generating a SSB; it’s fairly self-explanatory. Clicking “Create” generates a new application bundle on my desktop, which launches and takes me to Apple.com. Now let’s look at the whitelist Fluid set up for me:
As you can see, it converted my original URL of http://www.apple.com to a whitelist pattern of the form *apple.com*, where asterisks represent wildcards. This is to allow me to visit any subdomain (e.g., support.apple.com) and any file (e.g., apple.com/macosx/), rather than limit me to just the homepage.
The problem with this approach is that it’s too general; the whitelist permits too much. Not only can I get to http://www.apple.com/, but I can get to http://www.snapple.com/ as well. An attacker could buy up any that ends with apple.com and Fluid would happily load it.
You may have guessed that this particular whitelist pattern has other deficiencies. The following URLs all work as well:
- http://www.microsoft.com/#apple.com
- http://apple.com.example.com/
- http://apple.com@rgov.org/
In each of the above examples, I’m not limited to just domains ending with apple.com, but I can in fact load any page on any domain I choose, as long as it includes the whitelisted string somewhere within it.
Now that we’ve demonstrated that the default whitelist setting is flawed, what’s a better whitelist? I propose this:
- http://*.apple.com/*
- https://*.apple.com/*
- http://apple.com/*
- https://apple.com/*
It allows only hosts which are proper subdomains of apple.com. (It’s important to include the / after the hostname, or else the last two example bypass URLs I gave would still work.)
Unfortunately, one would be wrong to assume that when you set up the whitelist as above, you can no longer access any URL not owned by Apple. It seems that Fluid has a few implicit whitelists to allow certain features. The two that I’ve found so far are *userscripts.org and www.google.com*www.apple.com*. As with our original pattern, these aren’t adequate for proper filtering, and from what I can tell there’s no way of disabling them.
I’ll keep using Fluid for the time being, but I have no illusions that it’s doing anything to keep me particularly safe.