When he's not tuning web performance and building things in the Cloud, Robin Osborne spends a lot of time scrutinising web application security. Here, he gives the lowdown on one of the most notorious exploits around...
(Robin's the one enjoying a hot beverage in the sidebar, not the dodgy hooded fellow)
Cross Site Scripting (XSS) attacks have been around almost as long as the internet itself; there are examples of dating back to the nineties. It's one of the most persistent and prevalent threats, appearing in the OWASP Top Ten web vulnerabilities every year since it began!
A cross site scripting attack can consist of an attacker executing malicious JavaScript on a victim's browser (for instance by getting them to click on a crafty link in an email), allowing the attacker to steal the victim's authentication for a particular website.
For example, if I could steal the authorization cookie that lets you stay logged in to Facebook, then I could overwrite my own cookie with yours and presto changeo, I'm hitting "like" on all the rubbish photos your friends take of their food on your behalf! (it's worth pointing out Facebook are pretty hot on this and offer big bounties for any XSS exploits found in the wild).
Not scared of unwarranted Facebook comments? How about executing other common hacks that enable a remote attacker to gain significant control of your browser and even the computer it's running on? It's scarily easy for the moderately determined evil-doer.
Another attack vector could be a compromised version of a JavaScript library that you've unwittingly called from your own website. Imagine if the externally hosted version of jQuery you're using suddenly included a keylogger, tracking everything your users entered on the credit card details page...Ouch.
Earlier this year a large number of websites which had implemented a popular accessibility widget started unknowingly serving their users cryptocurrency-mining JavaScript code.
Large organisations were affected, including the NHS, the ICO and the U.S. Courts.
This impacted not only the responsiveness of their own websites, but also slowed the user's entire device while their CPU churned away making moneyfor enterprising miscreants.
This is a real life example of why we shouldn't implicitly trust 3rd parties to add code into our own websites.
The Content Security Policy (CSP) is a reasonably new standard for browsers to receive configuration in an HTTP header which informs the browser what that page is allowed - and not allowed - to do.
For example:
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
This header example allows images from any domain, media from media1.com and media2.com only, and scripts from userscripts.example.com - anything that doesn't match this, or isn't loaded from the current domain (default-src 'self') will be blocked by the browser; the request will not even be made.
The header can determine the domains which we're allowed to load JavaScript from; and even be really explicit, like forcing that resource to have a specific hash using subresource integrity!
<script src="https://code.jquery.com/jquery-3.1.1.slim.js" integrity="sha256-5i/mQ300M779N2OVDrl16lbohwXNUdzL/R2aVUXyXWA=" crossorigin="anonymous"></script>
CSP allows the website owner to put up a fence (or a security turret lined, crocodile infested, moat) and be very strict about what can and cannot run on their site. This is not only useful from a security perspective, but also from a performance one; you can limit 3rd party requests from loading certain scripts or from certain domains you know to be slow.
So if you haven't looked into CSP, it's definitely worth checking out - it's just one of the vital instruments you should have in your IT security toolkit.
Want to learn more? We can help! Give us a call on 020 3137 3920 to find out how we can give your architects, web developers, database specialists and testers practical hands-on skills to help fortify and defend your online presence.
