Boosting security with HTTP headers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 163 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50012 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Control flowContent (media)LengthServer (computing)Data typeLink (knot theory)Meta elementClique-widthWeb pageScripting languageInverse elementScale (map)Maxima and minimaInformation securityEmailWeb browserInjektivitätDialectInflection pointInclusion mapView (database)Rule of inferenceSource codeoutputPointer (computer programming)Hill differential equationInformation securityInformationDependent and independent variablesWorkstation <Musikinstrument>Server (computing)Process (computing)LengthMultiplication sign2 (number)Web browserEmailSource codeComputing platformComputer fontElectronic mailing listAddress spaceTraffic reportingRevision controlGame controllerGoodness of fitVirtualizationWebsiteNumberInternet forumWeightIntelligent NetworkWeb pagePlug-in (computing)MetreDirection (geometry)Power (physics)Line (geometry)Classical physicsBitMereologyElectric generatorScripting languageContent (media)Set (mathematics)Frame problemMessage passingCompass (drafting)Standard deviationData storage deviceTerm (mathematics)System callCategory of beingDatabaseObject (grammar)Cartesian coordinate systemSingle-precision floating-point formatEndliche ModelltheorieFreewareLibrary (computing)Java appletRight angleContext awarenessControl flowPhysical systemMedical imagingInjektivitätTouchscreenQuicksortCodeWeb 2.0Group actionVideo gameHypermediaDifferent (Kate Ryan album)Annihilator (ring theory)Rule of inferenceVideoconferencingBoss CorporationLevel (video gaming)Exception handlingForcing (mathematics)Formal languageInsertion lossForm (programming)Open sourceDigital rights managementConfiguration spaceStructural loadVulnerability (computing)Client (computing)Application service providerWeb applicationDemo (music)Socket-SchnittstelleUniform resource locatorGraphical user interfaceSlide ruleMobile appParameter (computer programming)MultilaterationDefault (computer science)Hacker (term)Computer animationSource codeJSON
09:45
Chi-squared distributionSimulationInformation securitySource codePulse (signal processing)Content (media)Just-in-Time-CompilerScripting languageDefault (computer science)IntelHash functionConvex hullTraffic reportingExplosionSource codeElectronic mailing listDirection (geometry)Absolute valueMedical imagingDomain nameScripting languageServer (computing)1 (number)EmailNumbering schemeInformationBeat (acoustics)Hash functionCartesian coordinate systemDefault (computer science)Canadian Mathematical SocietyDemo (music)Digital rights managementWeb pageAddress spaceContent (media)Level (video gaming)Flash memoryWeb browserFrame problemMatching (graph theory)CASE <Informatik>NumberTerm (mathematics)Computer configurationTraffic reportingInjektivitätData storage devicePhysical systemControl flowForm (programming)Type theorySet (mathematics)Pointer (computer programming)BitAttribute grammarHypermediaWindowContext awarenessProbability density functionSlide ruleRight angleUltraviolet photoelectron spectroscopyPoint (geometry)CryptographyLine (geometry)Information securityDifferent (Kate Ryan album)Forcing (mathematics)Uniform resource locatorReading (process)Order (biology)Descriptive statisticsMetropolitan area networkPlastikkarteProcess (computing)Group actionComa BerenicesWebsiteReplication (computing)DivisorStatement (computer science)Multiplication signSpecial unitary groupMappingBasis <Mathematik>Source code
18:59
Scripting languageSheaf (mathematics)Structural loadMaxima and minimaComputer iconPrice indexView (database)QuantumInformation securityDefault (computer science)Content (media)Computer networkSource codeElement (mathematics)Demo (music)Execution unitCache (computing)EmailCorrelation and dependenceSineHash functionDirected setTouchscreenWindowSource codeRoutingVideo game consoleComputer clusterRevision controlMultiplication sign40 (number)CodeGoodness of fitBitLine (geometry)Information securityWeb browserLibrary (computing)NumberTraffic reportingShared memoryBit rateMereologyGame controllerForcing (mathematics)WebsiteCartesian coordinate systemReplication (computing)Default (computer science)Direction (geometry)Demo (music)View (database)Scripting languageService-oriented architectureProduct (business)Proof theoryVideo gameEmailWeb pageSoftware developerComputer fileDigital rights management2 (number)Link (knot theory)1 (number)Projective planeGroup actionAttribute grammarComputer animation
26:28
WebsiteSource codeMaxima and minimaComputer networkInformation securityScripting languageStructural loadContent (media)Directed setDefault (computer science)Demo (music)Level (video gaming)CurvatureHill differential equationIntelComputer iconElement (mathematics)Thomas KuhnVideo game consoleInverse elementFormal languageEmailSturm's theoremQuadrilateralLine (geometry)Direction (geometry)Scripting languageAttribute grammarBitState of matterGraphical user interfaceHoaxStatement (computer science)Web pageInformation securitySource codeCryptographyHydraulic jumpWebsiteClient (computing)Web 2.0RandomizationMultiplication signCartesian coordinate systemDemo (music)Type theoryClassical physicsHash functionDigital rights managementCross-site scriptingWeb browserGoodness of fitEmailPlug-in (computing)Flow separationRevision controlComputer animation
33:41
Operator (mathematics)WebsiteFrame problemWeb pagePoint (geometry)Web pageWebsiteBitOnline helpContent (media)Structural loadProcess (computing)Computer configurationInformationFrame problemProfil (magazine)Web browserSocial classEntire functionEmailSource codeJSON
36:14
Single sign-onCorrelation and dependenceDependent and independent variablesPopulation densityMereologyService-oriented architectureWebsiteDemo (music)RippingAddress spaceIntelWave packetPresentation of a groupInformation securityUsabilityMultiplication signPoint (geometry)Turbo-CodeWeb browserPhysical lawDependent and independent variablesTelebankingDomain nameComputer animationSource codeJSON
39:11
Convex hullMenu (computing)View (database)Landau theoryDemo (music)Transport Layer SecurityEmailWeb pageCache (computing)LengthContent (media)Sanitary sewerModemSurjective functionDrum memoryUniform resource locatorWebsiteRoutingTrailObject (grammar)BitRevision controlInsertion lossFigurate numberInternetworkingTouch typingWeb pageRow (database)Demo (music)Connected spaceGroup actionAttribute grammarComputer clusterWebsiteMathematicsInformation securityTransport Layer SecurityHydraulic jumpPatch (Unix)Address spaceRule of inferenceComputer animation
43:55
Information securitySingle sign-onInterior (topology)19 (number)Hill differential equationElectronic mailing listDomain nameGroup actionGraphical user interfaceNumberAddress spaceWebsiteBoss CorporationEmailType theoryInformation securityStress (mechanics)Software testingPublic key certificateDensity of states2 (number)Computer configurationCodecDirection (geometry)Token ringDemo (music)Exception handlingWeb browserError messageSource codeJSON
46:18
Execution unitWechselseitige InformationInformation securityInformationConfiguration spaceCompilation albumSheaf (mathematics)Modul <Datentyp>EmailTransport Layer SecurityDuality (mathematics)Dependent and independent variablesHTTP cookieComputer networkChainTwin primeView (database)Content (media)Programmable read-only memorySurjective functionHost Identity ProtocolProcess (computing)BuildingRule of inferenceInternetworkingFluxElectronic mailing listFigurate numberInformation securitySoftware testingQuicksortWeb browserWebsiteConnected spaceSmoothing2 (number)Dependent and independent variablesWeb 2.0Loop (music)Heat transferDemosceneBookmark (World Wide Web)SoftwareRevision controlAddress spaceGroup actionMultiplication signSoftware developerProduct (business)EmailConfiguration spaceComputer animation
49:49
Web browserRule of inferenceAreaNormed vector spaceKey (cryptography)EmpennageFlagContent (media)Web browserPublic key certificateGoogolEmailWebsitePublic-key cryptographyAuthorizationBackupPersonal identification numberComputer virusDemo (music)Graphical user interfaceDefault (computer science)Electronic mailing listError messageInternetworkingMereologyHydraulic jumpBoss CorporationComputer-assisted translationVideo gameCASE <Informatik>Software developerWeb 2.040 (number)Software testingRight angleForcing (mathematics)Source codeJSON
53:02
MathematicsEmailTransport Layer SecurityWeb applicationFigurate numberCellular automatonDependent and independent variablesConnected spacePublic key certificateHydraulic jumpCartesian coordinate systemSoftwarePublic-key cryptographyEmailPersonal identification numberMobile appMetropolitan area networkMiddlewareComputer animation
56:06
Server (computing)Error messageCodeWeb pageChainServer (computing)Public key certificatePersonal identification numberElectronic mailing listAuthorizationComputer clusterForcing (mathematics)Computer animation
57:01
EmailCartesian coordinate systemMultiplication signLibrary (computing)Source codeElectronic mailing listFormal languageInformation securityAxiom of choiceMetreWebsiteCycle (graph theory)Hacker (term)Operator (mathematics)InformationWeb 2.0Public-key cryptographySet (mathematics)BlogMatching (graph theory)Configuration spaceWeb browserDemo (music)Middleware
Transcript: English(auto-generated)
00:00
It tells which server I'm running, which is IIS. It tells what time it is on the server, and it also tells the browser the content length. With this information, the browser can do something useful with the response. In this header section, we will be adding security headers, which will tell the browser to do security stuff, and that's the whole clue.
00:26
So we'll just close this and jump back in here. OK, we're still on the screen. So why do we want to use security headers? This is the only way to opt into modern security features in the browser.
00:46
We are totally dependent on the browser to keep our users secure. Some things are enabled by default, some things are not. To not break existing applications and stuff, we have to actually enable these features
01:02
from the server side. The security headers we'll be talking about today will mitigate well-known attacks. So that's a good reason, of course, to use it. The hackers out there know about this. Now you know about it, and of course we should disable the opportunity to exploit these vulnerabilities.
01:28
They are quite easy to use. There are libraries for a bunch of languages and platforms that can help you set these headers in your web application. And WebSec, which is my open source library, is one for ASP.NET.
01:43
If you don't want to use the library, you can usually add it through config. So for example, in ASP.NET, you could do this in plain web config, if you'd like. Or you could usually just add a single line of code to add a header to the response, to the client.
02:01
And these are low cost. Not all security things are, but this is rather easy to fix. We'll be talking about CSP, content security policy. That can be a bit more challenging, and you might have to do some adjustments to your applications to get that running.
02:21
So we'll dive straight into content security policy. And this is by far the most complex header with the most movable parts. So I'll be giving a broad overview, so you just get an idea of all the things you can actually take control over with CSP.
02:41
But we'll narrow it down to a very simple example in the end, so you kind of get the gist of it. And then you can go home and play with CSP afterwards. So CSP was born to deal with injection attacks. And how many of you have heard about cross-site scripting?
03:02
Which is good. And that was kind of the initial term, because that was what the attackers started doing. But of course, it's not only script you can inject to a page. When you can inject HTML markup, you can inject an iframe or an object tag or whatever.
03:22
You can load the Java plug-ins and whatnot. So that's why we call it injection attacks. It covers a whole lot more. In general, there are three categories. You have the reflected attack, which means that I send something to your web application, and it will include it in the response and do something you didn't intend your application to do.
03:43
So this is the classic URL parameter problem. Also, you have the persistent injection attacks. If you have a discussion forum, and I can add a script or HTML or whatever to a message, and that would be stored in a database and then served up to users, that would be a persistent attack.
04:03
You would actually store the attack and serve it to all your users every time they viewed the topic. And then, with the single-page applications and the whole JavaScript movement, you have DOM-based injection attacks, which is a vulnerability that lives entirely in your single-page application.
04:23
So it would never touch the server. We're not going to demo this because we have enough demos for the headers. But this is the problem that Content Security Policy aims to solve. So, Content Security Policy lets you declare a policy for your response,
04:47
and telling the browser what it should allow to load in your web page. So you can control everything that you load and whitelist the origins, and also you can put restrictions on the script's execution.
05:04
The headers are Content Security Policy, which is the top one, and that will enforce the policy. So things will actually break for the attacker, hopefully not for you. And then there's the other version, which is Report Only. So it will do everything, but it won't break your page.
05:23
It will only send reports back to your server to notify you. And Content Security Policy has been supported for quite a while in the browsers. If you look at the version numbers there, Opera 29, Chrome 25, Firefox 31, and so on.
05:40
So this has been around for a couple of years in the initial version. Support is actually on the way in Edge. So when we get the new browser from Microsoft, they will also support Content Security Policy. And that kind of completes the major browser set, and we have good coverage.
06:02
There are two versions, or generations. The first one was CSP 1. This is supported by all the big browsers except IE. And recently we got CSP level 2, as it's called, where they add a bunch of stuff to version 1.
06:23
That's partially supported. Chrome and Opera is good. Firefox is not quite there. And of course, IE is not there at all. But we'll go through what was in the initial version and the next version.
06:41
So CSP policy is made up of a bunch of directives, and each directive has one or more sources. That's how they explain it in the standard. And that's what we should be calling it when we talk about it. So if you see the example header here, it says Content Security Policy colon.
07:05
And there's a directive 1 with two sources, a semicolon, and there's a directive 2 with a source. So that's how we chain everything together. So now we'll have a look at the directives that were specified in CSP 1.
07:23
And that's a bunch. So in your policy, you can specify a default source. This will be the fallback for all the other sources in the list. And we'll get to an example in just a minute. You have the script source directive, which declares a policy for scripts in your web page.
07:44
And a style source, which takes care of styles. And if you look at the list, we have object source, image source, media source, frame source, font source. You can map these fairly one-to-one to HTML tags. Object source takes care of plugins.
08:03
Where are you allowed to load plugin content from? Image source is images, media source is the video and audio tags in HTML5. Frame source controls where frames are allowed to load from. Fonts connect source is IAGs requests and web sockets and such.
08:22
And report URI is the directive where you can give it an address where it can actually post back reports when something breaks in your application. So this was CSP 1, and this gives you a fair amount of flexibility in locking down everything you load in your app.
08:44
And then along came CSP 2, so this adds to the previous list. So now we have a really long list. And this gives you the opportunity to put restrictions on base URI if you use that. They introduced child source, which applies to what they call nested browsing contexts.
09:08
But that means iframes and, for example, worker contexts. And this replaces the frame source from the previous slide. So they made a mistake and they thought about it again, and they came up with child source.
09:23
It was a more general and better solution. So frame source is now deprecated. They also added form action, which lets you whitelist where your forms are allowed to post. So the destination of your form content. And they introduced frame ancestors, and that is intended to replace x-frame options, which we will be talking about a bit later.
09:49
In short, this is all the addresses that are allowed to iframe your page. We have a demo, an example on that.
10:00
They added plugin types, and that means when you embed stuff in your page, loading PDFs or things like that, you can actually whitelist the media type for that. The sandbox directive was optional in one, and wasn't implemented by any browsers.
10:26
So that's why it wasn't in list. But this is now mandatory in CSP2. And this lets you set restrictions similar to what you get when you do an iframe with the sandbox attribute in HTML5.
10:46
And of course, the report URI, it was a bit cumbersome to always have to report back to a relative URI, which means you had to have a reporting endpoint to gather all these reports in your application.
11:02
Now you can specify an absolute URL, so you can have a separate application, and all your applications can report to the same source, which makes it much easier to manage. So, let's have a look at the sources.
11:22
Here I'm using the script source directive as an example. And what you see here are all valid headers. So you could set the content security policy header with script source none. And that means none. No scripts would actually run in your application.
11:44
You can set it to self, which means that it would be allowed to load scripts from the same origin, where you served the web page. So if I was running on nwebsite.com, I would be allowed to load scripts anywhere from nwebsite.com.
12:01
You have unsafe inline, and this is kind of poking a hole in the whole protection, because this will allow inline scripts to run, which kind of beats the purpose. But for some sites, you really need this. And this applies to the style source and the script source. So inline styles and inline scripts would be allowed with this source.
12:25
We have the unsafe eval, which is for script source only. But this would let you use the eval statement, and windowsat timeout, and a couple of others that are very dangerous to actually use. So stay away from that one, please.
12:44
So these were the kind of special sources. And also, you can specify URLs and such. If you give it a star, it will allow anything. You can also give it just a scheme. So if you say https colon, it will enforce that all scripts are loaded over https.
13:05
You can give it a wildcard domain. So star.nwebsite.com would allow scripts to load from any subdomain on nwebsite.com. And you can also give it an absolute URL, such as https www.nwebsite.com,
13:24
and it would load from there. So this applies to all the directives. It's the same. I've just used the script source as an example to give you a feeling of how this works. And then there are the special directives.
13:41
Sandbox has its own set of sources, and these map one-to-one to what you can use in the sandbox attributes in HTML5. So allow forms would allow forms in the document. Pointer lock would enable the pointer lock API to track most movements and stuff.
14:03
Allow popups is popups. Allow same origin means that it would enable it to access the DOM and stuff if you're serving your content from the same origin. Allow scripts, enable scripts. Allow top navigation lets you do frame busting, essentially.
14:23
You're allowed to find the topmost context and then change the window location. Plug-in types will only take media types, for example application PDF. So they are not using the sources we saw in the previous slide.
14:44
And we have to talk a little bit about the default source. And here's an example where we set the default source to self, and then we set script source to self and scripts.nwebsite.com. Of the long list of sources, we only included two of them.
15:05
That means the ones we didn't include, they will fall back to default source. So if you load an image, when loading the image, it will see there's no image directive here, so we'll use default source instead. So we'll see that in the demo shortly.
15:25
We have the script source, which means that it entirely replaces the default source. The script source is exactly what we've stated here. So this means that style sheets and images and Flash animations and Java applets, God forbid,
15:43
will be loaded as long as they come from the same address as the page was stored from. And the good thing is that this policy denies inline scripts and inline CSS, which takes care of a lot of the injection attack problems.
16:04
And it only gets better. Because in CSP2, they also introduced support for hashes and nonces. And this was actually quite a big thing, because a lot of people had existing applications with a lot of inline scripts.
16:24
And with the wiggling room you got from CSP1, you had to run it with unsafe inline, because your application would break otherwise. So they had to come up with a solution to let you safely run your own inline scripts, and then hopefully be able to stop injected scripts from an attacker.
16:44
And I have two options to enable that. We have the nonce, which is a good old term from the crypto world. It means number once. But this is a unique value generated to be used only once.
17:03
And you can use these to write these inline scripts and styles. So how it works, it's included in the header, and it's included in this HTML on the script type, and the browser will check that these two match. So we'll see how it works in a second.
17:23
And then we have the hashes. And here you can actually hash your entire script, and then include that hash in the header. And when the browser is reading the scripts, it will calculate the hash, and it will see if it matches one of the hashes in the header.
17:42
If it does, then you're okay. The typical use case for this is that you have stuff in a CMS system somewhere, and you're pulling it from there. It contains HTML fragments and scripts and stuff. So what you would do, you would hash the scripts and store that with your fragments,
18:01
and include the hash in the header, and then you can safely include the fragment in your HTML. We'll be using the nonsense for the demo. And then we have the reporting. You can specify a report URI, so when things go wrong,
18:21
the browser will actually post back information saying that this directive was violated, and it was on this line, blah, blah, blah. Now it can be a relative or an absolute URI, and you'll get the reports as JSON back to the server. And of course, the report-only header will just give you the reports.
18:42
It won't break anything, but this is a great way to start using CSP. Do it in report-only mode, and have a look at the reports as they come in. So that brings us to the demo. And I hope that everything will be crystal clear.
19:05
So I just lost the screen again. Is this a Windows 8 feature? I think it's PowerPoint. There we go. Okay.
19:26
And I've decided to do the demo with Opera, because no one ever does any demos with Opera. So, what do we have here?
19:42
I'll show you the view. I've built a very small demo application. It's up on GitHub, so I have the link in the slide, so if anyone wants to play around with it, you can find it there after the talk.
20:01
And here is our view for the CSP page. So this is a very tiny demo application, but it's riddled with inline scripts, and we are totally dependent on these scripts for our application to work. But still, we really want to use CSP in here.
20:24
So what I've done, there are two paragraphs here, one saying that the first inline script was blocked, and one saying that the second inline script was blocked. And why do they say that? Because, if you look down here,
20:40
we have two inline scripts which replaces the text in those paragraphs. So if the scripts are run, they will change the text and tell us that we ran. We're okay. So that's it. Nothing too advanced.
21:01
So, if you go to the CSP page... Oh, so long ago it actually fell asleep. There we go. And let's make this a little bit bigger, so you can see it okay now.
21:20
So, we see that both the scripts ran. And now we want to enable CSP. And of course, we have to demo the most brutal version first. This is the MVC attributes from nWebSec.
21:48
So they let you just decorate your action methods and controllers, and they will apply the header, so you don't have to mangle this into your own code. If you have a look here...
22:02
Come on. Oh, come on. There we go. So the CSP attribute will enable the content security policy header, and the default source attribute will enable the default source directive for the CSP header. And it says this is version one directive.
22:25
So, just build it. Refresh. And, of course, we need the developer tools. There we go. And the console.
22:46
There we are, on the CSP page. So it doesn't look that good now. And that's because CSP prevented anything from running here, and it also prevented the browser from loading the stylesheets.
23:04
So we lost everything. And, if we have a look here, we get a bunch of violation reports in the console. These would have been reported back to the application if we were using a report URI.
23:26
And if you look at the first one here, this is the fallback. It says that the CSS file violated the directive default source none. And it says, note that stylesource wasn't specified,
23:42
so it's using default source to decide if it wants to load it. So there we are. We totally broke our app, which is usually what you do the first time when you enable CSP. So, we have to try something else.
24:01
So, if we instead enable the default source, setting the self to true, we'll see if it gets any better.
24:22
And now it looks a bit better. Now it actually loaded the stylesheets and stuff, which is good. I'll just quickly show you the header, too. Of course, that's the... Here we go. If you look here, you see that the website now added a header here,
24:47
content security policy, setting the default source to self. So that's proof that the header is in action. So, if you look at the warnings here,
25:01
we see that it didn't like the inline styles. And this is a gift from Modernizr. And I was actually planning on complaining to someone about this, and then I realized that I actually had a comment in the template saying that, play around with Modernizr, but when you're ready for the production,
25:22
go to the website and create your own library with just the stuff that you need. And that was actually what we've been doing in the projects I've been part of. We've been creating our own version of Modernizr with only the features that we use. So that's the solution. Modernizr, out of the box, will give you CSP warnings.
25:44
So, for the sake of demo, let's do the unspeakable thing and just get rid of those. And we do that by setting the style source with the self source and the unsafe inline source, which should take care of the Modernizr problem.
26:06
And we build it, and we load it, and we should get rid of the Modernizr warnings.
26:20
Now, the interesting thing here is that now we are left with inline scripts, the ones we need for our application to function. And if you look down here, it complains about the inline script,
26:41
and it says that you either have to use the unsafe inline keyword, or you need to specify a hash. And it actually gives you the hash of the script, so you don't have to figure that out yourself. Or you need a nonce to allow inline execution.
27:00
So the browser is actually quite helpful now. So, what we'll do is what a lot of people have done. We'll give up for now, because we are still now on CSP 1, and we will also enable unsafe inline for scripts.
27:26
There we go. And there we are. Now both the scripts were run, and we kind of just poked two big holes in the content security policy.
27:41
And this is what CSP 1 gives you. And this is kind of something we need to know, because when edge is coming, they will be supporting CSP 1. That's the only official statement they've made. So, how can we solve this?
28:02
And then they have the trick with the nonces. I'm just checking my notes really quickly here. Yes, we are now faking a cross-site scripting attack.
28:23
And we'll show how we, with CSP 2, are able to let our own scripts run, but not the attacker's script. So, I'll just jump in here and do the classic cross-site scripting demo,
28:43
which is a pop-up from JavaScript, really. And we'll see that both our scripts ran, and also we got the pop-up saying that I was owned at NDC. That was the attacker's script.
29:04
Now, this is where CSP 2 comes to the rescue, because what we'll do now is we'll use one of the HTML helpers from nWebSec. There we go.
29:24
And this will generate the attribute with a unique value in our script tag. It will be 120-bit random nonce from the crypto RNG, and nWebSec will also add it to the header. So, it will give you the attribute for the HTML,
29:42
and it will also include it in the header. So, we're just going to add that guy quickly to the second script, which is ours. And for obvious reasons, we are not adding it to the attacker's script.
30:01
So, there we go. And there we are. No pop-up. And both our scripts were run, which is good, which is what we hoped for. And we see that we have a warning here on the last inline script,
30:24
which was the attacker's. Now, I'll quickly just show you what this looks like.
30:41
Okay, we need to flip this over here so we can see them both. There we go. So, if you have a look at the header here,
31:02
you will see the nonce is included with the magic value. And we will also see in the HTML that the nonce is included in an attribute there. So, as long as the magic value is in the attribute and in the header, we're good.
31:21
The good thing about this is that we are now running with unsafe inline, which means that we are still running in csp1 clients. They don't know what the nonce is, so they just ignore it. So, we are running in the old clients, but in the new clients, they see, oh, there's a nonce. That overrides the unsafe inline, so I will only run scripts including the nonce.
31:44
So, this gives us an upgrade path, if you like to call it that. So, this is how you add csp to an existing application with a bunch of inline JavaScript. And you can take full advantage of content security policy.
32:06
So, that's good. So, the nonces and hashes are supported in Chrome and Opera, and also Firefox. And EA has really put enough for them to support security headers,
32:23
so I assume they will be adding support in some upcoming version. They need to keep up with the rest of the guys. And then, really quick, we'll go to Firefox.
32:43
And just show you, I have a separate web page using all the new directives from csp2. And here you can see that Firefox doesn't know about child source,
33:02
plugin types, or sandbox. So, they haven't implemented complete support for csp2 yet. They are working on it, so it's upcoming. But it's a good thing to know. Okay, so that concludes the csp demo.
33:32
And this is taking a lot more time than I was really hoping for. So, there we are. I'll speed up just a little bit.
33:47
So, iframe attacks. The most famous one is click-checking, where people will iframe your web page and fool the user into clicking stuff in your web page.
34:01
In short, you are the vulnerable site, and there is an evil site out there. The evil site has lured the user onto their site, so that's where the user is. And they have a big shiny button saying click me. What they do is that they take your site in an iframe,
34:22
and they place it over their own button. And then they do a couple of CSS tricks to make it transparent. That means when the user clicks on the button, click me, the user is not clicking on that button, he is actually clicking on your button. And that could be a problem.
34:41
Delete my profile. Transfer all my money. So, that's click-checking in short. There have been a couple of other interesting frame attacks. Frame sniffing was one of them, where you could actually load a web page in an iframe, and you could actually extract information from it
35:00
by sniffing how it scrolled the content. This was an attack on SharePoint. This was fixed in browsers later. But the X-Frame options will take care of pretty much all these attacks, the entire class of attacks.
35:20
So X-Frame options gives you two options here. One is to deny the same origin, and there are some browsers that have a token called allow-from. This is not fully supported, so that's why it's in parenthesis. This tells the browser to not display the page in a frame. And when it's not displayed, there is nothing to click,
35:41
which is a good thing. It takes care of the attack. And this has wide browser support. It's been supported for many, many years. So always send the header, unless you intend to be iframed. If you don't want to be an iframe, send the header. It takes care of all these attacks. Just a note, in MVC 5, they are actually emitting this header
36:03
if you use the anti-forgery helper. So you might get two. If you're using in WebSec and MVC 5, you might get two. There has been some complaints there. So, let's skip to the next juicy part.
36:27
HTTPS is tripping, which is a really fun attack. I assume everyone is running their site over HTTPS, because we should, no matter what. Law firms, newspapers, everyone is moving to HTTPS.
36:43
In the upcoming HTTP2 support, all the major browsers have decided that they will not support HTTP2 unless it's over HTTPS. So, this train is coming. So, we all have to enable HTTPS on our sites.
37:03
So, to give a very short explanation, secure sites tend to use SSL or TLS for the users, your online bank for example, but for usability reasons. When people just enter the domain name in their browser, and press enter, it will make an HTTP request.
37:23
The site gets that request and does a redirect to the secure HTTPS address. And this is where SSL is tripping Play Support. It's a middle-person attack where you can actually hinder the user from actually switching to HTTPS.
37:43
And this was demoed at Black Hat back in 2009. So, this is an old attack. We've known about this for quite some time. And this is how it usually works. You enter www online bank and press enter. This will be HTTP.
38:01
The online bank will say, okay, I want to talk to you over HTTPS. So, you get a redirect. And then you're good. Then you have the green bar in your browser. It's all fine. Except, in this case, if you are between the user and the site,
38:22
the user will make the request. It comes to you. And this is unprotected. You could change that and use HTTPS when you forward a request to the site. The site would be happy. And you can just deliver the response back
38:41
to the user in clear text. So, no redirect. User never notices. You have to look in the address bar and see that it's not encrypted. And so it goes. From that point on, you are talking to the middle person in clear text.
39:01
And the middle person is talking to your bank over HTTPS, which is nice. And we have a demo. So, I lost you again.
39:27
There we go. So, we can close this. Now we'll have a look down here.
39:42
Here we have two actions where we can do the TLS demo. So what it does, it will tell us this is the request object and this will tell us if it is a secure connection. So the framework, if you're using HTTPS,
40:01
will set this to true. So we bring that in. And we also have one that requires HTTPS. And here we are using the require HTTPS MVC attribute. And this will actually detect that it's not a secure connection and it will do the redirect automatically for you. So, this is what people typically use
40:21
to take care of the clear text problem. Just add this attribute and it will always redirect you to HTTPS. This is built-in in MVC. This attribute. So, if you do this, and I'll do this demo in Internet Explorer
40:43
because last Patch Tuesday they finally added support for this three or four years after everyone else. But now it's in IE. So now I can do a demo in IE. Not many people do that here. So, if we go to our TLS page, this one does not have the require HTTPS attribute
41:02
so it is set to false. And it also tells me that the secure connection is not secure. And we're on HTTP. That's fine. If we go to the one with the MVC attribute, we see that it will actually redirect us to HTTPS.
41:21
And it will tell us that the connection is now secure. If we have a look in Fiddler, we will see that this is really small, isn't it? There we go. This is the attribute working. It's giving us a redirect to HTTPS.
41:42
And what happens next is, you can see here, Fiddler is now out of the loop. The middle person is gone. I can't see it. All I can see is that there is now an encrypted tunnel to the site,
42:01
which is nice. This is how it should work. Middle person is gone. So, with a bit of Fiddler magic, we can easily do an SSL stripping attack. I'll just change my rule here now.
42:21
What this will do is to check if the host name is ndc-demo-nwebsite.com. It will take the clear text request and it will make an HTTPS request behind the curtains. So Fiddler is an excellent middle person attack tool.
42:41
There we go. So, if we go back to the HTTP version, and I'll just put Fiddler over on the side here, so we can keep track of the request in the background. So now, it's not secure.
43:01
But, something changed. We are on HTTP, on the action method that doesn't require HTTPS. But, the site now claims that the connection is secure. And that's because Fiddler is making HTTPS requests
43:20
behind the curtains. Wrong button. There we go. And also, if we go to the address that requires HTTPS, we are still running over HTTP. So, I'm owned by Fiddler.
43:44
That's the short story. We'll jump back here and quickly talk about Remedy. There we go.
44:00
So, Strict Transfer Security is a security header that can help us solve this problem. This is one of the TOFU headers, which means Trust on First Use. You are dependent on the browser seeing this once, without anyone in the middle. But, once the browser has seen this header, then you're okay. And it has two tokens in it.
44:22
MaxH, which will give you the number of seconds the browser should be remembering this policy. And the token includes subdomains, which will make it apply the policy to all your subdomains, too. What this header does is that it instructs the browser to always communicate to HTTPS.
44:42
No matter what you type in your address bar, it will always be HTTPS. And that solves the problem. Also... Oh, sorry. If there are certificate errors and stuff, you will not get the warnings on the button you can say, I accept. It just fails,
45:00
without giving the user an option, because something is wrong. And this also has been supported for many, many years in all the big browsers, except IE, which added it this month. Also, recently, they added a preload directive,
45:21
which you see in the header there. And this lets you actually register your entire domain as an HDS domain. So the browser will then actually include you in a hardcoded list, embedded in a browser, and you will always be HTTPS. But you have to set this header.
45:41
The MaxH has to be 18 weeks. You must include the include subdomains token. And you must also include the preload token, because that shows that you have the intention to be pinned. And then you can submit your site at the address here. And this list is used by Opera,
46:01
and Chrome, Firefox, and IE. So this is a joint thing. So, let's jump right into the demo of how we avoid the SSL scripting attack.
46:26
So, what we'll do now is that we'll remove the middle person. Oh, sorry, sorry. I was so focused on what was happening here.
46:41
There we go. And we'll go to our web config. And we'll enable strict transport security through web config. This is, and web's like magic.
47:03
So, and that should be fine, really. If we bring up the developer tools here, and we have a look at network. Now we go to TLS. We see that the connection is not secure. Fidro is nowhere to be found.
47:24
Then we go to the require HTTPS address. We see that the connection is now secure, which is good. And then we have a look at the response headers. Oh, where did it go?
47:47
Yeah, there it is. And we can see that we now have the strict transport security header. So, the browser is now instructed to never talk to this site again over clear text
48:01
for the next year. That's how many seconds you have in a year. Also, we have include subdomains, and we have the preload token, which means that if we were running this in production, we could submit our site to the preload list. And it would be included in all the browsers, eventually.
48:21
So, if we re-enable Fiddler, now it's still running. Here, there's self-stripping. Let's move it over here. And if we go back to my bookmark, which is HTTP,
48:40
we can also try to remove the S and insist on being insecure. And what we see here is nothing. It's all HTTPS. So, Fidro is out of the loop. Even if I enter HTTP in the address bar,
49:01
I still provide it and still use HTTPS. Which is good. It's a good thing. So, that's how strict transport security works. And you really want to employ this if you're running your site over HTTPS. Really.
49:24
And we have the final header. Let's see. I'm just going to... I have been SSL stripping myself more than one time without knowing it. So, let's just disable the SSL stripping.
49:42
There we go. And we will move on to the final security header, which is public key pins. And this is all about limiting browser trusted certificate authorities.
50:01
In your browser, you have a long list of certificates that you trust. These are the certificate authorities. These are the guys issuing certificates for sites on the web. And it's a very long list, and that's the problem. So, if you get the search from any of these CAs for your site,
50:21
it will be valid in a browser. Which means that if one of these CAs are compromised, there are a lot of sites on the internet that can be attacked using that. A famous example is DG Notar, a couple of years back. They were hacked, and they were issued a search for Google
50:41
and Yahoo and Mozilla and a couple of others. Google detected this, actually, and all the browsers revoked the certificates, essentially putting them out of business. If your business is issuing certificates and nobody trusts them, then you're dead. Google has been pinning this in Chrome, hard-coded.
51:04
That's why they detected it. We don't have that luxury. Instead, we have a header that can help us do this. Public key pinning is also a TOEFL header, Trust on First Use. It includes some max age. In this case, it would be 50 minutes. And it also includes some magic values,
51:22
which is calculated over a certain part of the certificate. The details aren't that important, but this lets you identify a specific certificate that you expect the browser to see. And again, if something is wrong, it will just fail.
51:43
Chrome supports it. I assume Opera supports it. I haven't been able to test Opera. Firefox supports it, and for Edge, it's under consideration. A detail error. You can only pin certificates from public trust anchors, which means the CAs you buy certificates from.
52:02
Private trust anchors, your own certificates that you install, are not supported by default because they are used to check content and check for viruses and stuff. This can be overridden in Firefox, which enables internal testing, which is good.
52:22
A couple of considerations if you want to deploy this. You have to include two pins. You have a certificate that's live. That's fine. But you have to give it another pin because you have to have a backup certificate. If something goes wrong with your one certificate and you have to revoke it or you lose it or whatever,
52:41
then all your users are offline on your site because they don't find the certificate they expect. So that's why you have to give a backup pin. Of course, if you do this wrong, you shoot yourself in the foot. But we're used to that as developers, right? So, then we'll jump straight into the final demo.
53:12
And now you're seeing what I'm seeing. And now we'll let Fiddler be a bad, bad CA.
53:28
We will let it decrypt our connections. And just to make sure there are no dangling connections, we will reopen the apps.
53:44
Now, if we go here, we see that we are on SSL, running under my own certificates, which is good.
54:03
And let's start Fiddler. Now, Fiddler. Let's just close this. It caches stuff. Now, Fiddler is in the middle here.
54:25
There we go. Now we are actually seeing the responses from the web application. This is because Fiddler is now a man in the middle. If we have a look at this, we are now verified by Do Not Trust.
54:42
Not the same certificate, but this is a man in the middle with a valid certificate. So, we are still running HSTS. We are always HTTPS, but we're just talking to the wrong certificate. So that's a problem. So, we'll close Fiddler,
55:01
get rid of the middle person here, and we'll jump back into our application and we will enable the public key pinning header. This is the OWEN middleware from nWebSec, just to show that.
55:22
So, now we're pinning it for one day with the certificate that's the good one, not the Fiddler certificate. And we jump back into Firefox. Just let me restart it quickly.
55:47
There we go. Network. Get. We will see. In the response headers here,
56:01
we have the public key pin header with all the magic values, which is good. And now, the middle person is back
56:21
and it fails, with a beautiful warning saying that the server is using public key pinning and this was not one of the trusted certificates. So, now we're taking the list of, I think it was 80, certificate authorities and we've narrowed it down to one certificate that we trust,
56:42
which is really a good thing. So, that's public key pinning. So, I see I'm running out of time here. So, we'll just skip. No, you can take a minute or two.
57:05
There we go. So, just a quick note on WebSec. It lets you configure security headers throughout your application. You can do it through web config, you can do it through OWIN middleware and there are also MVC filter attributes
57:22
that let you override specific settings here and there. This means that you can set the global policy for your application and then do minor adjustments where needed. It will validate configuration. So, if you configure things, it doesn't make sense.
57:40
If you include none and self, for example, it doesn't match really good. And WebSec will help you with that and it will also make sure that the headers are set correctly. If you have a typo in one of these headers, then suddenly it's not working at all. It has to be exactly right. If you say public key pinning, pinning, it doesn't work. The browser doesn't know what to do with it.
58:03
Just a quick list, because this is a general security thing. You can do this in any app, anywhere. So find your language of choice in the list here and there's probably a library that can help you set these headers.
58:23
A few references. There are a couple more security headers. We didn't have time to look at those today, unfortunately. But I did a blog post about most of them back in 2012. So you can have a look there. Also, you'll find a WebSec security library on GitHub
58:42
and on NuGet. I've spent some time documenting it, so you'll find a lot of information there on how you get started. You will also find the application used for demo up on GitHub. So, go home and enable those headers and make the world a safer place.