 All right, hello everybody. Thank you for being here. Thank you for Joining my talk some of the people I already know from yesterday Remkas, is it right? Perfect Okay, and yeah, thank you to what came for giving me the chance here to talk about one of my topics and Yeah, let's see what I got for you today so the talk is called content security policy one-on-one and I want to show you with this talk what content security policy is What you can do with it and how it could be of use for one of your projects and WordPress project as well Come in no problem We have enough seats Okay, but before we start maybe some first information about myself My name is Christopher I'm a developer here from Vienna I Do mostly PHP and Lara stuff so PHP software development and in the last two years I have done a lot of projects with chatbots so that's also something that I do a lot lately and From time to time I do talks like today at meetups and at conferences I bought the things that I do and you can find me on Twitter My name is crystal from from my handler there So check it out and they also have a blog where you can Find a lot of blog posts about these topics and other stuff Before we go into the talk I also want to mention one of my latest project, which is a e-book that I'm writing right now It's called bit chatbots with PHP So if you're a PHP developer and I guess most of you are and if you're interested in chatbots Please check it out. There's also a free chapter available already and Always happy for feedback The website is called build chatbots with PHP.com and you also find the link and some blog articles about it on my personal blog Okay, but back to the topic so content security policy is obviously something about security and I guess we can all agree on that that Security is really hard. There are so many things we need to take care of and Yeah, it's it's a little bit mind-blowing. We have to take care of plugins input handling updates brute force attacks storing credentials cross-site request forgery SQL injection nonsense SSL certificates and so on and this is only a bunch of things that came into my mind when I did this Light so there are much more of them and you can easily see that Security topic especially in web application. It's really big and it's really overwhelming so You probably also know of some of the famous leaks happened in the last year like big one at adobe PlayStation network or cloud flare and there are many many more of them and when you think about this Maybe this question comes to your mind So how can we protect our sides when even the big companies can't because they got the money they got the people They got the power, but they can't secure a side. So how can we do this? So you then might think okay, maybe my side my word for side is not as interesting as the one from adobe or from PlayStation network But maybe at some point your side will be interesting to some hackers and if you don't Take care of that. Yeah, you're kind of doomed. So I think we all still should consider Security and the only thing that we can do is Go step-by-step and take security seriously Checking out new stuff learn from mistakes that you did I'm sure every one of you has in some way done some security mistakes And you need to learn from them and do them next time better and this is the only way we can handle this overvaluant Topic just by going step-by-step so What is content security policy? The Mozilla web documentation says Content security policy is an added layer of security that helps to detect and mitigate certain types of attacks Including cross-site scripting and data injection So okay, so it's a kind of security layer But if we try to take a simple way of explaining it, we can say CSP content security policy lets you define trusted resources for your website So it's a kind of whitelisting what your website is allowed to load in terms of scripts Stiles images and so on and with whitelisting the resources that we allow on our side We are also saying all the other resources. We don't want to be loaded and this is where the browser blocks them and you Don't run into occasions where scripts get loaded that you don't want to be So how does this look like you can add CSP with a content security policy header in your side You got a header name Which you see on the left and you got a header value Which you can see on the right and on the right we define the policies the rules for the resources that we want to define So a first example would look something like this here on the right We have the string our policies we separate them with salami columns and each of this policy Defines something for a certain type of data So with this policies we need to Take in mind there are directives These are the things on the left So is it a data sources the types like the first one is we're talking about images the second one We're talking about scripts and on the right We then define the sources that are allowed to be loaded for this Directives for these types And if you want to translate that we can say it the first policy means Images are allowed to be loaded from anywhere any resources. That's was that that's what the asterix means and the second example means Image are allowed to be loaded only from the current sites origin So which starts with the same domain and if you have your scripts or styles or images from the same Domain loaded, then that's okay, but anything else from other resources like other domains will get blocked So we've seen these two directives so far, but of course they are much more that we can use There are one for styles for fonts for media objects for form action as well and form Yeah, let's say all kind of types that you will encounter when you build your websites and The same goes for sources. We don't can use just these two You can also define Concrete domains or regions that we allow and also use the asterix for subdomains But we can also use the num keyword which says we don't want any resources to be loaded for Let's say images or scripts or something else So when you take a look at some examples from real sites, this is from my blog where I integrated this You have this header and you have the big long string that Contains your policies and you can also already see that even for my simple small blog Which is not that big there are a lot of things I need to allow in order to make it work And this is due to things like Google analytics or a Facebook SDK that I use at some point and It quite easily gets very long and messy But it's a good way to tell the browser what resources I want to allow on my side Here's also another example from Facebook. Yeah, looks kind of similar so mainly we've talked now about Sources that come from other services from other domains But we also have to handle inline things like inline scripts or inline styles And this is what gets a little bit tricky because how do you know if they weren't ejected by Any attack because of cross-site scripting people try to attack your site to include some scripts or styles to your site And when another user then loads the site the browser sees the scripts and styles and it comes from your Sides and the browser is okay. It's okay. I will execute the script. I will allow these styles And this is something where it gets tricky because you don't know if they are well it or not So this is where we have nonsense and hashes with content security policies So here's what we don't want to do. There is a keyboard for Directives that says we can Unsafe inline scripts or style so when you have this in your header the browser will let you Use any inline scripts or styles that the website has included And we don't want to do that because this is exactly why we want to use CSP To avoid this stuff to a lot of scripts and styles that we don't want it to our side So what we can do now is use nonsense as one example We define for directive and nonce Which is just a random string similar to WordPress nonces and you then can also use this nonce for Inline scripts and styles where you can say, okay, here's the nonce. Here's the keyword when the browser gets the site It will check if the nonce from the header from the CSP header is the same with the one in the script tag or in the style tag and What you need to make sure is that with every refresh of the page that you get a different nonce because if not It wouldn't be useful anymore So this is one approach that we can use for inland styles and scripts another one is hashes and This works quite Yeah, a little bit differently Because what you can do is you can use the content of a script or a style Hash it it also gets them base encoded and you get like this hash that you can set inside your header and In this header you also define which method you did use for the hashing. So in this case, it's Shah 20 256 that I've used to hash the script So when the browser then loads the site again, it sees this hash It also sees okay There is an inland script and he will try to hash the script And if the hash is the same like in the header, then he will allow this one If it's not the same, he will block it and the resource will not get loaded Yeah Yeah Sorry What the difference is Speed I Can't tell you that sorry We can look it up later Together and we see if there's a difference. I haven't come across any resource that said that there's a special difference, but it's a good question Okay, now about browser support because yes It's sometimes a pain So with content security policy, we have three versions of it right now The third one is the next one. It's not yet implemented It's a working draft by the W3C so we can get rid of this for now Everything that I've shown you today is from the level 2 CSP and yeah, all major and Current browser support it. So that's quite good except the Internet Explorer, of course, but it has its own X content security policy header, which is also deprecated But you can use it if you want to do some CSP stuff for Internet Explorer as well the only thing where It could lead into a problem are these browsers right now because they only support CSP level one and When if you and your side uses CSP level two then nonsense and hashes are not included in CSP level one So they will get ignored. So this could lead to a problem where you say, okay, the script I am for me. It's okay. I have a nonce. So I will allow it but Internet Explorer or other I'm sorry the edge Explorer version 12 other browsers Don't know what the hash is so it will ignore this and it would lead to that This resource gets blocked on your side and maybe your side don't work anymore So you need to make sure what browsers do you want to support and how to build fallbacks to don't Let this case to happen Since we are at the WordPress conference, we probably should talk about WordPress as well. So How we can integrate this into a WordPress site? So there are these three options right now and yeah, let's take a look at each of them You can of course use server configuration to add a each to the P header to your side This is not WordPress specific and it's like the highest level where it can add a header And you can set it like this for Apache in the HD access file Or you can also do it like this for your engine X server inside your server block So you need to define the whole string here So as you can see that this will get quite big and long if you have multiple resources you want to allow What you also can do is you can add the header inside your theme files So there's one use case where you might think this could be useful This is when you have different themes with different Resources you load and you want to define the security header on a theme level So this is the only thing that I came to my man was that okay? This could be useful there because normally I guess we want to separate those Configurations from your theme and we don't want to include them there, but it's possible And the third and probably best option is create your own plugin where you add the header Maybe you have a plug-in just for security headers. There are more securities headers out there like the content security policy I won't cover them. So this could be useful or you use a plugin that's already given and I found this one WP content security plugin which I tried and tested and it works quite well and It adds some configurations to your WordPress backend where you can define some general option for CSP header and You can also add for each directive the resources that gets loaded. So This solves a little bit the messy problem because you can define for every directive here Which of the resources I want to allow? So in this case, I have some stuff for Google Analytics and Yeah, I also have the unsafe inline in this example, but this is what we don't want actually So this is a good way if you want to start with CSP and want to try it out But with WordPress there are a few things you need to be aware of because CSP and WordPress. Yeah, let's say they're not the best friends The problem is even with WordPress the core and the themes that comes with WordPress you get a lot of insan Inside styles and scripts which are tricky to handle For for example, there's the emoji detection support script that gets ultimately adds to your header and Yeah, you can just add a nonster very easily So what you can do is you can do a hash But then there are also inland styles for let's say if you're locked in to your side And you have the admin bar then WordPress will add some inland styles there as well and you need to take care of that and It gets even more complicated when you think about themes and plugins because many of them put a lot of styles inside your markup and this will make it much more difficult to use CSP So the best approach here is to write your own themes Write your own plugins because there you can define how it is set up You can put every style and scripts inside external files That's always a better approach because it's also better for the browser To cache and so I would recommend that and Yeah, just need to be you just need to be aware of that. It's quite complicated to start with some WordPress stuff But it's definitely possible So here's what I would recommend We will go through each steps of them Now there is another header which is called content security policy report only It works very similar to the other one, but it only will tell the browser what violations will be triggered But the browser won't stop loading this files So you can use this and any of your life sites You will see the errors in the browser in the console bar But all resources are still being loaded and it's not active So it's like a debug mode for a CSP and it's perfect for testing So definitely start with this try to define your policy with this header This is also something you can set inside the plug-in settings and then you go step-by-step to work here through Before you use the real header Just waiting for the picture Then what I also would recommend is using the default directive So every directive that you haven't set Like this one we haven't set any directives for images or scripts only the default one We lead into this default directive. So if we say default itself We only allow scripts and styles from the same origin Then this will work for every directive now that's possible And you can also use a default with other Directives together so to have the fallback for this one The only thing you need to be aware of is when you start using another directive like the image one It won't use any of the policies inside the default directive So just make sure when you start using a directive like images or scripts that every every policy you want to make do it inside there and It will not be triggered the default ones. So that's that's a common mistake that I also ran into Yeah, and then you can start with error-driven development. So This is what I did for one of my sites. I started with a policy In report mode, I added the default source to self so only styles from the same origin are allowed And it led to this 53 hours that I got and yeah It was quite interesting because you see a lot of stuff that you didn't know your side needs So even when you use Google Analytics, it's not just one script that they load There are different Origin that you need to add to make it work and also Facebook SDK needs some styles to add I don't know why but they do and it all lets up to these 53 errors and you then need to go through every one of them go step by step See what is loaded. Is it okay? Is it not? Can I use normal directive? Can I use a normal policy do we need a nonce or maybe a hash and Yeah, it takes some quite some time But you get to know your side a little bit better and at the end it will be worth it and And there's also not a great feature with Level two of CSP, which is called the report UI directive So what happens here is you can say whenever there's a violation to the CSP header It should sense this information to a domain that you define and What it will send is this Jason Jason object, which tells you okay This is the UI where the violation happened What was the blocked UI the violation directive and the original policy and This is really important when you start using CSP because there will be edge cases And you want to know about these errors because if you don't see them Yeah, you can do anything about them and there are services like report ui.com where you can get the URL that you can put in in the header so that you can put in here and This site can list you all the files that get collected But also the plugin that I showed has also an option to show all these errors so make sure that you use this send report stuff to Yeah, to lock what's happening on your side and if there are any errors So we've seen that already Okay, that's Already most of it from my talk. So a quick summary check out usp try to use it get yourself familiar with it It's a great way to just start putting more security to your side Don't try to allow inland scripts. There are certain cases where it's Where it's not possible and where you need to allow it, but If you can don't do it because yeah, it will add more security leak to your side Start in report only mode so you can test your side No errors just the the locks that tell us what went wrong and yeah start learning about Your side and your dependencies and I'm pretty sure when you use his pu will be quite surprised what sources are being loaded and Yeah, it's it's good to know your side If you got want to know more about it there are a few blog posts I did on this topic And you can find on my blog and there are some official documents that I also have here I will also share the slides later so you can check them out and Yeah, this was it from my side. Thank you very much Yeah Anything Okay, let's say and the attacker has injected some script on your side and it's an inland script Oh, sorry The question was what is the whole concept because if someone has already put in some scripts into your side Then it could also change the header and why would it be secure them? So from my point of view, I don't think that it's possible to change the header before the browser Loads the side and checks what is allowed and what not so I don't think it's possible to afterward and change the header So if Yeah It brings you that the inland script is not that doesn't work if it's not allowed So if you say you don't allow inland scripts, then the script won't get executed by a browser Yeah, I guess it depends here on the kind of manipulation But if there's only one script that's included into your side and you can prevent that from being Executed then and already helps you But if the attack is like yeah a bigger one where the user has access to more than just Including the script and it gets of course more difficult and then maybe this doesn't help anymore Yeah, yeah for common Cross-site scripting attacks where you can add any kind of JavaScript through forms or other stuff into your site and other data Injection where scripts get to your page that you don't want them to do of course if you if the user has access to the server or something else Then yeah, this won't help you anymore But good question, thanks Any more questions Okay, I'm here the whole day if you Got questions later. I want to talk about other stuff of my work. Just find me around and yeah, thank you very much for your intention