Skip Navigation

Blog » XSS Alarm Userscript

A user script for Opera, Firefox and Chrome that notifies you when a site is loading scripts from unrecognised third parties to help you spot potential XSS attacks more easily.

Cross-Site Scripting (also known as XSS) is a security concern for any site that allows user input, especially e-commerce stores and anyone using or collecting sensitive personal information. In very basic terms, XSS is when a third party manages to have the target site load and show to a user a script or iframe they control. It allows the attacker to steal cookies, log keystrokes and more.

Unfortunately, while as a developer there is plenty you can do you make your web application secure against XSS, as a customer/user there is very little you can do to keep yourself safe. All you can really do is make sure you don't give out personal details or buy online from anywhere but the most reputable stores. And maybe watch your browser's "loading" bar like a hawk. Or maybe sniff your own HTTP traffic.

No browsers (that I know of) provide any method for prevention of third party scripts or iframes from loading. Let's face it - as long as advertising exists, that's unlikely to change. You can turn all JavaScript off, but that doesn't protect you against iframe-based XSS, and obviously degrades (for the most part) your web experience.

What I wanted was something to warn me when my browser was loading scripts from a third party. (Actually, what I really wanted was something to allow me to decide whether to load them or not.) Once a script from a third party has loaded, it may be too late to do anything - personal information may have already been taken - however, at least in principle, a warning may prevent me giving information to a compromised site.

So I have written a very basic UserScript for users of GreaseMonkey, Opera or Chrome. It pops up a red box with the URLs of any third party scripts or iframes being loaded by a site, unless they are being loaded from a whitelist of domains.

Download

The userscript is hosted on Google Code as part of a new project, addedbytes-userscripts (along with previous userscripts released here). As usual, they are released under a New BSD License.

Usage

If you see the red box (and you will) and you're on a site asking for personal information, glance at the URLs to check there's nothing odd being loaded.

The domains whitelist is based on my own browsing habits - I wanted as few warnings as possible, lest the box become worthless (see a warning box too often and it ceases to warn). I strongly suggest you modify it to reflect the third party scripts loaded by sites you commonly use.

If you want to only use this on SSL connections (so pretty much only when you're checking out of an online shop), add this line to the script after the "@exclude" lines:

// @include https://*

Click the box and it goes away.

Improvements welcome.

Notes

This is not foolproof. There are fairly easy ways, as an attacker, to make sure that the box doesn't appear, or that your URL isn't displayed. It doesn't stop XSS either - just tells you when it might be going on. It's not an excuse for a lack of vigilance.

One problem is and will continue to be getting the balance between whitelisting enough domains (and so keeping the tool useful) and speed (for every domain you add to the exclusion list, every scripts source needs to be checked against that domain). For me, with the list at around 30 whitelisted domains, I see the box on few of the sites I use often and not too much elsewhere. And it's quick. Your mileage may vary however as you and and remove excluded domains to reflect your own browsing habits.

It's been interesting, browsing the web with this on for a few days (especially with no excluded domains). Some sites load a vast number of third party advertising and tracking scripts (Economist.com article pages - 17 scripts, MSN article - 19) in addition to their own JavaScript. Some tracking systems are better than others (loading a script from the host site initially before communicating with the third party). Some companies have an odd system of alternative domains for hosting parts of their site (ebaystatic.com, images-amazon.com).

I can't help but think that as XSS becomes more of a problem, browsers will start to look more at ways of preventing it, which will (inevitably, I would have thought) involve at some point the prevention of third party scripts from loading directly. Which may well lead to people loading third party JavaScript via a hosted script (so instead of having a script with the src attribute pointing to Google to load your AdSense, you'll point your script tag at a JavaScript on your own server which will in turn do the loading from Google - a sort of JS relay to prove the JS is supposed to be there). Some sites will find this easier than others to implement!


comments powered by Disqus