What if I told you... that you can get visitors to your site to automatically check for a bunch of security issues. And then, when any are found, those visitors will let you know about it automatically. And the best bit is that you can set this up in a few minutes and add it to your site with zero risk. Or if you like, set it up so that it can automatically block certain types of attacks.
It's not an expensive appliance, it's not a wacky browser extension and it's not some weird proprietary code implementation. Instead, it's all open standards built into modern web browsers and it's all available for free, right now. Well, it mostly is, the main gap is that in order for your visitors' browsers to tell you about these threats you need a way of logging and reporting on them. This is what Report URI does and that's why I'm joining the company. But I'm getting ahead of myself, let me take a step back and explain what this is all about.
About Report URI
This is a service created by a good friend of mine, Scott Helme. You may remember Scott from such blog posts as hacking the Nissan LEAF and indeed previous posts of his such as when he tore into NOMX. Scott has carved out somewhat of a niche for himself within the security industry by going especially deep into browser security headers and TLS. For example, he runs the site securityheader.io which can give you a really neat report on how well a site is using the very thing implied in the URL itself. He's also been involved in delivering what is literally titled "The World's Best TLS Training".
3 years ago, Scott launched Report URI, a service designed to enable website operators to have CSP and HPKP violation reports submitted to his service and then reported on. He ran this as a hobby project and it grew to impressive numbers. As of today, Report URI processes billions of reports every month across 9,000 unique subscribers. Some of the biggest sites in the world use this service, including a bunch of them in the Alexa Top 1,000. They see value not just in CSPs in particular, but in the ability to aggregate and report on violations raised in people's browsers.
Now I've written about CSPs at various times in the past, but let's just have a quick recap here now:
About Content Security Policies (CSP)
When you stand a website up, anyone can go into the browser dev tools and modify the DOM. For example, go to almost any website then grab this script, open up your browser console and paste it in then hit enter. (Incidentally, don't do this with any script you don't trust, Facebook literally pumps out a big warning message in the console explaining the risks of self-XSS.) And now the page is doing the Harlem Shake which results in much hilarity. But is this representative of a security risk? I mean does it even matter that someone can modify the DOM on their own machine?
Let's look at it another way instead – for a site that may have an XSS risk (and remember, this is still the 3rd biggest risk on the web today), how does the browser know what's malicious script and what's not? There's some degree of XSS defence in modern browsers, but that's not going to help you if, say, there's a persistent XSS risk and someone gets script into your database. Or on the more obscure end of things, if someone embeds an XSS attack in the TXT record of a DNS entry which then renders into the output of a WHOIS service (yes, that's really a thing and it's awesome!) Using a risk like this, an attacker can do anything from changing the POST path of a form to embedding their own content on the page to siphoning off non-HTTP only cookies to loading other content into the page from foreign domains. Once you can start running your own arbitrary JavaScript in someone else's browser, the world is your oyster.
Now of course, you should do all the things good developers know they should do to prevent XSS attacks, specifically output encoding all untrusted data, but clearly this doesn't always happen. Just the other day we saw this with Equifax and this was after their major breach when you'd think they'd be pretty set on making sure all their security things are solid. And this is precisely where the value of a CSP begins to shine.
By using a CSP, you can be very specific about what content is allowed on a page. Taking the examples above, a CSP can specify where a website is allowed to post form data to, where it can embed content from and where it can make other external requests to (among many other things). It's typically added as a response header which means that even when XSS exists on a site, this doesn't give the attacker access to control the headers thus it's not a defence they can readily remove.
To the point of the Harlem Shake demo, yes, the ability to arbitrarily load in content from an unintended third party does demonstrate a security risk. I've highlighted this by using a script you run yourself in your own browser but for every website that successfully shakes and plays annoying music, an inadvertent XSS flaw could use the same fundamental principle to actually do serious damage. If you want to see how a site should respond once a proper CSP is in place, try that same script on Have I Been Pwned (HIBP) and see how that works out for you ?
This is Not Just About XSS
Content security policies go well beyond just XSS. For example, they can specify which other sites are allowed to put your own site in a frame thus mitigating the risk of clickjacking attacks (yes, this is roughly equivalent to the old x-frame-options header).
Indeed, Report URI goes beyond just CSP too, for example by supporting HTTP Public Key Pinning or as we also know it, HPKP. Then there's the Expect-CT header and Expect Staple, both of which can report exceptions back to Report URI. As with CSP reporting, the service enables you to log, aggregate and report on the results which is a really neat way of bundling everything into one place.
Another especially neat trick is to use a CSP to upgrade insecure requests for content on a page. Let me explain: one of the greatest barriers I hear from people about moving to HTTPS is that they have to go through their site and change every embedded HTTP reference to HTTPS. If you don't change, for example, an image embedded over HTTP yet you load the page over HTTPS then in a browser like Chrome you lose your padlock, your green HTTPS scheme at the start of the URL and the “Secure” text that normally sits alongside it.
I actually wrote specifically about this just a couple of weeks ago in The 6 Step "Happy Path" to HTTPS which coincided with the launch of Chrome 62. You know, the browser which now does this whenever you enter anything into a form on a non-secure page:
I'd actually hoped to be able to announce my involvement with Report URI before pushing that post out but it was more important I gave people usable info to coincide with Chrome 62 than it was to wait for Report URI v2 to be ready. Which brings me to that - let me talk about my role.
My Role with Report URI
Scott wrote about the next steps for Report URI just before I published this piece so you can always go and read his take on it there. But for the sake of completeness here, there are 3 main things I'm bringing to the company.
- Money: Scott is now working on this thing full time and he needed funding to get it to the point of financial sustainability. I'm investing both dollars and effort in return for a share of the company.
- Profile: I've got a healthy following in the security and developer communities and the latter in particular can really help get this project traction. I'm going to be talking a lot more about how devs can use this tech in cool ways that most people I speak to have never even considered before.
- Expertise: I bring a bunch of professional experiences that compliment Scott's and Report URI is stronger for having the both of us. We're working together to build this into something awesome.
We've been working on this together since June when, like so many great ideas, it came about over beer. We were both in Oslo for the NDC conference and Scott was passionately talking about Report URI and some of the great ideas he had for it. He wanted to focus on it full time and had great projections for commercial potential based on the years of experience he had already running it, including experience with existing commercial customers.
I'd also been using it for years, especially as a way of helping developers understand CSPs during the workshops I run. I was seeing first hand those "light bulb moments" where developers would see these in action and go "oh wow". But I also know that the number of people who actually understand the value proposition is extremely small; Scott's August scan of the Alexa top 1 million websites (he prepares a 6-monthly report on a bunch of trends) showed that less than 2% of sites are using the tech. But his stats over the last couple of years also show the uptake is growing massively:
From the perspective of how big the potentially addressable market is, it's huge.
About Scott Helme
I got Scott to proof read this blog post before publishing just to make sure I had everything straight. Except this bit - he didn't get to proof read this ?
I first met Scott in Jan last year. I was running a workshop in Bedford in the UK and he travelled down from his home in Manchester to meet me in person. We'd "known" each other for a while, but it's one thing to chat online and quite another to down beers together.
Scott was at the beginning of building his own personal brand. He was writing some awesome material and doing great work (including with Report URI), but was nervous about moving beyond that. Myself and others had been nudging him towards public speaking at tech events because his material was so good, but he was nervous. Tentative. A relatively quiet bloke.
Fast forward only about a year and things were really different. I'm seeing the guy pop up all over the place not just in the press for the work he's done or the expert opinions he's increasingly being sought for, but on the conference scene too. And then, before you know it, he's at Blackhat in Vegas with a BBC film crew entourage making serious TV:
Another hard day's hacking from @Scott_Helme with @BBCClick at #BHUSA17 pic.twitter.com/SFhmLh8G89
— Kate Russell (@katerussell) July 26, 2017
Or something like that. The point is that he's come a long way in a short time and is on an awesome trajectory. Scott's a genuinely lovely bloke too, someone who can not just go deep on technology, but who can also hold a conversation with "normals" about why it's important and what it means to the masses.
During that Oslo trip a few months ago, my wife and kids spent a bunch of time with Scott both in Norway and then in the Netherlands. As I've said before, Kylie's support in everything I do is really important (link to the point in my "Hack Your Career" talk where I cover this), and she was 100% on board. Not because she understands CSP, but because she's come to know and trust Scott. We're both confident enough in his vision for this project that we were happy to invest in him and what he's doing.
I wanted to share this here because Scott is such a huge part of why I've invested in Report URI. It's about so much more than just the technology, it's about having trust and confidence in Scott both professionally and as a good bloke. So yeah, no pressure mate!
What's Next?
Well firstly, I'll still be doing all the things I normally do and Report URI isn't a major commitment for me time wise. I'll still be working tirelessly on HIBP, speaking, training and writing, but I also expect each will influence the other. I'd like to write more about the mechanics of things like Expect-CT and Expect-Staple, for example. It'll be great if people then turn around and use Report URI to track any exceptions but even if they don't, I'll have fun writing those posts and delving into something a little different.
So that's what I'm up to, I'd love you to jump into Report URI and give it a red hot go. We've structured the pricing to ensure that everyone can experience the features for free and in fact, for many sites it won't cost a cent to use (commercial plans start once you're logging 10k reports a month). Do share your feedback with us, I think we're onto a great thing here and I'm really looking forward to growing it into something awesome.