Have you ever done the following?
- Logged in to a web site, let's say for the sake of example, any web-based email service
- While still logged in, visited another site, perhaps just clicking on a link in an email, or viewing an HTML email
Now, you have just opened the doors wide for an attack. A malicious script could (for instance) grab your email or do anything else the programming interface (the web API) of the site you are logged into, allows. This chilling story indicates the extent of your vulnerability. A script used the GMail API to insert a rule that forwarded all email concerning domain names to a site hijacker. The hijacker then sent an email to a domain registrar, and quickly and easily had control of the person's business web site. Most likely the exploit was a script uploaded to a web forum or other insecure page, where upon it attempted the same for everyone who viewed that page. It could even be in an image tag in a HTML spam email--no action required on the victims part.
I've known about this style of attack (now called a XSRF or cross-site request forgery) for many years. How do you ensure that a request coming in is legitimate? After all, it is the web, legitimate use could be coming in from any Internet Protocol address. One barricade that can be placed in the way of hackers is to use what is called the referrer or "HTTP referer" (mis-spelled in the original specification). This is information that the web browser provides indicating which URL the request came from. For example, only Google URLs should be accessing GMail settings.
This information however can be spoofed, for example by writing a program that emulates a browser (and this is much easier than it may sound to the non-programmer). A larger problem is then distributing the program so that victims inadvertently use it, which is where well-known techniques of code injection such as viruses come into play. Even simpler is to use a Flash applet stuck on a web page, which you will probably not even be aware of running when you stumble over it. But apparently Google's GMail did not have even this low barricade, allowing simple scripts to directly access the settings (of any GMail user who was currently logged in while being subjected to the evil script).
So, the question is, is there any way to safely browse? After all, banking, shopping, and many forms of communicating now take place primarily via the web.
The short answer is that safe browsing is not really possible today, at least not in a practical form (in other words, while still allowing web-based banking, shopping, email, blogging, etc... any form that uses the medium as something more than a read-only source of information). But there are things you can do to limit your exposure.
- Disable automatic image loading in your email client, whether webmail or application
- Always log out of your sessions before opening any untrusted site. Always look at the URL of a link target (the URL that is typically shown in the lower right when you mouse-over a link). If you don't trust it, don't open it. [Note, I don't think this can be spoofed by the default settings in the current major browsers, but am not 100% certain]. Or copy it to another browser (not just another window of the same browser). For example, install Opera or Safari in addition to your default browser (Firefox, I hope!), and paste the URL there.
-
Avoid webmail for business or other communication that should be secure.
- Use the NoScript extension for Firefox, selectively allowing those sites you trust (it makes this process quite easy).
- Just because a site seems to use https:// (secure, typically shown as yellow in the URL address bar and the lock icon) for everything, doesn't mean it actually enforces that policy.
- Don't expect the big guys, the Googles, Facebooks, or your favorite global banking conglomerate have ironclad web applications.
Finally, for web developers, this paper on XSRF [PDF]
offers some methods for securing applications.
