 It's very exciting for me to be here, it's my third time speaking at WordCamp Europe. It's one of the highlights of my year coming, it's really fun, so I hope you guys are enjoying. I'm glad I got you before lunch, so you're not in the post-lunch coma state, because we're going to be talking about something that you'll either find really interesting, I find it interesting, or really boring and you'll take the opportunity to have a good nap, which is fine, I'll try not to disturb you. So a little bit about me, so I'm from Israel, as you mentioned, and did you guys watch Eurovision? I'm not your toy, you silly boy, I just had to put that in. I founded a web development agency about 12 years ago, we provide high-level business solutions using WordPress. Been writing a blog called WP Garage, we kind of stopped writing on it, which is a shame, I miss blogging, but people still tell me sometimes that they're looking for a tool or a solution to something related to WordPress, and they come across our tutorials that we've written there. Five-time WordCamp organizer, but then WordCamp Central implemented a new regulation where you can only delete organizer twice, and I had passed that by far, so yeah, looking forward to hopefully having another one there soon, and if it happens you guys should come. And more recently, the founder of Startup, related to WordPress, called Stratik, we are a static site publisher for WordPress and other CMSs, and by publishing in Stratik, we basically solve all issues related to performance, speed, and security. All right, oh right, and also, I can't forget that, I'm a mom to seven, so there's my loves of my life, my children. Each one of those is another startup. Anyways, so we're going to talk about content security policies today, but first let's just talk about how the average web page loads in your browser. So when you visit a web page, or your web page loads in someone's browser, it's accessing or calling different assets or resources of different types, and many of them will be resources that are on your server, on the same domain, and some of them will be third-party services, or a lot of them will be third-party services. Here's just an example from a very well-known large news site. These are some examples of the types of assets that it's calling when you load their home page, and they're not assets that they own, they're third-party assets from Bounce Exchange, Adobe, you know, things like that. How are web apps or websites compromised? So either it's on the server side, which is what I think us in the community are most familiar with. The vast majority of vulnerabilities and hacks happen on the server, and that's when our sites get defaced or just don't work anymore and things like that. The other way that sites get compromised is on the client side. So that's the user in the browser. And the most prevalent type of attack, both server side and client side, is cross-site scripting. And cross-site scripting is when a hacker or an attacker tries to inject their own script into your site, into your source code, and have it loaded in the browser. So yeah, so that's cross-site scripting. It either can originate on the server or it can originate on the client side. Once this attacker has this type of privilege or has gotten into that state in your page source and in the browser, it has the same privileges as your browser in general, which means it has access to your cookies, to your web storage, to your DOM, and that's not a very good situation to be in. There's three types of cross-site scripting attacks. Persistent, which means it's related to the server. It originates in the database. One example that used to be much more common, but has been basically stopped, is when someone leaves a comment and the comment has some kind of script in there that will then be loaded. The other is reflected, which it originates in the victim's request. So that means someone gets a URL in an email or whatever, and that URL has some parameters in it that load a script. So they think they're loading, they're clicking on an OK site, but they don't notice that the URL is not OK. And then there's DOM-based, which means that it has nothing to do with the server side. It has everything to do with what's happening on the client side. Cross-site scripting has been in the OASP top 10 threats since OASP started talking and having this list, this annual list of the threats. OASP is the open source collaborative security information and guidelines resource. It's very useful. So with cross-site scripting, even though sometimes it originates on the server, the victim is not your site. The goal isn't to deface your site or take it down. The goal is to attack your users, your visitors to your site, and get certain types of information from them. What they can get when they do a cross-site scripting attack is session hijacking, cookie theft, account takeover, redirecting traffic, stealing account credentials, right? They can see what people are typing in. So that's key logging, which I'm going to get to. Displaying unwanted ads, infections. It's not pretty. An example of this that happened relatively recently that was quite ride spread was the Browse Allowed attack. I don't know if you guys heard of it, but Browse Allowed is an accessibility extension that many sites run in order to make their sites more accessible. In particular, government websites, many sites in the UK and in Europe. They access this extension by adding a line of script to their page source. And what the attackers did was they got access to the library that these sites were calling or referring to, modified it, turned it into crypto mining. So everyone who visited these government sites, that script was now using that user's resources, their laptop, their electricity, their CPU, to mine for cryptocurrency. Mining for cryptocurrency isn't the worst thing that can happen to a user. It's annoying. But the fact that that was possible shows what potentially terrible things could happen when we're using it. So the Browse Allowed extension runs on like 5,000 sites and that's how many sites were affected. So in one go, they just made one change and it was across the board on 5,000 sites. In general, crypto jacking, thanks to the rise of Bitcoin and other cryptocurrencies and their rising prices, not so much anymore, it led to a lot of efforts by hackers to utilize or gain access to people's user resources in order to mine for cryptocurrency for their own gain. And that is called crypto jacking. A very popular one is called coin hive. And people use it for legitimate purposes. Well, kind of. So there's like one site called Ceylon. And because of ad blockers and the difficulty in monetizing sites, they, Ceylon said to their users, either pay us some kind of fee or we're going to have this coin hive running. So when you're reading our site, we're actually using your resources to mine for Bitcoin or I think it was Monero actually. And then, you know, that's how we monetize. But in many cases, it's not legitimate. Either the site owner is not telling the user that that's what's happening or the site owner themselves don't have any clue that their site has been infected and their site is now grabbing resources from all of their visitors. What happens when you have a crypto jacking attack, slower devices, it can use up to 100% of your CPU. I don't know about you guys, but I have way too many browser tabs open. I'm already like at 80%. All I need is some crypto jacking to happen and my computer will just fry itself. High energy consumption, battery drain and overheating. Crypto jacking has infected 55% of organizations in the world. That's the estimate. And it's increased 8,500% over the duration of 2017. That's what greed does. And in browser, crypto jacking increased 34,000% also over the course of 2017. So it's crazy. So how do we protect ourselves? Oh, it's just one example that affected the WordPress community actually is this plug-in. So this is a weather widget, which is pretty innocent. And, you know, all it does is help website users and users with a diverse range of applications. The plug-in's developer didn't realize that this, the source of the weather data they were using was, was implementing crypto mining in they're i-frame. So anyone who was using their service was crypto jacking their users. And so this plug-in was actually removed from the WordPress repository. So how do ourselves, in particular, our website visitors from these types of third-party attacks, we think we control our web pages, and yet we don't because we're relying on a lot of other resources and other parties to generate our web pages. So what content security policies do is they whitelist resources. It allows you, the site owner, to whitelist the resources that you want the browser to load for your web page. So rather than trying to guess what the bad stuff is, you just say, this is the good stuff and this is what I want to load. It's been in existence for like, I think, two years, and I'm going to tell you how to use it. Very few people are using it. So this is just like an example of what happened. So here's a web page and it has content security policy in its header. It told the browser, and the browser knows, okay, Google Fonts is okay to load, Google Analytics is okay to load, and that image is okay, but here's an evil JavaScript. The content security policy knows that that's not included in the whitelist and doesn't allow it to load at all. It can't even get going. In terms of browser support levels, so content security policies in the beginning and even maybe until a year ago did not have widespread browser support. So that meant that you could only protect your users if they were using certain browsers. The thing is that even if your visitors are using a browser that's not supported, there's nothing negative about that. It just will ignore it. So it's not like there's a detrimental effect here in browsers that are supported, then the content security policy will go into action. So how is the content security policy built? It has two parts to it. One is the directives. So basically, you have a list of types of assets that you can refer to. So font source is fonts, right? Frame source has to do with iframes. Images, images. So you're saying these images or these fonts, this is what I want you to do or not do with them, and then there's the source expressions. So we say font source, and then we can give it certain parameters. So we can say font source only from this website. Or in the case of, let's say, frames, you may say frame source, none. There should be no iframes loading in my site, even from my own server, because your server could be compromised, and you just know that there will never be iframes that you want to be loaded on your site. Iframes are sometimes used for click-jacking attacks. Iframes means my website URL is mysite.com. So any assets coming from mysite.com slash whatever, that is okay. Star is everything. And unsafe inline and unsafe eval are two ways that the content security policy allows us to continue to have bad behavior, and I'll explain what I mean. So the point of content security policies is that we separate structure from behavior. So I don't know how long you guys have been in the world of web development, but when I started, we built our pages using tables, and our styles were in line, which is bad practice, and obviously we developed to put the styles separate, right? We separated style from the structure. But we still, many of us, and it's very common. We still put behavioral things like JavaScript in line in our page source, and that is actually not great practice. When you have inline JavaScript, that is a great weakness with regards to cross-site script attacks. So with a CSP, ideally, you will have all of these types of assets externally in an external file, and you will whitelist them. But if, like many of us, your site has been built with inline styles or inline scripts, you can create a content security policy that says, I'm allowing it. So that still means that you have a kind of weakness and a vulnerability there, but it's better than not having any content security policy at all. So this is just, I'm going to give you some examples of the format. So this is the basic content security policy directive. And what it's saying is, even if I don't specify for each of those other directives, like fonts, images, whatever, where specifically I'm allowing it to come from, the default will be self, let's say, and let's say HTTPS. You can say, I only allow my site to load assets via HTTPS, okay? So you can add other parameters here, and it doesn't have to be this way, but once you've set that, then you don't have to set every other single directive. Here's an example of script source. So this is saying, scripts like JavaScript can load from self, so from my domain, or Google Analytics, right? We all, even though Google is a big backer of content security policies, their own analytics script, we all embedded straight in the page source. So we're saying, that's okay, that can load on my page. Font source, also, let's say I'm using Google Fonts, so I say the fonts can load from my own server, from my own domain, and Google Fonts are okay too. We can say never, like in objects, we can say we never wanted to load. And now I'm just gonna tell you a little bit about unsafe inline and unsafe eval. So as I mentioned, so eval is bad news in general, and inline styles and scripts also, but we can authorize them. We can say to the browser, it's okay, but there are some ways to add, even though we're like removing the security of our site by enabling it, we can add some other ways of securing it, specifically on the scripts that we want to load. So this is how that content security policy would look, if we're saying script source is okay. It's like they use phrasing here that doesn't let you think anything other than that you are being unsafe, right? You're saying, browser, I want you to load these unsafe things. It's a very clear message, but what can we do? That's just the internet is a crazy place, and we've built our pages in certain ways, so one way that you can secure those inline scripts is by adding a nonce. And that would be something that regenerates on every page load, and it's very complex. And the other way to do it is with a hash. So you create a hash of the script. And then if it changes in any way, it won't load. Now this, now all of those content security policy things were defensive and they're like not fun. It's creating content security policies actually not so easy, because you have to make sure that you are not allowing the bad stuff, but you are allowing the stuff that you need for your site to function. You'll have to, you end up doing a lot of testing, the font's not working, where is it, I have a YouTube iframe, now it's not working. I have to authorize that. So, but this is a great one that's easy to add. And I think it's very useful, and it makes me happy. And it's the upgrade and secure request. So as we all know, all of our sites should be running on HTTPS and SSL, right? And I'm assuming we've all migrated our sites to that, like good web developers. But doing that migration, it's pretty easy to miss something, to miss an asset of some kind that is being loaded on HTTP. It got lost in the rewrite or it's hard coded in the theme files or whatever. By adding this content security policy, it tells the browser, I don't care what the page source says, always load every single asset by HTTPS. And what that means is that you'll always have a green padlock, you will never have mixed content. That's a really nice and easy thing to add. As I said, creating content security policies is not so easy and it can break things. So what you can do is rather than implementing a content security policy and having it become active immediately, you can use the report only function, which will not deliver the content security policy and activate it for your users, but you can look in the developer console of your browser and see what is being blocked by the content security policy as if it was active and then modify accordingly. And it can send logs to a URL that you specify, it's in JSON format. SRI is something that adds another layer of security to this whole thing, but it's kind of complex. What it does is it says, here's a reference to a script and here's a hash of that script. Now, if that script, let's say jQuery, gets updated, then that hash is no longer relevant, do not load this resource. Now, that's not good in the case of something that you need and it's being automatically updated and they don't notify you, but the point is in the browser-allowed example, their script was modified if you had SRI enabled, then the hash would no longer match and the script would be clearly different to the browser and it wouldn't have loaded. If you read up on content security policies, you'll see a lot of references to the X types of policies. Those are deprecated, they're no longer relevant. There's different policies that have taken their place, so just FYI, because you'll come across a lot of content that refers to them. So how to add it? Server level as headers. You can add it in your functions. I think this is particularly, in my opinion, the header is the ideal way to do it, but a meta tag is really useful because we all can pretty easily add meta tags to our pages. It gives you more control per page. And yeah, it's just, yeah, it gives you more easy control. You can add a meta box to the back end of your site and just manage them from there. Just note that it doesn't support three of the directives, frame answers, report URI, or sandbox, but those aren't so common, so for most of your use cases, meta tag is fine, or HT access. Some tools to use to make your CSV journey a little bit easier, the browser console. If you go to the network tab after you've loaded a page, go to the top result, which is your, you know, www URL, and you can click through and you can see header information and it will tell you about your content security policy, what it says, et cetera. This is an easy tool for getting that information. You just plug in your URL and get the results. Google created its own tool, CSV evaluator. It's kind of funny, because what it will do is if you put in a URL and it has a CSV, so it'll show it to you, it'll tell you what it is. It does give you some feedback, which is useful, and if you don't, it just says no CSV, so that's the tool. This is a really useful tool created by a guy named Scott Helm, and you plug in your URL and it gives you this kind of report. Now this is an unhappy report, this is actually the White House. That's how many sites don't have content security policies, banks, the White House, you name it. They get a big old red F, but it gives you information on what you can improve, and if you have a current content security policy, it will analyze that as well. There are some WordPress plugins to help you more easily manage your security headers. So just here are a few security headers, WP content security plugin, HTTP headers, and this is for the SRI, which I managed to check if a script changes. This is an amazing site. It has a lot of tools related to CSPs that you can use that are really, really helpful. One of my favorites is this, CSP Generator. So it can be, I mean you can do it, but writing your own policies and making sure all the syntax is right and everything, whenever it's time consuming. So here you just plug it in, and then at the top you can see the green is the outputted content security policy and you've got your policy. Yay, really, really helpful. This is the only tool that I know of that will analyze a page and tell you what you need to whitelist. Unfortunately, it's because of the state of content security policies, there aren't that many tools, and this is the only one, and they have a Windows version, their Mac version is not fully fleshed out. But it's very useful because you put a URL in and it will say to you what you need to put in your content security policy. In terms of adoption across the web for content security policies, in February we were up to 2.4% of the top million sites. So you guys aren't using content security policies, you're definitely not alone. The point of using a content security policy is not to prevent cross-site scripting, it won't prevent it, but what it does do is if your site is compromised, which according to the top security experts, cross-site scripting is one of the most difficult types of attacks to prevent and then deal with, and even sometimes know about. When you have a content security policy in place, it's an added level of protection, so it will protect your user even if you've been compromised. To finish off, I wanna show you this. So another way to test, an entertaining way to test, if a site has a content security policy active, is the script that was created by this guy named Brenno de Winter, and you just can plug it into the console, and if the site does not have a content security policy, it will do this. Let's see if this works. There's no sound, can you hear it? It's Harlem Shake, remember Harlem Shake? And if you see at the top, the hamburger icon is dancing, so just, first of all, that music should not be playing, it wouldn't play with you. So it makes the whole site start dancing. Yeah, there's Trump dancing, and more dancing, and then, and the White House is dancing, as it should when the Harlem Shake is playing. So that's the kind of fun way to show people that they don't have a content security policy active. I think it's something that's worth knowing about. You can protect your users, you can give yourselves another level of protection. Here are some resources. I'll make the presentation available online. Mozilla has amazing resources, and Google, Scott Helm is like an expert and this other guy, Troy Hunt, yeah, I put him here as well, and yeah, let's all make the internet a better place with content security policies. Thank you. Fantastic. We have time for questions. If you have a question, if you're in the back, please stand up so we can actually see you. If you're down here, just raise your hand, and Miriam's gonna answer your questions. Please also make it questions, not stories or announcements, just questions. Hi, I have a story to tell. Just kidding. One thing that came to my mind is fault positives. What is your experience, and is it a daily basis, or are there any at all? Thank you. So because it's white listed, there aren't false positives, right? Like it's not like that bad thing can get through because only the good things can get through, but what you can end up having is that you're not authorizing things that you need to have. And so this type of reporting where the logs are being sent to the report URI, that can help you keep an eye on things and see if there's something that maybe you didn't authorize and so your page is breaking. You can also check in the console and see if you get these big red errors if something's trying to load and it's not allowed. So it is something that you kind of need to keep an eye on if you change your site quite frequently, but there is no false positive. At the worst, your font will look weird or the YouTube video on the iframe won't load. You know what I mean? I hope that answered your question. Thank you very much for bringing up CSPs. It's a very important topic. I think we are one of those using it for some time now. That's impressive. Thank you very much. Also impressive bringing it up to work in Europe. So no, I just wanted to share a thought about the GDPR context because I think many of us now have the issues having themes of plugins that are doing stuff we don't know about and being not compliant with GDPR. So we were considering using CSPs to prevent any external includes actually because it's quite easy to prevent anything being loaded from external server and thus solving, so from the short time perspective all the GDPR issues with external contents. What do you think about it? That's a really interesting application. I've been trying to like ignore GDPR. I be you. Like we like implemented it but like I left that to our lawyers because my head is spinning from it and I think it's not clear to almost anyone what exactly we're supposed to be doing but that's a really interesting approach that is very smart I think. I think it's quite radical but. It is quite radical but so is GDPR. In my opinion. Thank you. Yeah, thank you. That was a good story. Okay, that was the only story though. Can we have more questions? Anyone have more questions? Don't be shy. Yeah, right there. Hello. Good talk, thank you. I wanted to go back to earlier when you mentioned about unsafe in line and I went for a period about a month ago where I was going through a lot of these things and trying to update my own content security policy and going through a lot of pitfalls. So it's interesting to see what you've done but I also noticed that I also tried to remove unsafe in line and unsafe eval and although a lot of the code that I'd written was fine there was parts of WordPress that didn't necessarily like what I'd done. Sorry I'll stand up so people can see who I am. For example the thing that I noticed first was that Yoast SEO stopped working and when I dug further into that as well as that the media page stopped working and the media library did, it turns out that there's something in Backbone that compiles functions by creating a function, compiles templates by creating a function which gets blocked by those content security policies. Do you have anything you can recommend to mitigate or? Yeah, so you need to have the content security policy not be applied to the admin area which there's ways to do that and then the plugins will work because the output let's say of Yoast, right? It's meta, whatever, it's just data. So that's fine because it's not actually scripts. The scripts are on the admin side so you need to not have the CSP applying to the admin area in my opinion. I think though in general about unsafe in line and unsafe eval just like it took a while for everyone to move their CSS to external files I think when people start to become aware of the security implications then hopefully we as developers will start to build sites differently and make sure that the assets are externalized in separate files and then it will be able to start, stop using unsafe in line, unsafe eval in our content security policies but I think that's gonna be a while and you know Google I really feel like they're to blame like sometimes in their speed suggestions they'll say in line things because we'll make it faster and then they're like don't in line things because then you have security issues and then you have all the internet's a mess because of these types of things so in the meantime I think we're all gonna be using it and not much we can do about it. All right we do have a question in the first row over here. If we have any more, if you're in the back please stand up so we can see you. So what you just mentioned with the unsafe in line currently in WordPress all the translation for JavaScripts are done by inlining an object. Do you know of any of the plugins you mentioned that's using nonces to those inlines? No, it's like almost no one. Like really if you think about it how like 2% of the internet is using it if they're using it they're not using it necessarily in an optimum fashion and it's barely being used maybe the WordPress community needs to consider these types of things. I feel like the SRI could be something relevant to WordPress because one of the problems with SRI is that you need to be able to notify the users that there's an update to a library or something in order for them to regenerate the hash whereas that could actually be built in theoretically to WordPress because we all get updates to push tests. So I don't know. Because I don't see a good alternative to this current solution on how to translate JavaScript without inlining JavaScript into the website. Right I mean I think that's going to be the case with a lot of things like I said for the foreseeable future but maybe implementing non-SIR or hashes could help mitigate it for them in the meantime. Any more questions? We have time for one or two more. Don't be shy, right there. Hello. Sorry. Hello. Regarding the inline JavaScript and so on I'm not an expert okay but Vue.js does a lot of inlining and works with injecting the content inline to build the components and so on and so on and so on. But I never felt it as a security issue because all the properties are hidden right? Do you feel it like being in a problem with Vue? I mean I'm not familiar with Vue very much right? And I would hate to say that an entire thing should change the way that you're doing things. I'm a small person I don't know but if they've done it that way it's yet another sign of people including myself only like in the last six months did I start to really learn about content security policies. People just aren't aware that it's a security issue and what can I say? Google is saying make sure to offset all of your externalize your resources. So depending on how Vue is configured maybe they should too but I don't know. I hate to, I can't say. Hell have a look. Okay. All right do we have one last question? One last one now's your time. It is now or never. Okay if not we're just gonna close this question and answers and Miriam how can people reach out to you? I see an email address up there. Miriam at Stratix.com feel free to email me. I'd love to talk about content security policies cause nobody's talking about it. So we can have a conversation. All right people please give it up for Miriam Schwab. Thanks enjoy your lunch and the rest of the conference.