Our wholly insecure web

The internet is poorly designed from a security perspective and last week’s Tweetdeck Twitter client cross-site scripting incident serves as a salutary reminder.

Having left the web version of Tweetdeck running in a browser tab, I like many other users of the otherwise excellent Twitter app encountered a dialog on the page that shouldn’t have been there.

That’s panic stations time, because it could have meant having fully lost control of my Twitter account with all sorts of reputational unpleasantness arising as a result.

Ars Technica’s take on the event, which was “Powerful worm on Twitter unleashes torrent of out-of-control tweets" was particularly good.

At first, calling it a worm seemed over the top but as Twitter user Tom Scott pointed out, the XSS that was found by accident spread to millions of people very quickly, and there was no interaction needed on their behalf to fall prey to it.

Congratulations @BBCBreaking for not logging out, and sending a self-retweeting hack to 10.1m people (h/t @dracos): pic.twitter.com/S6haCHkfn8

— Tom Scott (@tomscott) June 11, 2014

Now imagine if the XSS had been loaded with more malicious content than just a pop up dialog.

Twitter, which owns Tweetdeck, fixed the issue quickly. But has Twitter removed the chance of it happening again? Is Tweetdeck safe from future XSS vulnerabilities (as well as others)?

That’s doubtful because Twitter still has to work with existing standards and be compatible with users’ browsers.

The persistence of XSS is due to a fundamentally flawed design of mixing content with executable code on the web, and a desire not to break it in an attempt to improve it.

That’s the same thinking that leaves email susceptible to delivering malware and spam by the gigabyte and serving as an attack vector for digital miscreants.

As with other fundamental design flaws, the deficiency that permits cross-site scripting isn’t taken seriously. When the XSS holes pop up, they’re plugged on a case-by-case basis with the attack vector that appeared in the '90s remaining for the foreseeable future.

As a security researcher said to me recently: “XSS is often dismissed on its own as being a throwaway flaw, but as part of a larger campaign, you can use such bugs as part of a much more serious compromise.“

Indeed.

XSS is only the tip of the insecurity browser iceberg. Cookie snatching, clickjacking, framing, cross-site request forgery are other vulnerabilities that are difficult to defend against, and require sleeping with one eye open and applying patches on a piecemeal basis.

Yes, there are ways to protect your sites and users against XSS. The Open Web Application Security Project XSS crib sheet is a good start. 

The prevention cheat sheet amounts to a lot of work in order to provide the basic functionality users expect. 

A web browser is a powerful application but using one really shouldn’t be a game of Russian Roulette.

Now that we’ve consigned our business processes, government interactions, democracy and life in general to the web, shouldn't we work on ensuring that we can do that without putting all those things at risk?