Browsers Are Magical Creatures

Alrighty, web browsers started off as just one of the apps we used on our computers.

Alongside Outlook for our emails, Word for our documents, Excel for our programming, Napster for our music.

We had a bunch of different applications and web browsers were just one of them.

It sat in a corner, you connected to it, you used it when you connected to the internet for 15 minutes a day on dial up or something.

It wasn't really much, it was just one of the other apps you used.

Now, web browsers are everything.

We use them for basically everything we do on our computers.

If you think about it, when you go into your computer, when you start using it, what's the first app you open?

Is it Chrome or Safari or something?

You've got your emails through there, your calendar, your to do list, you go watch videos, listen to your music, talk to your friends, social media.

All the different things we do in our computers, most of them run through a web browser in some form.

We even have web browsers that don't look like web browsers, like these things, they're all web browsers, like Visual Studio Code is a web browser, which is just nuts when you think about it.

So web browsers, they do a lot of stuff.

They do, and so we use them for so much of our, for our lives and so much of what we do.

And so as developers and as people that run Web applications and things like that, we need to be aware of what they can do.

And our primary role, at least in my opinion as a security person, our primary role as a web developer and someone who manages a website, is to keep our users safe and keep them secure.

So we need to be aware of the different security features we can use, and the ways of making our site secure and our site safe so we can protect our users.

Protect their information, protect their data, protect their computers from being hacked.

Now, I don't have, my kids aren't into unicorns, but you could consider, a web browser like a unicorn.

Does lots of cool, shiny awesome things.

I think a better creature to describe a web browser is probably one of those things.

I'm also a big Lord of the Rings fan, get rid of it.

So yeah, so you want, web browsers are big, they're mean, they're scary, they do a whole lot of stuff.

And you really want something like this to protect you.

The best place to get started when you're looking to secure your website is securityheaders dot com.

And we'll just jump over there now.

And this is a great site because it allows you to run a scan on your site and see what security headers are missing based on, the current recommendations.

I don't know, let's check Amazon dot com.

It's going to give us a big A.

So if you know the SSL Labs SSL Checker at all, it's a similar sort of concept.

Where it's going to give you a rating depending on how you're doing.

And as you can see here, it's got, six headers that it's checking at the moment.

So we've got Amazon dot com is doing well.

I don't know, MyGov.

How's that looking?

Any suggestions?

Oh, hey, that's good.

Any suggestions for a slide I should check?

I'll just check one.

I already had it prepared, sorry.

It's funny, I just went and looked at this and thought, oh, why is that orange?

Yeah, the head has been, anyway.

Anyway, I'm not going to bash it too much.

Alright, that's my site, by the way.

Nice big A and Laravel, which I use as a D, I need to make them fix it.

Anyway, What we're going to do is enable all the headers on this site.

And I'm going to show you how easy it is to enable basically all of the headers.

This is something that you can do on your own sites quite easily.

Starting at the top, we have strict transport security.

And the idea of this header is it tells the browser all of the connections from the browser for the client over here has to be encrypted when it's connecting to the server, which means that, when you go to your browser and you type in, google dot com, by default the browser will try HTTP first, and if that doesn't, yeah, if it doesn't work, it doesn't work, it tries that first and Google will tell the browser, upgrade, redirect to HTTPS.

The problem with that is, if you can see to the middle, you can get what's called a downgrade attack.

And so you're the client over here and the server over here.

You type in the domain name.

The browser is going to try HTTP.

And then you intercept it in the middle, which you can intercept because it's not encrypted.

And then you sitting in the middle, you can make an encrypted connection to the server, which expects an encrypted connection.

Do whatever you want to the request, send it to the server.

They send it back to you hiding in the middle.

You send back an unencrypted request to the user over here, the victim.

And as far as they're concerned, the site doesn't work on HTTPS.

And you can make whatever changes you want, listen to whatever they're doing in the middle.

But with the strict transport security header, if the server has told the browser that it, if the browser has seen this header from a response from the server, the browser will always require encryption, always require HTTPS.

Which means that when you type in, say, google dot com, it will never try HTTP, and the person sitting in the middle cannot intercept it.

It will always be encrypted, which means it always connects to the server, which keeps it safe.

And the max age on there tells it the number of seconds the browser to remember.

So the first one the browser sees the heading, it remembers it for that number of seconds.

Say if you set it for a year.

Then every time within that year, the browser tries to connect to the server again, it will always require encryption and you can never downgrade it to HTTP, keeping that safe.

You can enable, oops, no, just a thing behind me.

You can enable include subdomains, which means that all the subdomains on your domain, so like a dot example dot com, b dot example dot com, the first one of those that you hit is going to set the strict transport security header for every single sub domain and the main domain on that site, so it's always going to be encrypted.

Which again, makes it easier because you only have to hit it once, then every other encryption, connection is encrypted, keeping you safe.

The third option we have is preload, which solves the TOFI problem, the trust on first use problem that you might have noticed at the start.

What this means is, the first connection before you've seen the header, you have to trust it.

So if you can get in the middle between the victim and the server, on the first request, the victim, the client, doesn't know that the strict transport security header is there.

So they will send the unencrypted version, you can intercept it.

But if you add it, add the site to the preload list and you'd find preload in the header, then the browser itself will be shipped with the, with that, with the header and so the browser will know.

And so this is called the HSTS preload list.

And this list is a list of domains and extensions that require HTTPS.

And you can add your domain to it simply by using that bottom one down there, set the max age to a year or two years minimum.

I think it's one year is the minimum for it.

And if you add that onto your site.

Submit it onto the HSTS preload site, then future browser updates will include your domain name in the list.

And the browser will require encryption on every connection.

And if you're familiar with the dev and the app domain extensions, they're on the preload list.

That's why if you use one of those two extensions, you need encryption.

You cannot use them on HTTP only.

So if you add the header to the domain, and then you submit it to the HSTS preload list, it will, it will keep your site encrypted always, and a browser will not be able to connect to it without using encryption, which keeps you safe from downgrade attacks.

So I've added it to my site, we've got a green up there now, we're up to D, and you can see on the bottom we have the, header is listed there.

So I've set that for two years.

We've included subdomains and preload, which I need to add it to the list.

Next up, frame options.

So this one, there are two options here, deny and same origin, and they define the behavior of your site within a frame.

So if you have a different site trying to embed your site within a frame, if you, this controls what happens.

So deny says your site can never be loaded in a frame, doesn't matter where it's coming from, it just will not be loaded in a frame.

Which is really helpful, unless, because most sites don't need to be loaded in frames.

And you often use frames for clickjacking attacks and other such malicious behaviours.

So if you don't need to load your site in a frame, set that to deny.

No one can frame it and no one can cause any sort of problems, any sort of malicious attacks there.

And same origin says only your site can load itself in a frame.

So if you have, you've got parts of your site loading in frames, you set same origin.

So you can still use your own frames, but nothing else can load you in a frame.

If you want to allow different sites to load you in a frame, you can do that for content security policy.

We'll get to that shortly.

Added that on there, still in a D, but now we've got both headers, we've got two down, four to go.

The next one, content type options, there is one option, it's just this, and this tells the browser don't try to figure out what the file is, just listen to the server.

And this solves the problem of a malicious upload, where if you upload a file and you tell the server, this is a JavaScript file or a CSS file, but it's actually an executable.

The browser, when it's, goes to download the file, if you don't have this header set, the browser will look at it and go, oh, that's an executable, I'll download it, which could introduce a virus into your computer.

Instead, when you set this header, the browser will see the service saying, this is a, stylesheet, or this is a JavaScript file, and the browser will try to load the file as a stylesheet or, as a JavaScript file, and it won't download it, and you won't get the, get anything malicious from that.

That one's really easy, that's only one option in piece of cake to enable.

I haven't seen a reason not to enable this, you really have no excuse not to have it on.

Three down, out to a C.

The next one, referrer policy.

Now, referrer policy controls the referrer information that's sent from your site, I'm sorry, from the browser when you're navigating around and you've got two behaviors.

First is when you are navigating on your own site and second is when you're going to a different site.

The clicking from one site to another site.

So this is the default value strict origin when cross origin It's the current default by browsers.

So if you don't set anything, this is what you'll get and it's a good safe default But it's a good idea to define even if you want this anyway, just in case the default changes, so you know what's happening and the behavior that's going on.

So strict origin when cross origin says that the full referrer, so the domain name, the path, and the query string will be sent on internal requests, so clicking around on your site, you'll have that full referrer.

But if you go to a different site, as long as it's encrypted, it will only send the domain name and the protocol.

It won't send the path or the query string at all, keeping those secure.

It won't be leaking any information there, or keys, or anything from the query string.

But it'll only go on encrypted requests.

If it's an unencrypted request to HTTP, it'll just drop the referrer.

It won't be included.

Because then it's, so it's not leaking any information on encrypted requests.

Next option, no referrer.

Says just don't send referrers anywhere.

None of the, no requests will send a referrer at all.

And I'm just going through some of the main ones here.

There are only a couple that you really need to care about.

No referrer says, don't send a referrer when you're downgrading, so going from encrypted to unencrypted.

Otherwise send the full referrer.

And this includes the path and the query string when you're going between different sites.

This one is useful if you have a public blog or a public site where you want the paths to be advertised.

And so if someone is clicking on blog posts on your site, going to a different site, the referrer will tell them what article they came from, which can be really helpful if, as I said, you have a blog or something, or a new site where you want to be advertising the origins of the requests.

So you can set that one for that one.

And the last one, I've noted my clicker works, is SameOrigin, which says that the full referrer is sent but only on internal clicking.

So anytime, when you're going around your application, it'll be sent.

If you're going anywhere else, it just won't send the referrer.

This is useful for, internal sites, or, like intranets, internal systems and things where you don't want to leak any information, where you don't want the domain name to be known.

And so you can just turn it off so any links and clicks that go from your application to anywhere else won't advertise where it came from, keeping it a bit quieter.

So that's Referrer Policy, pretty easy to enable.

Now we've got four down, we're up to a B.

And enabling those four would take probably less time than it took to explain all of it.

And you can do all of these through like your NGINX configuration or Apache or whatever.

Really easy to set up, you don't have to touch, do it in your application itself.

You can just do it at the web server level.

Permissions policy is a similar one.

In terms of configuring it, the way we want to configure it.

So permissions policy controls the features of the browser.

So it, for example, geolocation.

Here's a couple of examples of how you would do it.

So the top one there enables geolocation, allows it to work.

The middle one, geolocation can only work on those specific resources.

Bottom one is disabling geolocation and the microphone.

And so permissions policy allows you to define the different browser features that can and can't be used.

So the best place to get started here is this site permissions policy dot com has a list of all the standard features and then all the proposed ones as well.

It's quite overwhelming.

It takes a bit to your, to get through.

And you need to be careful enabling.

'cause sometimes it can break if you feel like browser extensions.

If you do screencast through a browser extension, permissions policy will stop that if you're disabling like the webcam or something.

So something to be aware of there, but this one's, if you don't need any of those fancy features or you just want to go through and enable like geolocation and microphone and some of those things that you were never going to use, then you can do that.

So use this site to generate your policy, and then it'll give you the list.

Then you can put that into your header.

And as you can see there, we're now up to an A.

And we can see the big permissions policy, I blocked everything from that page, down the bottom there.

But, you can just block whatever you need, and it's pretty easy to add on there as well.

If you don't need any of these features, then you can block them.

Now I've just got one left, which is the big scary one, Content Security Policy.

Wait, there's one thing before I get to that.

You'll often see on, security checklists and things, and older, All the compliance rules and such, they'll talk about the X-XSS protection header, and this was a feature that browsers attempted to use to stop cross that scripting.

However, cross that scripting depends on the context, and browser has no clue about the context.

So by default, sorry, the top one is the default.

It's off, so it turns off the filtering.

This one enables the filterings of what it does.

If the browser sees what it thinks is cross site scripting, it will attempt to get rid of it for you.

There's some foreboding there, I hope.

The last one says, if the browser sees what it thinks is code that's scripting, then block it.

If you do need to have this enabled for compliance reasons or anything else, use the last one make sure you block because the middle one filtering has a problem So if you're using this header and you're setting it to one so filtering and so you have code that looks like this.

You can see there We have a script tag with production mode equals true, and then if production mode is false then run some vulnerable debug code you say that does cross scripting or injection of stuff I don't know something vulnerable right.

Now if you make a request to this page that has that in the URL, that matches the script tag at the top.

If the browser is doing cross site script, has the filter enabled, it's going to get rid of that code block.

Which means, suddenly you've got a false debug mode is enabled and it runs vulnerable code.

And if that vulnerable code allows cross site scripting or some other injection from the query string, you now have a way to inject stuff into the page.

So the this header actually allows cross site scripting.

So get rid of it if you've got it If you need it for compliance reasons like some old outdated legacy compliance thing you've just got to deal with then turn it to block mode.

Make sure it just blocks the page because then it won't load the entire page at all rather than attempt to fix it and just make things worse.

So get rid of it if you can All right, now we're on to Content Security Policy.

Content Security Policy is like Permissions Policy, and it controls the resources that are allowed to be used on your page.

The top header there, that's the blocking policy, that's the main one, which says that when you define your policy, anything that doesn't, that isn't allowed through the policy is blocked.

It just won't work.

So if you've got JavaScript, third party JavaScript files or anything else loading or even inline scripts, it'll just block those.

The browser just won't run unless the policy allows it to work.

The bottom one allows you to define a policy that won't break anything, but allows you to receive reports.

And so you can be notified when there are problems like cross site scripting or weird new script includes or anything like that.

You can be notified of what's going on without it breaking anything, which is really helpful.

So here's an example of a policy on one of my sites.

The top line there is a reporting URL, so that's where it'll send the reports to.

And reportUri dot com is a fantastic service to set up with cross site, with security policies.

So check that out to get started on these things.

And as you can see, there are different types of resources that you can control.

We've got scripts and styles and images and connections and frames, forms at the bottom.

And you can control them through different methods.

We've got self unsafe eval for JavaScript.

When loading, we can allow cdn.

use-fathom dot com.

We've got some hashes and some nonces in there as well.

So there's a bunch of different ways that you can control resources to allow them to load.

Don't have time to go into any of it.

There's, but I could, you could do a whole talk on this greater policy.

But please come find me after if you want to have a chat, and I'll chat with you for hours about it.

This is, how you'd get started, like setting up a new policy on an existing site.

This is a report only header, so nothing will break.

What it is saying is nothing can run.

So the none there is preventing all the resources from running.

Then we have a reporting URI at the end.

So when you put that on a site and run it, you're going to see something like that in the browser console.

And as you can see at the start there, is that?

Yeah, it's huge, should be easily readable.

Alright, so you see at the start of each line says report only, so that's telling you that nothing is being blocked.

But these are all the things that are going into the policy, which is basically everything that is happening on the page, that isn't just the plain HTML.

As you can see, we've got style sheets and scripts in there, and there's some images in the middle.

And so that's giving us all the reports of all the things that are against the policy.

So then you can build your content security policy from these reports without your page breaking.

And also because you deploy it to your site, any user, anyone who goes to your site is going to get these reports.

It'll be hidden in the console, they won't see them, but allows you to do real world testing on there.

And then if you use the tool like reporturi dot com.

It lists them all in a table for you, you can go through and look at all the reports and you can see how many times they've been seen, what you need to do to build your policy, and it makes it really easy to get started with content security policy.

So that's just the basic reporting that you can view, so these are all just the report only notifications.

But you can also use the wizard, which has a different endpoint.

You point it to the wizard and then it'll help you build the policy for you.

So it's seeing all the reports coming in, and then it's suggesting the directives and the The values in there in order to build the policy.

So as I said to get started on that security policy check out reporturidot com And use the wizard to set it up on your sites for the easiest way to get up go about it So I've added that to the site now.

We just have a very basic policy at the bottom.

We're just allowing self so allowing its own resources and forms pointing to itself and ancestors, sorry, frames loading from itself and then it's going through an impulse policy.

So now we're up to A+ in a very short amount of time.

That really is as long as it takes.

The hardest bit there is the content security policy, but if you're getting started on the wizard or something, it doesn't take long to throw up the basic blocking policy in the report only header, and then you can use that to iterate and add that to your site.

So yeah, if you take anything away from this talk, securityheaders dot com, go there, type in your site address, and then go from there.

And the page gives you like helpful information as to how to fix up each of the headers as well.

But check out the MDM documentation for each of the different features, because it's a really good resource.

So yes, Content Security Policy is like a dragon.

Bit scary, but they kind of work.

All right, next thing related to security headers and related to security policies, sub resource integrity.

So these are the default tags you get when you go to add bootstrap to your site.

You'll notice these interesting ones here.

And that hash there, the integrity hash, tells the browser the file that is in the link or the script tag must match that hash.

If it doesn't match the hash, then it blocks it, it just won't run.

Which, and it means that the file has been modified, so the purpose of this is to prevent, your third party site from being compromised, and then malicious code being added onto the includes.

So if you think about it, if you look at the bottom one there, we've got cdn dot jsdelivr dot net, if that was hacked, and someone adds like a keylogger onto the end of the bootstrap dot bundle dot min dot js file, if you don't have the integrity hash, that bootlogger, that keylogger is going to be added to your site.

And this happened to the British government, I think it was, where they were using an accessibility helper on most of their sites, and the accessibility helper was hacked, and a keylogger was added onto that.

So why hack the British government when you can just act, when you can just attack a pokey little accessibility, start up over here?

And so their scripts were, compromised and then keyloggers were added.

And because the British government weren't using sub resource integrity on their scripting includes, the keylogger was now running on the British government websites.

If they had these integrity hashes, it would have just stopped working, and then the malicious code wouldn't have run.

If you, to, oops, where's it gone?

To add these onto different includes, if they don't give it to you automatically, there's a site sri hashdot org, you just paste the full URL, now you want the versioned URL though, because that won't change.

If, the thing you're trying to use doesn't give you a versioned URL, you need to get one, and usually you can just type the, the short URL into the browser, and then it'll redirect to the versioned version.

As you can see here, AlpineJS has a full versioned URL, and it's giving us the hash.

Then you can just dump that in, and it'll work.

And as long as that, and if that file changes, usually, it's a versioned file, so if it changes, something weird and malicious is going on, the browser will block it.

All right, we all know cookies, right?

There's a couple of useful things in cookies.

That you need to be aware of in case you're not.

First of all, the secure flag here.

This one tells the browser the cookie can only be used over HTTPS.

Enable it, there's no reason not to have this enabled, so enable it.

HTTPS everything, just enable it.

HTTP only is probably less useful at a JavaScript conference, but it tells the browser the cookie is sent to the server but can't be accessed by JavaScript.

Which is useful for, If you've got session cook, yeah, session cookies for like backend stuff, and you don't want the JavaScript to access it because if you cross that scripting or something running in the front end, if the cookie has this flag on it, the job, the cross, that scripting can't access the cookie and so it can't steal it.

So enable that one, on anything that you don't need the JavaScript to access, to keep it outta the JavaScript so that if there is a compromise somewhere, it can't be stolen.

And finally, same site lax.

And the same site lax, same site is part of, controls the behavior of the cookie when you're navigating around, going between different sites.

So lax is the same default, and it says that when you're making a request from another site to, your site, if it's a safe request, so a GET request or a HEAD request or an OPTIONS, I think it is, then the cookie will be included on those requests because those ones are considered safe and they're not supposed to make any changes.

So someone making a GET request site.

In the background or in a frame or anything else like that shouldn't have a security implication because it's just a GET request, nothing should change.

But a POST request, a PUT request, DELETE request, those things change stuff.

And so same site lax says if you're making a POST request from a different site, don't include the cookie.

And so cross, it's designed for stopping cross site request forgery attacks, where the malicious site over here is running in the background like a post request linking via JavaScript, or, I'm not sure if you're via frame, or like redirecting the whole page over to the victim's site.

And so we're sending lax in.

It'll stop the cookie from being included on those requests and prevent those attacks from occurring.

Strict says do not include the cookie on any cross site requests.

There's no real reason.

You use this if you have a really secure implementation.

You need the user to do something on your site before they can get your cookies to work.

I haven't seen many examples of strict in play, really.

The only one you need is lax most of the time.

But strict is there if you do need to have extra protection and stop the cookies from being included on anything.

None is there to say always include the cookies, as long as it's secure, because you need the secure flag as well.

So none, every request that goes to your site from another site will have the cookies.

And this is useful if you have, if you like have forms that need to be submitted from different sites.

I've seen it used quite a lot for that sort of implementation.

The problem with that is of course you're opening up the cross site request forgery attacks, and that's we need CSRF tokens and other protections to prevent those cross site requests from being malicious and causing problems.

So stick to lax, unless you need none, yeah, and if you need none, then you need the extra protections in place to protect against forged attacks.

All right, now, CORS.

I, it's a complicated topic, it's far too big to try and get into now, but the recommendations I have here is enable as little as possible.

So when you need to use CORS, and CORS is controlling, requests between different domains when your site is running on, when your site's working across multiple domains, or you've got, customer and clients and things doing different work between different sites, enable as little as possible, and yeah, so don't enable everything and don't widely open everything up to go I might need this, I might need this.

Instead, only do the bare minimum that you need, so that you don't accidentally open something too wide that you need, and CORS controls that, you control the different parts of it, like methods you allow, specific methods that allow work through cause and origin and credentials, includes cookies and things.

So yeah, it's CORS.

Dig deeper into it, MDN documentation.

Cross origin isolated is related to it, very similar acronym.

Again these kind of open , enable more complicated browser APIs and things, and they've been locked down for like memory reasons and such.

A lot more complicated stuff that makes my brain hurt, but again, the same principles apply.

Only enable the bare minimum of what you need, otherwise you might be opening things that you don't want, And this is stuff you only really need to get into when you're doing, complicated stuff across different domains.

In general, just leave it alone.

Same for CORS as well, unless you really need it, leave it alone.

Yeah, the problem with these CORS and all those other things is you can, yeah, you can hurt yourself if you're not careful.

Anyone know the movie, by the way?

I did this in, I've got one, yes!

Last time I did this talk I had one person in the audience who knew the movie.

It's an awesome movie.

All right.

Thank you very much.