 So this talk is called security is a process, but also just plugging in a computer is apparently a process as well So I'm sorry for you the delayed start here. I'll try and maybe go fast. So we'll have enough time So I've been working with WordPress for About 13 years now. It's just a really long time. It's about a it's more than a third of my life And one of my focuses over the years has been security But I'd like to start with a little game kind of break the ice So we're gonna play two truths and a lie I'm gonna tell you three things two of them will be true one of them will be false So first I discovered a major WordPress security issue while auditing code in my head in a church That's one two is I disclosed a major security issue to a web host and Which caused them to accidentally take down their entire network with a fix and Three is my first commit to WordPress contained a security flaw So let's let's have a show of hands who thinks it's the church one Okay, how about the taking down a blog host More for that one and who thinks my first commit to WordPress contained a security flaw is the lie Okay, and and who didn't raise their hand because you think like you know I'm just not the sort of person who raises a hand But now that I'm now I'm calling you out and recognizing that you exist as a person You suddenly feel the swelling urge to like raise your hand for the first time ever. Okay. Yeah, you're out there Okay, you you people who didn't answer you're actually right because all those all three of those things are true and Yeah, the lie was that there were just two of them So So if that minor deception makes you feel vaguely annoyed and distrustful Welcome to the security mindset so this is what I'm talking about today the mindset that you should have as you are coding and deploying sites and working with web applications and it's It's a mindset that allows you to treat security as a process that is integrated into all aspects of your development First thing you need to do is stop thinking about security as a destination as a place as like something you arrive at like We are now finally secure. It's not like, you know, step seven make our code secure. We're done Sure like in my consulting I have a lot of people hand me code and I have to review it and say okay It looks good or here are some issues that you could fix But really no real world code can ever be said To be completely secure even if a given piece of code is secure in a moment in time Tech is not static. This is all changing the compiler that the code runs on could change in a way that Changes how that code works a new web server could come along that changes everything web browsers could add new features and suddenly Markup that was was okay is now Insecure and has implications So as an example take something like click-jacking who's ever heard of click-jacking Yeah, it's a catchy name. I like it. So it used to be fine To allow your web page to be embedded in another one in an iframe Once browsers got the ability to use CSS to make anything transparent including an iframe You could have a situation like this This is a completely legit site Because it's you know verisign trusted and Oprah-approved so this is a fine site and then we have an iframe embedded which is Justin Bieber's Facebook page with a like button So you would know like if you click that what you were doing you'd be liking his page But since you can use CSS to style iframes you can do something like this So now when you click that button you're not getting an iPad you're liking Justin Bieber's page Which is fine as long as you know what you're doing So don't think of security as the destination think of it as a Process by which you apply security mindset to every step of the process I want you to think as you're coding and as your designing features How could this go wrong? How could data be harmful? How could it be transformed to be harmful? How could it be harmful when combined with other data? How could someone use their access maliciously to cause harm? What would happen if someone sent a request on behalf of a user who's allowed to do something and sort of tricks them into doing it? There's a Japanese term called a pokey. Okay, which roughly translates to mistake-proofing and I believe is popularized by Toyota many many decades ago in their manufacturing process and has all the implications for design especially UI and UX so like you know you've a Form field for your age like you can't enter a negative number there stop them before they do that but this This idea also has implications for the design of your coding interfaces So if a certain type of data is going to cause a problem throwing through your flowing through your application Don't let it get there in the first place stop that mistake before it happens You should trust no one This is Terrible life advice, but is really good security advice So when you're putting on your coder hat just be thinking that you know Don't trust the people that wrote the code you depend on who wrote the web server that you run on You know wordpress core the the plugins you may be using and Don't trust the people who use their code that they're gonna always use it in the You know angelic way that you imagine them using it Is it kind of like an anti John Lennon stance? Just imagine all the people being really terrible And just assume if someone can do something that causes harm assume that they will and it's your job to write code That remains secure even when everyone is being their worst self When I said no one I mean no one you can't even trust yourself So who thinks that they're a better coder now than they were two years ago, right? Hopefully you're not getting worse Actually, does anyone think they've gotten worse? Okay Usually I thought we'd have one troll so The code that you wrote two years ago was written by a worse coder Even though it was you it was a worse version of you and you should not trust that person And even the current version of you is going to make mistakes So you should design your code so that it is harder for you to make security mistakes and You should integrate that security mindset into your coding to enable that So it's not something that you do later like when you're done writing the application you say, okay Let's go through and security proof this. This is something that should start with your first line of code and continue through the process So what does that look like practically? So for example Intent is a thing that a lot not a lot of people consider Certainly you'd have to check to make sure someone is allowed to do something which is permissions So you do something like current user can to validate that make sure they have a certain capability But less obvious is that you need to validate a user's intent So if if anyone has ever used Siri or the Amazon one whose name I will not mention because there are people on the live stream at home I don't want to purchase a dollhouse for them or something by mistake You're probably familiar with accidentally ordering something or Calling the wrong person or something like that So I mean this is something that you were allowed to do but you didn't really intend to do and the same is true When you're working with a web application I may be allowed to delete a post which may be like a form submission that says like action equals delete post post ID equals 123 But if someone can submit that make me submit that Request and delete that post without me intending to that. That's a security issue So we have functions like WP nonce field and WP verify nonce That allows you to make sure that the request from a logged in user is is actually Intended and so you would use the first one in the form field To generate a token that is unique to them and to the action that they want to do so like for deleting post one two three for user ID for this is a unique string and on the other end you verify it with WP verify nonce and if that that feel that that token does not Validate then potentially someone is trying to trick me into doing that action Next you should make sure that the code or the data that flows through your code is aggressively sanitized So if something should be an integer Make sure it's an integer. Don't just assume that it is going to be just because all the code that you wrote You know Like whenever you use it you supply an integer But there are pathways that data can flow in that you may not anticipate so you should make sure that your code ensures that So many issues are just due to weird data showing up where it shouldn't show up I'm the big proponent of sanitizing both on the way in to storage like a database and on the way out So for example, let's take this code right we have set ID and get ID and With both of them, I'm casting to an integer So on the first one as I update the option I make I cast it to an integer and on the way out I cast it before I return it and also the second argument. There is a default Argument, so it's zero if it's not set So my certainty when I use these methods 100% that I'm going to get an integer when I use them And if you're using PHP 7 which I recommend you look into for code that does not need to be widely distributed So this for private code for a client or something like that PHP 7 is great just for speed reasons, but you can also do things like Enforce this at a lower level so I have type declarations right there in your function Definition and in the return. So the first one says int ID It will expect an integer and it'll also do friendly things like If you pass in one two three as a string It will cast it to an integer just like the the previous example did And then for the second one get ID the colon int says that it should return in and We'll do the same thing WordPress also has helpful functions that you can use to sanitize common things here's a bunch of them and There's also a filter that you can use to apply to all gets and sets of an option So that example that I showed before You can do something like this So it's just sanitize option and then underscore the name of your option So this ensures that even if someone like a third party is extending your code and they are Calling a get option directly This filter will still be on it. So they will get the data that they expect Best way to enforce all the sanitization throughout your code base is the dry principle. Don't repeat yourself So write code once so Instead of having like 27 different calls to get option littered throughout, you know 17 different code files put it in one place and Make a method for it. This is just so much nicer to read throughout your code And so this that long get option with a get cast to int that you have to remember to do every single time if you just have get I this get ID arrow get ID It's a lot nicer to read It also lets you do things like if you want to change how that option is stored So maybe it starts out as a standalone option like this But then it moves into a sub key of like an array of options as as your plug-in gets more functionality That's easy to do. There's one place to change it instead of 17 or 27, whatever and Then it gives you one place where the sanitization is happening when you can control what that value is as it goes in Or out of the database. I think you should create methods for everything Not only is this good for your sanity. Well coding it just limits the number of places where you could compromise your security I do a lot of code review and I can't tell you how many times I'm auditing someone's code and nine times It's perfect. They apply all the functions of the sanitization properly Escaping is correct and the 10th time they miss it and there's your hole It just you just need a tiny crack to get in For example, if your code looks like this, it's really easy to make a mistake like I did on the third line Forgot to run escape attribute Instead I could write something like this. So here's a method for text input and I supply the name of the setting and It runs escape attribute That's the option escape attribute on that prints it out So no matter how many of these I add to my code. I'm not going to introduce a security hole I've already taken care of it in one place And it's just It lowers the risk of introducing new code So escaping Escaping data is something that you should do according to the context that it's being used in So the WordPress security functions are named in a very helpful way according to their context So for example, you're probably familiar with these ones escape HTML when you're between HTML tags attributes for within HTML attributes and URL for within URL based attributes like source or href and for sequel queries you should You should use prepare to sanitize your or to escape your queries Well, first of all, you should probably be using WordPress API functions But you need to do something with a database that's not supported use for pair And this allows you to pass in your data as separately from the query So you don't run into problems So now the whatever is in that name variable gets stuck where that Percent s character is Of course, what should we do with this should make a method out of it? One people one mistake people make when escaping their data is doing it far too early. So Online 100 they're printing out an input or something and then they escape the the values that are getting Output there at line 5 and This is problematic because you might not know the context that you're going to use the data in until you're about to use it You might want to use it in multiple contexts. So you may have escaped it in the wrong format and it's also It's also hard to audit Your code when the escaping hap escaping happens far removed from the usage So when you see that Output you're going to say, okay, is this escaped I escaped this earlier now lots of scrolling okay here I did it a hundred lines earlier So it's much better to do it right as or right before you output that data Next you should update everything WordPress your plugins web server php your local operating system It doesn't matter how secure your WordPress code is if the the platform that it's running on or the platform They're using to access it isn't secure. You have all you have a security hold a lower level You also shouldn't trust your ISP or the people on your local network SSL can keep your browser server communication secure and In 2016 and I would argue or 2017 as well as last year There's no excuse for not having this Thanks the good work of the people that lets encrypt everyone can get a an SSL certificate free of charge often, you know auto updated and So you don't have to budget that separately And if you're using one of the web hosts like one of the fine sponsors of this event A lot of them are just going to give this to you free of charge as part of your hosting service Sometimes you have to opt into that I definitely recommend that at least for securing the WordPress admin And this one's interesting So I'm a little bit conflicted on this because it's definitely a good idea that WordPress is self updating Because you know if an exploit comes out we can update and push that out to to millions of WordPress installs But it also is a bit of a security issue if WordPress can write update its own files you might have an issue where a plugin exploit Allows code to be written and someone can write out a PHP shell To your server and then access it and get ongoing access So if you know that you're gonna be quickly updating your site If you're managing sites for clients and you're on top of this with something like managed WP where you know like Okay, these sites are out of date It can make sense to have the WordPress files not server writeable by the server user and It might make sense for you to use a deploy system To update those files Of course, there's one directory on your server that that pretty much has to be server writeable And that's the uploads folder so that WordPress can write out JPEGs when you upload them so if If I were writing a code vulnerability, that's the first place I would try and write like a PHP Shell is to that uploads directory because I'm pretty much assured that it's gonna be writeable So one in-depth defense trick you can use is to disable execution in this directory So you could have something like this in an HT access file in the uploads directory Of course, you'd want to make sure that that file is not server writeable. Otherwise, they can just delete it And here's how to do it on engine X saying anything in the uploads directory That ends in dot PHP just deny it So this this won't prevent them from Like if someone gets access to upload files PHP files somehow through an exploit They could still do it, but then they can't access that file through the browser and use it as a PHP shell So it essentially becomes inert Using git can be a good way to verify that all your files are as expected and have not been modified So like if you did a git diff any file modifications would show up Also lets you know if they say some other developer is cowboy coding and directly editing files on the server Which they shouldn't be doing And that's it a deploy script for this is could be a simple two-line affair We just get fetch to get the newest code and get reset hard to your origin master And of course if you're using git checkout, you don't want people to be able to access this git dot git data directory Over the web. So you're gonna use a saint a similar trick to like say block all dot files Or here block dot git and dot SVN directories So, but let's let's apply our security mindset to An even deeper level having production credentials in your repository is a bad idea I see a lot of people a lot clients do this where I go to check out their site and There's there the database password. So I go to run this locally and it's trying to connect to the production database and It's bad because first of all anyone who has access to your repository has those credentials and you might not want them to have it You also want to limit like the ways that someone could get those credentials and there will be come though There will come a day if you have production credentials distributed like this that someone sets up a local development environment and then Delete your production database I don't know did anyone see that the thread on reddit where someone's first day they set up a production environment and deleted everything Yeah sad day So you can check in a WP config file, but I would just keep those database credentials out of it and have like a separate file that is ignored by git like DB config dot PHP And then just have that sit on the on the server not checked in So this is something I debated including in this talk because it seems so basic We're all professional developers here. Certainly. We all use strong unique passwords, right? Yeah We don't not not every time not as much as we should So I came up with this acronym for choosing a good password and it stands for complex long unique and enigmatic Actually, the first version was I used for the e I used esoteric which proved to be too esoteric a word confused people So Complex so you should use, you know alpha characters symbols numeric should be long and when I say long I mean like longer than 16 characters all my passwords are in the 30 to 50 character range You should unique you should never be reusing passwords across sites because as soon as one gets compromised Then they can use that to gain access to other Accounts and enigmatic so like no personal information nothing that can be tied to you that people could really guess I was thinking about showing you some examples of secure passwords, but has anyone ever seen this xkcd comic Pretty popular one about advice about you know how there's there's more Entropy in a password like this then like an eight character random garbled characters password So the problem of this is that I actually had a sysadmin set up an account for me and use this exact password Not very unique So I'm not going to show you examples and but really you shouldn't be creating your own passwords in your brain You should be using a password manager. So something like one password or last pass can generate Great passwords super long super complex For all of your accounts and you never even have to know what they are So when your boyfriend or girlfriend is like, hey, what's your face about password? You can say I don't know and then when they break up with you. You can blame me So let's review and as we do I'd like you to start thinking about the questions You'd like to ask so that we don't have that awkward minute of silence where I ask you if there are any questions And there are crickets so start thinking So security mindset, I want you to remember that Security is a process not a destination integrate it into every step of the development process Ask yourself, how could this go wrong? How could data be misused? How could be transformed? Trust no one ever assume everyone's gonna abuse their power except that the data you get is gonna be wrong or malicious You sanitization and escaping to prevent bad bad data from causing security issues Validate the intent so no one can trick your users into doing something they don't mean to do and Keep everything updated every piece of software on the server and on your local machine and When you're coding distrust yourself set things up so that you have to work really hard to introduce a security issue and Create methods for everything so that your code is clean and you minimize those danger zones where you need to escape or sanitize data and One last thing before I open it up When you're done working for the day forget everything I said because all this is great for security But you don't want to be this person right So that's it. Thank you Thank you mark now we have time for maybe two or three questions at the very most What we'd like to do this time is have people queuing up at the mic stands that are dotted around here here here in here Does anyone have any questions they'd like to ask mark? If you make your way to a stand Please even with warning we have the awkward silence And maybe you're all good. Yeah, we have a question coming down below. Thank you. I Guessed you hear this a lot, but why is WordPress still supporting PHP 5.2 Yeah, why is WordPress still run PHP 5.2 because there are still people using it Does anyone have the latest stat the stats are public? I'm sure there's like a nascent here knows it off the top of his head Seven Seven okay, so that's that's getting I think about to the point where we dropped PHP 4 support I think it was somewhere in that range So I think we'll be doing that soon, of course We're gonna be updating them in a requirement to 5.3, which of course is also woefully outdated But the reason is because people are still are still using it and we don't want to break their sites And there's always a trade-off, you know, do we want to make the hard decision and eventually we do But we don't want to be you know, I think Matt said it wants, you know 15% of our user base is like the population population of a major city That's a lot of people to be just kind of turning out the lights for We have questions down. We also work with web posts to encourage them to have the latest version So we are proactive in that sense. Absolutely question down here, please. Hello. I've got a question about security in distributed code like Are are all the releases signed by someone with GBG or are all the updates signed like why should I plan we trust someone if that's not signed Yeah SSL Definitely helps with that, but it's it's not a complete solution and there is an ongoing debate because of our You know our minimum version of PHP. There are certain things that we I am talking about Like like signing git tags or suppression tags So I know that that's what you release not what my ISP is actually giving me Right. Um, so you're talking like for updating WordPress itself or just like when you're working with your own repo Yeah, with your own repo, especially because it is open source. So Yeah, so like git itself has way to sign commits and sign tags and are you guys doing that? Yeah, okay that's that absolutely it's it's it's a geeky but Again, like you're just putting up hurdles and the more hurdles you put off put up You know, you're just not gonna be the the the person that a hacker comes after the they're generally looking for the easy targets unless you're You know overly political or something like that where they're targeting you specifically We're gonna take one more question and you're all gonna sit very nicely until I dismiss you. Okay, Jolly Hi There are a lot of WordPress security plugins out there most of them are pretty terrible my opinion What what plugins would you recommend to use and which ones would you recommend to avoid for? plugins in general or for security the security WordPress plugins. Yeah. Yeah, the What's it called the I themes one Aaron? Where are you? I? Think security is a good one. I've I've I helped Aaron in years past look over that look over their feature set Securey I recommend there was a web application firewall Which is like sort of like cloud flare on steroids where it can you know cache data I've also protect against exploits at their level before things even hit your server Those are good There's the the jetpack one Brute protect Jetpack. Yeah, well jetpack has has a has one as well Those are good. I recommend those Yeah, I'd also recommend having two-factor authentication as well as I think you lean in a little bit more again, sorry When you're managing a big network of sites having two-factor Authentication is really important as well. Yes, that's a lot of brute-forcing on the ad WP admin. Absolutely Great. Well folks. Thank you most group. Please don't thank Mark. Jake with stay here stay here