Securing the Web in 2018

JavaScript starting out as a way to make our web pages a bit more interactive, but over the past few years morphed into unmissable pillar of the web. But with it rise in popularity so have the attack vectors on our code.

Luckily there has been a lot of improvements into the security mechanisms available to us. Unfortunately almost all of them require us to take action.

In this talk we will go over all of the recent additions to the browser security stack and how you can massively increase the security of your site with relatively little work.

(upbeat instrumental music) – Thank you.

Now we’re gonna see if this thing’s on, the thing’s on! Welcome! My name’s Erwin, as Chris said, and I do quite a bit of speaking.

And one of the things I always tell other people when I’m training other people in public speaking is that you cannot really teach someone something in a conference talk.

You can inspire people.

But today I was going to set myself a challenge. I’m gonna try and teach you something in 20 minutes. And obviously, I wasn’t gonna go all by myself so I sort of consulted with a very, sort of, very old and dear mentor of mine for any sort of tips, and tricks, and insights in how do you teach people something in a really short period of time.

So I’m really gracious he’s sort of decided to help. Count von Count.

He’s a counting influencer.

And he gave me a couple of really good tips. So the first thing he says, “You wanna keep it really simple.” And he insists on counting being the thing. So sure, we’re gonna do that, and then sort of the other thing you need is you need something that is familiar with the audience. Like, the audience is intimately familiar with, which is why I’ve chosen the sort of nine sort of ways to secure your web application because obviously you’re familiar with that. So we’re gonna see if I can sort of get you to sort of count familiar things in sort of web security. So, first, we’re gonna count attacks.

Then we’re gonna sort of count cookies.

Like, all the ways you can secure cookies.

And then we’re going to, Jeez, I should’ve seen that one coming.

(laughter) And then we’re gonna talk about securing headers and sort of learn counting whilst doing that. So let’s go talk about the sort of attacks. When we’re talking about security and sort of web applications, right? We have a server serving us sort of JavaScript, and we’ve got in the age of JavaScript-based front-end sort of react applications, and angular, and view. And so what can we do in these sort of big, big applications? So, the first type of attack that we wanna sort of do is. This is one, all right? Can we try this? – One. – One.

There we go, thanks, Chris.

So number one, what is the man in the middle? And a man in the middle is a rather descriptive name for this attack cause it basically talks about this man, or a woman, it doesn’t really matter, in the middle between your client and your server. They can read things and they can intercept some traffic. And that’s sort of not a good thing.

So, number, – Two. – Two, there we go.

– Number two is cross site scripting.

And this is when someone manages to inject some JavaScript into your website.

This sounds really hard to do but, yeah, if you’re in a security space, you know that it isn’t.

It’s actually relatively easy and not good. Attack number, – Three. – Three.

– We’re talking about cross site request forgery, which is a really non-descriptive name, but basically what it means is we’ve got a bad server and we’ve got a client that’s sort of served to this bad, bad website.

But then this website sort of has a link or sort of anything else, that makes a request to your perfectly good server, but because the browser is configured to sort of send cookies and all this other sort of good stuff to your website, it’s very hard for you to detect sort of whether this request came from your website or someone else’s website, sort of cross site request forgery.

Attack number, – Four. – Four is click-jacking.

– And this is a really interesting attack where someone overlays something on top of your website, or the other way around, that’s a bit harder to do. But someone overlays a translucent thing over your website so people think they’re on your website, but every time they click, they click on the overlay. Yeah, they do so things do that.

Again, not good.

So, let’s go and sort of repetition cause that’s the third thing Count told me to do, we should repeat this often, right? So, man in the middle, his number? – [Audience] One.

– [Erwin] Cross site scripting? – [Audience] Two.

– [Erwin] Cross site request forgery? – Three. – Three.

– [Erwin] And click jacking is number, – [Audience] Four. – [Erwin] Four.

– We’re doing really, really well.

Yeah, Cookie.

So, how can we sort of help protect against these four types of attacks? So cookies, one way of doing it.

Couple things we can do with cookies.

And the thing is all of these things are so very easy. This is, we’re talking basic hygiene this sort of here to do, alright.

And the first one of these is secure.

Secure means only sent this cookie over HTTPS. Because obviously, already serving all of your content on over Https because it’s 2019.

And if you don’t, join us in 2019 and serve your website over Https.

But secure means this cookie will never be sent over HTTP. And a lot of people sort of go like, “Well we don’t really serve anything over http,” and I go like, except when you use your types and your URL and your browser and it sorta does. Secure means it will never get sent.

So if you have sensitive things always set the secure. Number two is HTTP Only.

HTTP Only means that this cookie will only be ever sent with Http request and it’s inaccessible to JavaScript.

Now, this doesn’t actually prevent things like cross site scripting, but it does limit the damage you can do if JavaScript in the browser cannot access the cookie. So it’s a great way of sort of securing it even further. Number three, same site.

This is a relatively unknown one that is extremely powerful. And basically what you can say is, “Only send this cookie if the origin of the page “is the same site were sending it to.” And that means all of your sub-domains, as well. But really, really powerful to prevent against cross site request forgery, where you an easily go only on my domains will it send this cookie to the back end.

There’s two settings on these, lax and strict, that you’re gonna have to so do your own research on them. The basic is that one is lax and the other one is strict.

That’s sorta what it does.

It’s a whole different system.

So here we go again, ready? Yeah? Secure is? – [Audience] One.

– [Erwin] Http Only is? – [Audience] Two.

– [Erwin] Same site is? – [Audience] Three.

– Three you’re doing really, really, really, well. Alright.

So this is what the perfect cookie looks like. We’ve got some settings, some session thing secure Http Only and same site, either lax or straight. (audience laughs) who saw that one coming? Alright, headers.

This is gonna be more challenging cause there’s six of these.

All right, we’re gonna go all the way up to six now. First one of which is x-content-type-options. Explaining this takes about 20 minutes.

The gist of it is IE tried to be really smart way back and it turned out to be not good and this turns that off. (audience laughs) I’m like, well, I don’t really do all IE but it’s just a header.

just set it, get it over with, all right.

Basically tells IE I know what I’m doing.

Stop making decisions for me.

Two, Referrer.

Referrer is one of those things that we sort of know what it is, but often forget about the implication. And that’s basically every site that people never get to from your page gets the URL in one of the headers. And the referrer header that the browser sent us through. And that’s not that bad until you realise that we sort of now sending through IDs that people shouldn’t know. And session tokens that people shouldn’t know. And sometimes there’s stuff encoded in the URL that you don’t really want the other site to know. And there’s this header called Referrer Policy where you can tell browsers what to send through the next. You can completely disable it and they’ll never send one. Or this really descriptive? Well, no.

But basically strict-origin-when-cross-origin means if you go somewhere else that isn’t my site only send the base URL.

So your link doesn’t link to the page slash blah, blah, blah, blah, blah it’ll cut it down to sort of link doesn’t reach. Just the main domain.

So it doesn’t give away any secrets accidentally or not. Again, it doesn’t take long to implant this. Number three, X-XSS-Protection.

They really make these headers, like they choose names based on how easy they’re pronounced. For if you’re giving a talk about these things. But basically browsers have a whole bunch of cross site scripting detection built into them. But because it’s not necessarily backwards compatible you need to opt into that.

And that’s what this does.

It tells the browser, if you happen to detect any cross site scripting attacks going on just, uh, don’t please.

Sort of be nice.

If you could just not do that.

That’s what it says.

It, one, turns it on.

And so the block setters just stop.

Everything for free.

Number four.

X-Frame-Options.

X-Frame-Options means don’t allow this to run in the iframe. Which, given the state of the web, is a pretty good thing. We could all do this and get rid of iframes. That’d be nice.

So this means your…

This particular page, will never been better than an iframe.

A browser will just completely refuse to do it. Which if you’re worried about click jacking, this is a great way to prevent against this cause your site can’t be iframed.

Now if, for some reason, you want to iframe your own content and after you’ve evaluated your life choices and come to the conclusion that this is still the right thing to do, you can do things like sameorigin.

Which mean I can iframe.

If other people wanna iframe your stuff and you’ve taken another hard look at yourself and decided that this is still a good thing to do you can sort of white list origins where you want this to happen.

Again, bunch of security absolutely for free. Well, one header.

Now we get to the more interesting ones.

Strict-Transport-Security.

Strict-Transport-Security means only ever talk to me over SSL ever again.

Well, for max eight seconds.

It means never ever talk anything else to me but SSL. Or Https, TLS.

You can include your sub domains, not just my main domains but it’s all my domains. And that means that after that first request even if they type in the URL of your site in the browser window it’ll go over https.

Even if they follow a link to the https site, the browser will still direct that traffic to https. If you have…

You wanna be a little bit careful with it cause if you have content that is only accessible over http, then you’re gonna break this because even if you have links to any of your old stuff everything will go over https.

This is a really, really cool header.

Even more fun is to include the preload directive. And basically what this does is it tells, so that you do this and you fill in the form HSTS sort of pre-loads and they will include your site in…

Like they will bake it inside browsers.

There’s a listing Chrome and Firefox and I think in IE as well now, where every update they ship this new list and that means your site will never ever be accessed over http ever again.

Alright, and here we’ve come to the holy grail of cross site scripting which is Content-Security-Policy.

As a relatively new spec as well but it’s absolutely amazing cause you can tell the browser exactly what this page is allowed to do.

You can sort of go like a default source.

Means unless I specify anything else this page can only talk to self, which is your own sort of origin, or some other URL.

If you do this, nothing but these two URLs are accessible to your page.

But you can go script source.

You have a very finely grained talk about what, where JavaScript can be loaded from.

You can disable inline scripts altogether, which while great in sort of theory doesn’t work all that well in practise.

Which is why we have schemes like nonce where you generate a random number on every page request and unless the scripts have that random number they’ll just get ignored.

So even if someone is able to inject the script without that random number, they won’t be able to do anything.

So the connect source, this means your fetch and your xml-http requests can only ever connect to these backends.

We’ve got form actions.

Never submit a form to anything that isn’t white listed here.

And 22 other directives.

When I told Count that he got giddy with excitement. (audience laughs) I was gonna do nine first so my next conference talk will be all 22 of these, I promise.

But I thought it was a bit too much to do that right now. You ready for it? We’re gonna start at the cookies.

Alright, we’re gonna start at the cookies.

Here we go.

Secure.

– [Audience] One.

– [Erwan] Http Only.

Two.

Same site.

(audience joins in) Three, yes. Alright, we’re gonna keep going.

Alright, we’re gonna keep going.

We’re going to four for X-Content-Type-Options. Referrer is five.

X-XSS-Protection six.

(Erwin sighs) Almost there.

X-Frame-Options, seven.

Transport-Security (sighs) Eight.

And this little number here is nine.

Thank you very much, you were an amazing audience. (applause) (upbeat techno music)

Join the conversation!

Your email address will not be published. Required fields are marked *

No comment yet.