Observations, musings and conjecture about the world of software and technology

Monday, 20 August 2012

Why XSS is serious business (and why Tesco needs to pay attention)

Monday, 20 August 2012

It was three weeks ago now that I wrote about Lessons in website security anti-patterns by Tesco where I pointed out a whole raft of basic, flawed practices which jeopardised the security and privacy of shoppers. These practices in and of themselves were (are) bad, but what really seemed to fire up a lot of people was Tesco’s response when I first flagged it with them:

This was just last week and well after the “robust” theory had been well and truly rejected by a great number of people who actually know what robust security looks like (or least know what it doesn't look like). Of course this same canned response was used many, many times to people raising legitimate concerns so I’m sure it’s nothing against Craig in particular.

But Tesco have security problems that go beyond what I originally wrote about, far beyond. At the time, I speculated that this was reminiscent of the Billabong situation where there were numerous bad security practices easily observable in addition to the ones which allowed an attacker to steal 21,000 account details. So it was no surprise when people started commenting about additional vulnerabilities such as SQL injection (unverified) or personally emailing me details of risks such as cross site scripting (verified). It was also no surprise to hear that many people had raised security concerns with Tesco over many years but to no avail. After all, they’d “never been hacked” (their quote) so things must be robust, right?

Let me get to the point of this post; I had someone from Tesco connect with me privately after which I asked for some technical contacts I could pass on information to. I’m not going to publicly divulge any names or positions publicly, but what I can say is that I was given the details of multiple people in senior technology roles after which I then passed on (anonymised) details of the cross site scripting (XSS) risk that was sent to me. That was two and a half weeks ago so nearly a week later, after receiving no response, I followed up on the original message. Nothing. Nada. Zip. And the vulnerability is still there.

What you need to know about XSS

At this point I want to stop talking about Tesco specifically and turn this around to a more constructive post; things you need to know about XSS. I’m going to approach this a little differently and provide a video as it requires a bit of social engineering which is best illustrated in real time. A number of the risks you see in this video are present on Tesco’s website but equally, some of them are not. Clearly I’m not going to disclose any detail which will allow someone to go off and get involved in malicious activity, but what I am going to do is show how XSS can be used to cause serious trouble and that’s what I hope Tesco (and others) can begin to appreciate.

Just on the browser compatibly for that XSS: IE9 and IE10 are actually pretty good and will warn you about it without exexuting it. All other browsers tested – Chrome, Firefox and Safari (desktop and iOS) – will happily parse it and allow the exploit to occur.

Summary

As I said earlier, not all the risks I’ve highlighted in the video may be present on Tesco’s website and I’ve intentionally avoided reproducing the specific circumstances where they are vulnerable. Some would argue that sufficient time has passed since responsible disclosure to publish details, but I don’t think that is necessary regardless of how frivolous Tesco believe the risk is. But certainly there are enough of these risks to be very concerned though, definitely more concerned than leaving it unfixed for days let alone weeks.

Interestingly, it seems that Tesco’s rather unique approach to security is now coming under scrutiny from the Information Commissioners Office in the UK. Whilst a statement such as "We are aware of this issue and will be making inquiries" is far from a damning indictment, it will be interesting to see how this unfolds and whether the company may actually be called on those “lousy” practices.

To wrap up on the general XSS discussion, there are really two key things which absolutely, positively have to happen but often don’t:

All output must be encoded for the context in which it is emitted. HTML, HTML attributes, CSS, JavaScript, XML, XML attributes etc. Not getting the context correct or even worse, not encoding at all can be disastrous.

Other lax security practices can then be combined with XSS to make the site more readily exploitable; cookies which aren’t flagged as HTTP only, for example. Plus of course there’s good old social engineering to help exploit reflected XSS.

Then there’s the fact that in terms of web app vulnerabilities, XSS gets very, very messy. How? Well to begin with different browsers implement different levels of defence. For example IE10 protects against some of those earlier examples where latest gen Chrome and Firefox don’t. Then there’s the fact that XSS is only roughly related to semantically correct HTML; browsers frequently allow markup to be parsed which shouldn’t be, for example IE6 will happily parse a tag like <IMG SRC='vbscript:msgbox("XSS")'> which contains VB Script. The XSS Cheat Sheet will give you a sense of just how obscure things can get.

As always, we’re back to security in layers. One particular flaw may not appear too serious but combined with other risks, things can get very nasty very quickly. Mitigating XSS on the vast majority of websites is simple – I mean really simple, at least for things like whitelisting and output encoding. The website used in the video above was easily made insecure just as it is easily made secure and you download the whole thing from GitHub (including comments on how to secure it) from the resources below.

Resources

The codebase for the “robust” site used in the video is publicly accessible over on GitHub under ShopWithRobustSecurity

Copyright 2014, Troy Hunt

Disclaimer

Opinions expressed here are my own and may not reflect those of my employer, my colleagues, my mates, my wife, the dog and so on and so forth. Unless I'm quoting someone, they're my own opinions and may not necessarily be cohesive nor entertaining but hey, at least they're original.

Designed by me

All original because I'm fussy and you just never quite get exactly what you want from a Blogger template. Besides, the left side of my brain rarely gets out these days and it needed the exercise.