 So We're going to talk about content security policies, which is I think a fascinating Approach to security, but of course it's also incredibly geeky and Nerdy, so I hope you guys find it interesting on some level I'll just tell you a little bit about myself was this working No, okay fingers it is Yeah, so I founded WordPress development agency based out of Jerusalem Israel and I did that for About 12 years and we worked with leading tech companies and universities nonprofits in Israel Wrote a blog that was widely read but stop blogging which I'm sad about I don't I mostly post on Facebook If anything or Twitter and no more long blog posts, but I see that pretty pretty well And a lot of the tips there were followed by people in the WordPress community I basically documented my WordPress discovery journey. I thought if people helped me That's how I learned right in the WordPress community from other people's posts I'm going to write what I learned and then hopefully that can help others so Yeah, so I wrote that for a while and organized work at five times in Israel Until they made a policy that you can be the lead organizer up to two times So I kind of surpassed that and it was actually really good timing because I really needed a break like organizing it five times Bit much someone else was supposed to take it over it didn't really happen So hopefully we've restarted the WordPress community meet-ups in Jerusalem We were having monthly meet-ups, which is great and hopefully we're going to do a word camp in 2019 So stay tuned if you want an opportunity or an excuse to come visit Israel and now and then oops and since then I founded a startup called static Serverless and static publishing for WordPress. I can tell you more about that and here are my other seven startups Yes, I have seven children Yeah, and they're the joys of my life. So anyways, that's about me. So What happens when you load a web page? What happens is that the browser? identifies what it should be loading into the browser and displaying and that can include a lot of assets that Aren't necessarily on the server with the website Some of them are some of them aren't some of them are loading from different domains, etc And what you will see is that if you look at the page source of a lot of websites This is a very prominent news site They will be loading assets from all different sources and you can see here, you know bounce exchange Adobe Amazon etc and Recent studies showed that on average websites are loading 42 scripts that are external at any given time So we're depending a lot on third-party services and third-party scripts in order to make our web pages functional and Over 50% of all page requests are third-party calls. So Without us really noticing We're adding more and more to our websites that we don't actually really have control over There's a big trust factor here, but it's just so easy. You just insert a JavaScript You know peace and you're good to go and you've got some new functionality or new tracking And and that's what we're all doing to our websites including the very large ones How do web apps get compromised? So first of all it can be on the server side, which is like SQL injections which target the entire website, right? And it will compromise the files or the database and That's seventy percent seventy six percent of total exploits are that kind of attack the other kind is on the client side and those are called cross site scripting attacks and Cross site scripting attacks are kind of the oldest Method of compromising a website. They've been around basically since the dawn of the internet And it's one of the most widespread you would think that if it's been around for so long It would be less of a threat, but that's not how the internet works necessarily There's constant efforts to try to mitigate it, but it still continues to be a very serious threat what it does is it allows an attacker to run a script in the user's browser and The browser can't tell the difference between a script that is authorized to run and a script that is malicious So this is what happens Browser allows all the assets including this terrible evil JavaScript and the browser accepts it and runs it and then it can do all sorts of terrible things to the site and because it's To the user actually and because it's accepted in the browser. It actually has the same permissions and access as the browser has so cookies web storage You know forms the DOM. It's all got the same permissions As as the site itself It's been in the OAS Top 10 forever. It's now in position seven And it's the second most prevalent issue It's found in two-thirds of all applications, you know At any given time huge amounts of websites have cross-site scripting vulnerability so with cross-site scripting the Unlike the server-based type of attack where it modifies something on the server or the database or the files Here the victim is actually the visitor of the website And here are just some of the things that can be done to a visitor to a website like this Session hijacking cookie theft account takeover redirecting traffic Stealing accounts credentials displaying unwanted ads virus and malware infections key logging Etc. So lots of fun stuff and these are things that we definitely want to be preventing so that our browser our visitors can safely browse our websites One example of a recent attack like this that used a third-party service to Infiltrate websites was a hack called the browse allowed so browse allowed is an add-on That a lot of British government websites added to their sites It's an accessibility add-on. It's text-to-speech. That's very useful and nice and good for a government for trying to make their sites more Accessible in Israel. That is not the case. So that's great but what happened was the sites are all loading this third-party script which they trusted and then the script was Modified by hackers and all of those sites instead of being text-to-speech Accessible became crypto miners. So, yeah and you're talking about How many sites was it? Let's see thousands thousands over 5,000 sites Got this vulnerability and we're mining cryptocurrency when visitors Using visitors CPU and resources when they were visiting these British government websites. So That's just one example Why is that bad? Okay crypto mining like whatever because it slows down the devices. It can take CPU to Higher levels if you're anything like me, you might have a lot of browser tabs open So you can't afford to have your CPUs anymore battery drain overheating You know puts a load on your on your device etc. So and of course a government should not be mining cryptocurrency We had that actually in the WordPress community. There was a Weather widget that was in the plug-in repository and the person who developed it didn't realize that the Resource that they were using to display the weather was also a crypto mining Yeah, thanks. So that's another example, but the very biggest most significant type of attack Is the Magikart one? It's very interesting and very widespread so basically Magikart Has been going on for the last three years. It took a really long time for anyone to realize that this was happening and It's a group that nobody really knows who they are and what they do is They identify third-party scripts or services that websites are using and then they hack those So at first when Magikart started out, they would actually hack direct the site directly But then they came up with this approach where they would identify a tool that was Maybe easier to Hack and then they would hack that and then they were able to apply their hack to the sites that had that script installed on it So these are just some examples And what they did was they became credit card skimmers so when people fill in the credit card form on any of these sites they were able to grab the credit card information and Of course use it for malicious purposes and They it's estimated that thousands I think thousands of sites have been affected by Magikart and It's really hard to track because they're very smart. They In they modify the script in a way that looks like it's meant to be there. It's so it's difficult to to identify it Okay, so that brings us to content security policies The idea behind content security policies is that Okay, so we're in this world of the web where we're all installing who knows what on our sites I'm guilty of that too. Just two days ago. I found a shiny new tracker thingy and I installed it on our site And then I was trying to Debug it. I was like, why isn't it working? And I was like, oh right because we have a content security policy That's not allowing me to be responsible. Good so what it does is basically you You whitelist sources that you have deemed to be trustworthy and okay to load on your site and Then anything that's not that will get blocked by the browser. So it's a it's a header that talks to the browser and The modern browsers Except for of course Microsoft Microsoft has partial support they all support the content security policy header and they will respect it and so It will load whatever you say that it can load when the viewer loads the web page and it will block anything else so Basically the way that it works is okay. I'm loading a web page and I've authorized Google fonts I've authorized Google analytics. I've authorized my own images and Then I have not authorized this other resource and the content security policy won't allow it to load and if these websites had had content security policies properly implemented Magikarp would not have been possible So in terms of browser support levels, there's a really useful site called can I use if you're ever wondering what is Supported in browsers in general and you can check out which browsers support content security policies and which version This is these are this is the support for content security policy level two But in October ish. Yeah, October level three was rolled out But Chrome and Firefox support it, you know Safari 2. I think of course Microsoft always lags behind So how does content security how do like how does the content security policy work? What do you have to do in order to create one and implement it on your site? So there's two parts to it. There's the directives, which are the type of assets that you want to Limit or control so you can tell by their names kind of what they are, you know fonts Frames like iFrames images media the media is like video and Objects objects are flash type of content Scripts, which is JavaScript styles, which are of course style CSS and then you say, okay Now for this font for the fonts I will only I only want the site to load a fonts from let's say my website or Not at all right like for the the object source a lot of content security policies will say none Because you don't want any iFrames loading those are those tend to be a pretty popular way to breach a site Self self is my own domain so anything that's sitting on let's say my my site comm Slash whatever then that's accepted Stars a wild card use that carefully And unsafe in line unsafe evil, which I'm going to talk about So this is The default content security policy so when you start out You could do Content security policy default source none, and that's a good way to actually try to identify Through the console and I'll show you how what assets are trying to be loaded and then you can say okay This I need to whitelist this I need to whitelist that Or you could start with self because it's probably the case that you do want to load assets from your own domain What this actually means the default source is it covers these directives and they and makes them all self Okay, it used to be that it didn't cover everything, but now I think it pretty much covers all of the directives So you've covered that and you said okay, those are all self and then you can tweak it further So you can say okay self for the script source But also I want Google Analytics to work So I need to authorize that with a by whitelisting it fonts same Object source like I mentioned probably best to do none unless for some reason iFrames are important You can also by the way tweak it so that on a per-page basis it will accept things So if you know you have an iFrame on one page you can have a different security header on that page doesn't have to be site-wide This is my favorite content security policy directive Basically what it does is if you Have a site and has mixed content right now that we all need to have HTTPS on our sites and it's very important You might end up having a site a legacy site or whatever a migration that didn't go 100% smoothly And it still has some assets that are HTTP like an image or who knows what? And then you won't have the padlock on that page, which is very sad So this instead of going and finding it all what you can do it Says load all assets is HTTPS even if they're HTTP. So it's like a one-step HTTPS for everything Directive and it's 100% effective. So it's it's great. So that gets big emoji from me Defaults oh right the reporting. Sorry. Okay, so what's really useful about the content security policy is that there's an understanding that websites are dynamic they change we add things we remove things and It's really hard to keep track of it, especially the site gets larger So there's a reporting capability where you can have this directive and it will collect information about violations of your content security policy now violations don't necessarily mean that someone's trying to hack you it might mean You know you now have a YouTube video Embedded in your site and you haven't authorized that you haven't whitelisted it and so it's violating the content security policy And then you can whitelist it and then your YouTube video will now appear on your site So and then what it does is it collects the data and sends it as a JSON to the URL that you define So here it could be CSP reports or something like that If you start to do research about content security policies online The problem is that there's not a lot of information out there and some of its outdated, you know, they've been around since 2012 they're not widely used and people aren't really familiar with it and The documentation well, there's the standard documentation from the w3c, but that documentation is never ever legible I don't know if you ever tried to read the documentation, but it's the worst you just go in circles and like they use English I don't know who's writing it, but Google has some really good documentation, but even their documentation is not updated to CSP level 3 in some places so what you might find is some mentions of these directives and Is that six hours? Okay CSP directives that look like this the X ones and They are no longer supported supported, but you might see Document like tutorials or whatever they'll say use it don't use it Okay But the irony is that even after you've whitelisted everything all of us are going to have inline Scripts Google Analytics is a perfect example despite the fact that Google is a huge advocate of CSPs and The bottom line of CSPs is that your assets need to be an external file and not inline Google Analytics and other Google tools are in line and In order to enable that to work you need to use something called Unsafe inline and unsafe eval just the names are like who you're doing terrible things to your site I'm allowing my site to be unsafe, but in order for Google Analytics to actually work You need to add this these directives of unsafe inline In order for the script to be accepted by the browser and once you add that then inline script injections are possible and Despite all our hard work on the CSPs our sites are still vulnerable I gave this talk first version of it at work camp Europe and I and we you know We implemented this for ourselves and for our clients and this really bothered me I was like so what are we supposed to do? We're all supposed to take our inline assets and and you know make them external That's a huge job and we'll take a huge amount of debugging and and the internet's actually like the way it is We just this does not build that way. That's a crazy expectation. So other people thought that obviously This is what the directive looks like if you want to have unsafe inline and unsafe eval so one way to get around this is to create a nonce for every script and But it has to be randomly generated on every page load. It's not so simple but you have one and then it's applied to all the scripts that you authorize to load and That can protect you from the inline script because any inline script won't have that randomly generated nods. It's unguessable And yeah, so so that's one solution that but that came up But there's a challenge with that which is caching right you can't really cash a page in that case because You have to change it every time Hashes is another thing that you can do which is you create a hash of the script the inline script that you want to authorize So That is it's that way if it it's changed in any way then the hash no longer matches the script And then it won't be accepted by the browser But the problem with that is that if you're using a third-party script Then they're it's ass right so they're generally updating it and so then the hash if they make one update your Your scripts gonna stop working And sub resource integrity is A way also to say this is a script and it's like this is like a kind of a stamp on it and you know But also it it's problematic in terms of maintaining it so researchers at Google identified this and they took a look at the content security policies that were implemented on like 1.6 million websites and they found that 94 percent of them are bypassable because of the Issue of the inline script So they came up with this directive called script dynamic Which on the one hand is not the simplest things implement But on the other hand it means that it reduces the challenges in a number of ways. So basically I'll just explain how it works You do the nonce and they have documentation explaining how to do it Random site generator let random number generators, etc Inline event handlers is the most challenging thing here Because they need to be refactored and on every page load right generally to do not so they're recommending the the nonce approach Despite the issue with caching. They don't address that but basically what this approach does is it takes everything that I just told you about which was CSPs until like a few months ago and says Okay, we don't all have to try to figure out what we need to whitelist because that's really challenging to keep on top of it It means consistently analyzing your pages And knowing what you've added and adding it to the CSP and doing that properly And then there's the inline script issue. So no more of that. You create this kind of like one policy Called strict dynamic and that applies to everything always It's kind of like a one-step Solution to the CSP craziness And this is like an example of how it looks. So you do the script source nonce and then some random number That will be the non-set-up peers. That's like appended to every script on your site that you're okay with Strict dynamic report sample, whatever unsafe in line The reason unsafe in line is there is for browsers that don't yet support level three of CSP So then it will be implemented and then you go back to having at least a CSP with unsafe in line But it's better than nothing object source none etc. So That's their new like recommendation about how to implement CSPs So there's the challenging part of doing the random number, but on the other hand, like I said, it's instead of Consistently trying to maintain an update You just add a random number to all the scripts that you are okay with and from that point on You're good to go like it's just it's much easier as someone who's been maintaining CSP for for us and others This is much easier Google has a few tools This is like a cool tool that allows you to see what your browser supports So it's the strict dynamic test bed and if when you load it in your browser if you see These squares then it means that it supports that level the strict dynamic Okay, so how do you add it to your site? So there's HTTP headers right so you do it on the server level. That's the ideal way to do it You can actually do it in your functions of PHP file that will work too and you can also do it with a meta tag So the meta tag can be useful if you need to do like per page tweaking It can make it easier But the meta tag doesn't support some directives most of them it doesn't support I can't remember which ones but like the most important ones that supports. Oh here frame ancestors report your eye or stand box You can do an HT access Yeah, but the most recommended way of doing it is as a as an HTTP header that's deployed to the pages on your site Some tools that can make your life easier the console In the browser That is your friend So if you're ever trying to figure out why something's not working or whatever go in there and it will First of all, you can see the content security policy in the console. There's It's under network, right? Yes, and you can see the whole set up there of your site and any other site And and also it will help you debug because it will show you very bright red errors if it's trying to if something's trying to violate the CSP This is another tool for checking your HTTP response headers This is a Google tool What it does is it identifies parts of your application which are not compatible with CSP because that's like the hardest part figuring out what needs extra Loving care and helps make necessary changes before you deploy your CSP The CSP evaluator is a very simple tool from Google. Just plug in a URL and it will say You don't have a CSP or you do have a CSP and if you do it will give you some recommendations This is like the best and easiest to use tool It was created by Scott Helm. I think he's a big security guy Very interesting to read his his work So you just plug in a URL and then you get a report. So this is actually the White House They get a big ol red F So I'm showing that to you just because a ha ha and B You can feel better about your own site because if you have anything better than an F You're doing better than the White House There's some WordPress plugins that will help you manage your CSPs So it will help you Create the meta tags and there's some other tools that are useful in terms of managing them Some of them haven't been updated for so long. So I don't necessarily recommend using it But it's an easy way to get started and maybe just start testing it out This is another one I'll put this online and all of these link to the resources and stuff all these images This is an amazing tool the report to URI so they have like a wizard for creating your CSP And you just you say okay I want this to be self and this to be this asset and this to be that asset and then it gives you something They could just plug in to your site and that's really useful The reason why it's recommended to still have a white list is because of the browser compatibility issues So that way, you know, if it doesn't do the strict dynamic then you've got the white list This is a great tool, but sadly it only runs on Windows It also it will analyze the page and tell you it like give you like an output of all the the assets there that you might want to White list for your CSP in terms of adoption. So this is from February and the top million websites Only 23,000 have content security policy in it. So you can see that adoption is really low I mean there's more by now, but It's it's not growing very quickly, but as front-end client-side threats and threats like the Magikarp become more prevalent People are going to start implementing it more and also with the new approach from the researchers at Google with a strict dynamic I think it will make it something that's also much more possible for people to implement So this is a little example of what happens when a site doesn't have a content security policy I injected something on the front end. I Did not hack their site. It was just on my end, but this is just I Would not be here actually I would have been stopped at the border. They let me through but it's just an example of Like how if you if you don't have a content security policy you can actually inject whatever you want into a site and Let's see if this will have sound. Oh Is that anyways? What happens is I inject the script and it plays the Harlem shake remember Harlem shake and Then it makes the whole web page dance. It's very entertaining. Well, you'll have to trust me on that That's something I can't really do a demo for so but anyways. Yeah, so that's just an example of how a lack of CSP enables you to inject What could potentially be much more malicious? On a site so the White House should implement a CSP. I mean At least on that from that point of view And I think that was my last slide so, yeah CSP is for the win. They're crazy, but they make a difference and They're increasingly important and we're going to see more and more threats on that level Just one thing that I didn't mention is that it's not it doesn't prevent the cross-site scripting what it is It's called defense in depth. It's like another layer So what it is is if your site is breached because cross-site scripting is so difficult to identify and control you've got this extra level and And then it will protect your users and then like protect your brand Protect yourself from being sued for credentials being stolen etc. Etc. So Yeah, I think this is kind of part of the future of where the internet's going and it's very interesting and It's worth keeping eye on it and I hope that was helpful to you And if anyone wants to see the video later, I'm happy to show you the White House through the Harlem Shake. So thank you We've got a couple minutes for questions. So Does the content security policy actually prevent the types of problems that you were talking about with the You know a script a script that's being loaded from a third-party changing without my knowledge Right. Yeah. So If the script is changing in order for them to inject into your site, they would have to know what the nonces And they can't because if it's set up properly, it's randomly generated It should be long enough and complex enough and etc. But You know, it's unguessable. So so it prevents that and if they try to inject anything That's for something that exists and if it doesn't exist yet on your site Then also there's no nonce there that matches the header. So nothing. I can't they can't do anything so the nonce is generated in the head and In the HTML So that's like in my opinion the next thing that has to be tackled because we want to be caching things Right and to have to like generate a new page load on every visit. It's resource-intensive slow, etc It's like that's not where we want to go But I imagine that there's going to be fixes for that because the internet isn't place of caching today You can't you can't work that way, but in the meantime, that's that's how it is. Yeah Any other question? Yeah How important is this for the average, you know users website versus a larger organization that's probably taking data from people? so like everything with regards to security after Do the pros and cons like is it worth it for me to invest the time? How big is the threat? It's possible that on small websites It's not so critical, but as it gets easier to do it's kind of like HTTPS right like how critical is HTTPS for a small website? it's critical and You know, we should be making every effort to protect our users also so Yeah, it's like it's a pain, but it's definitely worth keeping in mind and I do think will become easier to implement because It has to it has to be something that we all can basically implement as easily as possible And that's generally how things go so Yeah, it's like you have to do the cost-benefit analysis for yourself anyone who's doing transactions of any kind or even Capturing user information in some way through form probably should be doing that Thanks, Mary. I'm great talk. I wanted to ask and build on the other person's question who asked about if the script changes without your knowledge Maybe not so concerning if it's like Google Analytics and you probably trust the code They're pushing on to your site, but if you've got third-party scripts from developers that maybe you know They, you know, stop developing the project and or they somehow get into malicious hands Is there anything that content security policies can do to help with that? Or is there anything that you would recommend to be able to know if that's happening? Well, if you've implemented the content security policy and the script gets into malicious hands Then they can't do what they want to do because again comes back to the nonce and not being there And so any changes that they make won't be accepted by the browser. So the functionality will stop working all together But that's better than you know malicious activity. So yeah Hi, good morning. Thank you for your talk My interest is is with Apache or n Gen X. How is that implemented at the server level if you could speak about that a little bit? So that's like You probably need web developers to do that It's different for each one and it's how you would manage your HTTP headers. So it's it's It's on the server level. It's not like something that can be easily explained right here Thank you for the information. So when you're writing your rule set for this I saw you had like seven different Images videos, whatever Do you have to write a new rule for each content that you want to protect or can you combine it all into a single rule? And if you have to write multiple is that resource intensive at all to the users browser? so There's two sides to it. There's the one side which is If you don't if you have a content security policy and let's say it says Self then like a YouTube video won't work So if you want functionality to work on your site, then you have to create a directive for it and That's that's from that point of view of just enabling functionality to even work if you do a content security policy, that's too broad and Allows everything then you might as well not have one, you know I'm not sure if that answers your questions, but like it's like if you have one you need to author whitelist Assets if you want them to work And then the bad stuff won't work because it's not authorized I'm not sure if I'm answering your question. Oh So it depends on your use case like and also how much you want to protect it like let's say object source Which is flash and stuff you should probably just put in None just to you know be safe And it depends how much you care like let's say the fonts you could say only let's say Google fonts If that's what you're loading or you could just leave it and then theoretically it could load a malicious font But you know is that gonna happen? I don't know You don't have to define them all and that default source if you do default source self Then that covers everything more or less in terms of saying anything coming from my domain is okay But then again if you add something that's not from your domain and you want it to work then you're gonna have to Tweak the related the relevant directive for that. Thank you for the talk The plug-in that you mentioned does it have does that add the nonsense that you were talking about no So that doesn't exist yet in an easy way Yeah, unfortunately It's also relatively new and these are kind of old and not so well maintained the plug-ins Isn't that lead there will be a hacker day on Sunday if anyone wants to try adding it in Any other questions Hands-high please Okay, thank you, Mary you pleasure. Thank you