Cross-site-scripting flaw on our own site (resolved)

Earlier today, Twitter user @adam_baldwin mentioned finding a security flaw on our site. He reported this to us (thanks!) and we fixed it, then another Twitter user @mattmcgee asked what it was. It helps everyone on the Internet be transparent about security, so here’s an attempt at an explanation.

What Adam noticed was a Cross-Site Scripting (XSS) vulnerability on our “My Account” login page. If an attacker could somehow trick one of our customers into following a specially crafted malicious link or form to that page, the attacker could cause extra text to appear, or cause extra JavaScript to run, as part of the page.

Such a flaw creates several potential security problems. As a trivial example, an attacker might add an alert message saying “This page is broken, so e-mail your password to evil@example.com instead if you want to login”. More subtle examples involve running scripts that attempt to steal passwords or “session tokens” directly (although we also take other measures to block many such attacks).

The reason this particular vulnerability existed on our page was that if you entered a completely invalid domain name, it redisplayed exactly what you entered as part of the error message without “escaping” or “sanitizing” it. (This lack of “escaping” was due to a bug that was introduced when we added a new feature.)

If you’re programming HTML scripts that redisplay user input, you can never trust data provided by users: what you think of as “an invalid domain name” you’re going to redisplay might actually be a string that ends the current HTML tag, starts a new tag, and does something malicious. To prevent this, most programming languages give you a way to automatically “escape” strings you’re going to display in the browser, such as PHP’s htmlspecialchars and Perl’s escapeHTML.

If you write scripts and you’re not familiar with XSS attacks, or with the related Cross-site Request Forgery (CSRF) attacks, you should take a few minutes to learn about them, ensure you’re taking steps to avoid problems, and review your existing forms to make sure they’re not vulnerable. After fixing this, we spent a couple of hours examining and auditing all the other forms on our site today, too, to ensure they don’t have similar problems — an occasional review is always a good idea.

If you’re one of our customers and you’re not quite sure what this all means, and you’re wondering if your data is secure, you almost certainly don’t need to worry. You’d only have a problem if an attacker tricked you into following an external malicious link to our “My Account” login page and you fell for the trick. It isn’t something that could be a problem if you were logging in normally using the links on our site.