Security Sense: You’re Responsible for the Third Party Services and Code You Use

Increasingly, software on the web is becoming a mashup of individual services all coupled together to provide one unified experience when someone visits a site. This site, for example, uses a variety of third party services including Google Analytics and AdSense, both of which load content from another provider then render it in your browser (assuming you’re not blocking them, that is). My own blog pulls in Disqus for comments plus a whole bunch of various JavaScript and CSS libraries from CDNs.

All of that is just on the client side, that is it’s content loaded directly into the browser. The dependencies of modern websites extend far further than that on the server, often embedding various third party libraries that connect to other services, process user input and render content to the response. All of these classes of dependency have had serious security risks in the past and here’s the really tricky thing: if you run the site using them, you’re responsible for them when they go wrong!

I was prompted to write this after some recent “enthusiastic” debate in a closed forum where an organisation had found themselves to be the delivery channel for some nasty malware. However, it wasn’t them that was distributing the malware, it was the ad network they’d chosen to use and the debate centred around the assertion that it wasn’t fair the organisation in question copped the heat for it. If we were to have a purely technical argument and apportion blame to the source of the incident then they’re quite right, however that’s not how these incidents are perceived.

Think about it from the consumer’s perspective: they go to a company’s website and are served malware – who are they going to blame? Do they want to hear “well, we let an ad network run whatever code they liked in an iframe and they sold advertising to a malicious party and that’s why all the files on your PC are now encrypted and you have to pay Bitcoin”? No, the consumer couldn’t care less, all they care about is that they went to the company’s website and now they’ve got nasties loose in their machine.

Same again for all the other classes of things that go wrong due to someone else’s code running in a company’s website. WordPress plugins are notorious for having had a litany of serious security incidents in the past but if someone’s website gets SQL injected and all the data sucked out, it’s still the site owner that will cop the blame. After all, it’s the same end result as if they’d written the bad code themselves and the customers who’ve lost data will still blame them in the same way.

It’s not an easy problem to solve, I’ve had XSS on my blog in the past due to the nature of how ad networks operate. But make no mistake about it, I’m accountable for that! Likewise, if my site is one day the channel through which Cryptolocker is delivered to unsuspecting victors then I’ll be the one apologising and will not simply be able to say “Hey, not my fault”. Just in case there’s any doubt as to how many dependencies we have on external code these days, try running Wappalyzer in Firefox and see just how much external content is pulled into the site (you can see an image of it for this website alongside this article).

I’ll leave you with a final thought: if you’re responsible for a website, how many external dependencies does it have? How much of other people’s code is in there? How dependent is it on the practices of a third party such as an ad network? And perhaps most importantly, how do you ensure your customers aren’t going to be compromised by vulnerabilities in areas you may have never even thought of?