 Looks like we got time, so I'll go ahead and get started. My name's Chris Wigman. I'm a senior web engineer for TenUp. And before I did this gig, I built security plugins. So I've reviewed a lot of code over the years and had to look out for a lot of what I'm going to talk about today. And what we are going to talk about today, then, is some of the bigger vulnerabilities that we see in WordPress. This is a fairly advanced talk. I'm going to go through some codes. So if you're not comfortable for that, this is probably not the talk for you, to be honest. We're going to be talking about what the vulnerabilities are from a code level and how you kind of avoid them, what to look for as you're programming plug-ins or themes or things like that. In order to talk about this, one of the big questions we have to ask is, who identifies these vulnerabilities? These aren't something that I just picked out of a hat. There's actually something called the Open Web Application Security Project. It doesn't just cover WordPress. It covers vulnerabilities web-wide. This might be ASP.net. This might be Java. This might be any language that's typically used on a website. This organization, what they do is every three years, they come up with the top 10 application security risks. The current one out is from 2013. So it'll be updated this year. And it applies these things across a wide vulnerability. Now, fortunately, with WordPress taking up 25% of the entire internet at this point, most of them or pretty much all of them in one fashion or another are applicable to WordPress. With the nice benefit of WordPress Core, if we do this right, I'll eliminate a lot of the risks in our own code for us. When we talk about these vulnerabilities and then they deal with a couple things, they are dealing with code, but there's also some of the biggest problems we're gonna see with WordPress are configuration and just general vulnerabilities outside of our code. Even as developers, there are numerous things we can do. Sometimes it's simply to make our lives easier or to give access to that one person who needed it to sign off on your project that was due yesterday. But these are the types of security and various configurations, server configurations and general vulnerabilities that we're gonna talk about that really affect us here. And they're gonna target various different applications or different parts of WordPress as well. So we're not always just targeting WordPress, the four meg zip that you download from WordPress.org. In some cases, we're talking about vulnerabilities that target the server or could potentially damage things underneath. So in other words, if you have 100 sites on your one server, you're hosting with Linode or even if you have Bluehost and you have 60 different sites in your unlimited account, it could very well be that just because one is hacked, it doesn't mean it's gonna stay in that one site. It can target pieces underneath and spread. So we're talking about things that can target the server itself. We can target things, they're talking about things that are targeting the application. And the application, of course, is WordPress. And we're also talking about things here that target the user. So these don't always, they're not always trying to get to your server itself. In many cases, what they're gonna do is they're gonna actually attack you, they're trying to get at your user. Either it's to get data from somebody who's at your site, they're trying to break the trust relationship. Because in the end, all this comes down to, it's not so bad. If we have our own blog up there that's about food, whatever you write about, whatever your small site's about, whatever your large site about, it's not so much the data of your own that you're protecting in many cases. You probably have 17 backups. Maybe some people, you do your writing in Word, whatever it might be. It's not your data. It's the trust relationship between you and your clients that you're trying to protect here. It's that ability for your user to say, well, last time I went to that site, I got malware. I'm not going back to read his stuff, no matter our first stuff, no matter what it is. So any things that target the user are often overlooked when we talk about WordPress security. But the truth of the matter is, this is really what we're trying to protect. All the data in the world, if we lose a few blog posts even, it's not the end of the world. If you lose the trust of your readers and more importantly, your customers, depending on what you're trying to sell, that might be the end of your world. So that's something that's a very big distinction that you have to remember when we're talking about this type of security. So the OWASP project, I've gone through and I've picked, and I haven't necessarily picked these in order, but they do have a number of vulnerabilities in the 2013 list that specifically target WordPress, and this is an overview of them. We're gonna talk about sensitive data exposure, security misconfiguration, injection, cross-site scripting, insecure direct object references, missing function level access control, and CRSF or cross-site request forgeries. Most of these are very developer centric, but again, you don't have to be a developer to create a vulnerability, to take advantage of a vulnerability to create it by somebody else in some cases. And this top one is simply the most common one that we're gonna see in WordPress. This is really where it's gonna break that trust with your users. Sensitive data exposure. This might be, how many people in the room use WPCLI? It is a great feature of database export. WPDB export, and it creates a SQL dump of your database, everything in it. And it does it right in the web route if you don't do anything else of your application. So right in the exposed WordPress server route that's available to the web. So you do your database export and you leave it there. Anybody who wants to download that list of your users, any user meta, maybe addresses or something else that you have in there, that file is just sitting out there ready to be downloaded. That's a sensitive data exposure. It might be as simple as you left an extra admin in there. Your developer came by six months ago, did some work for you. He left his account with just the username password, but it has access to absolutely everything. Their credit card information, whatever else that you have. That's sensitive data exposure. There's a whole lot of ways that we can expose data without even trying in many cases. And without realizing that very simple tasks that we need to perform our job can leave this data in places at which it can be compromised very easily. Now of course the primary target of this is the application in the server. And it's a very severe risk. This is where you break the trust of your user. If they start getting spammed from 150 different pharmacy ads and it can somehow be traced back to they got your email address because you left it exposed to them, you've now broken the trust of that user. This is the worst case scenario and that's why I listed first. I believe this is actually number seven or eight on the OWASP list of the top 10 vulnerabilities. But it's by far the most damaging, particularly to a small site owner or a small business owner who relies on either repeat customers or some sort of reoccurring income from people that you need to have trust you. Difficulty to exploit, this says it's difficult and that's coming from OWASP. Many times it is, if you do a database dump, my initial example, if you do that WPCLIDB dump and you leave it there, what did you name the file? Well, they may have to guess or they may need some other way to just stumble upon that file. But the only thing preventing them there is what they call security by obscurity. Which is anybody who works in security who's played with security before tells you it's not really any security at all. That's just simply renaming something and hoping that they don't stumble upon it. Not quite the way you want your user data to be protected. And of course, the outcomes of this is sensitive data exposures we've discussed. Many of these are gonna come out from a security misconfiguration. And this is simply a misconfiguration anywhere that can lead to a compromise. It's usually, again, in the application of the server. It's moderate risk. Sometimes it might mean nothing. Maybe it just means that Google is indexing your staging site and you don't want it. Maybe you got mad at the staging site and your test data and there is some colorful language and all of a sudden Google's indexing that for your client instead of their main site. That is a security misconfiguration. That is getting out data on your client that shouldn't be out there. These are really easy to exploit. If you go into the reading settings, maybe it's something as simple as checking the little box that says don't allow crawlers on the site. Maybe it's something as simple if you have a membership plugin of checking the right box that says the site's a private site or leaving the wrong user with the wrong access credentials. These are very simple and they're all throughout. From a developer point of view, maybe this is leaving the untrusted SSL certificate on because you were testing and you didn't want to pay and you haven't figured out let's encrypt yet. There are numerous ways in which this can be exploited very quickly. So watching out and dotting your eyes, crossing your T's become very important. This is the biggest one. And developers are probably more guilty of this than most. We focus on code. We think, hey, I have sanitized all my data. There's absolutely nothing that anybody's gonna put in there. And then we leave an open admin account with the word password for the password or something stupid. It happens all the time. And it's a very simple way to create a very big problem for yourself and for your users. Now, of course, that's the simple way to do things. And some of these others are a little bit more difficult, at least if you're not a developer, you're probably not gonna implement them yourselves. And the first one is injection. Injection is simply a vulnerability which lets your server run code that it's not supposed to run. This could be your PHP. This could be MySQL. There's a famous cartoon out by XKCD in which they named the student, the kid's name is Drop Tables with a semicolon. So it goes to the database and it says Drop Tables, which anybody who's used MySQL knows that deletes the database. That's injection on a database. PHP, it's just as easy to run. It also is gonna attack the server and this application. Typically when this is a vulnerability, it can take over, this is the type of thing that can take over your whole server if done wrong. This is the type of thing where they start leaving PHP code in various places that can do things like set up new users for you. Change users for you. Change your homepage so only Google can see the funny ads that it puts in and you don't even know that you're compromised and the list goes on and on and on. It's very easy to exploit if it's available. These are the types of things that with even the big security plugins, the other plugins you see out there, typically when you see a vulnerability come by and they say everybody needs to update this right away. Many times it's because something can be executed remotely and something as simple that we've used in WordPress all the time. If you've used any of the XML feeds and XMLRPC and stuff like that that uses serialized data, just running unserialized on a piece of data runs code. Now we all have JSON. JSON is a transport mechanism for transporting data from one server to another. It uses JavaScript, but there's nothing executable in it and it replaces in many cases serialization. And serialization has a neat little feature. It'll run the constructor if you build a class, it'll run the wake function. So you can pass data back to a WordPress site and if that function is there, it's just gonna run whatever code it's told to run. You've now made quite a large hole for your server. And there's ways to make serialization a bit safer but for the most part and most uses I've seen of it particularly in plugins and themes, it can be a very big hole. All it takes is the right post content with something like Postman if you use Chrome or something simpler to exploit a site and take it over if done correctly. And the next one of course is cross-site scripting. First, the first time around we tried to execute code in the server. We wanna execute PHP code in my SQL code. When we talk about cross-site scripting, it's user supply data sent to the browser without validation. It can be executed data, it can be things like executing JavaScript. This can be the types of things where you see people put something in a URL with the alert one or they put a form in the, you know, gravity forms, you can't do this with gravity form so I wanna use them as an example only because we all know the name but if gravity forms had this or any other form plug-in had this you would put alert one in a box, you submit your form and all of a sudden alert one pops up. Alert one being a JavaScript. It's usually a quick test a lot of people do. It puts a little JavaScript pop-up with something on it. Maybe you say hello world or whatever. That's cross-site scripting. It's typically targeting the user. It is of moderate risk. There are ways you can steal user credentials doing this. It's not the easiest thing to exploit. You usually have to go around hunting for it. These are the types of things that once it's found it's why it's so important to upgrade your plug-in. If your plug-in is found with a vulnerability like this you wanna upgrade it right away because that's when all the script kitties and all the hackers are gonna go by writing bots that are gonna exploit it for you if you don't patch it. But it's not something that people typically stumble upon right away. Outcomes here, hijack browser, deface website, redirect user. These are the classics. Bank login forms and things like that. Ways to redirect a user so that you can get their credentials off things like that. Taking their cookie, their login cookie. If it's an admin user, you can use JavaScript to grab the cookies. Sending that back to another server. These are the types of things that hackers are trying to do with cross-site scripting. And they're very simple to do. A little bit of code example. The first one is if is set, get my secret key. This was, the way this would work is you put something in your browser URL with a question mark, my secret key equals whatever. And then you just echo it back to the screen. So you could put my secret key equals JavaScript and spell it out and it'll run that JavaScript for you. Document.cookie. You can start getting ahold of cookies that way. You don't see quite that blatant too often in WordPress anymore. Most of the, especially in big plugins that's one of the nice things about the maturity level of WordPress at this point is at least some big developers are avoiding these types of mistakes. You do see it a lot sometimes in newer developers' plugins or themes that are very custom and maybe the developer isn't quite as experienced. And the second one goes back to, John Block just did an excellent presentation on translatable functions. The second one is actually could be a cross-site scripting example of a problem with translatable functions, namely just underscore underscore my text to translate. The catch is who writes your .pot file? Who writes the translation file? You can put absolutely anything you want. All that does is echo the function. WordPress.org has tools to find it. So if you're going out and downloading whatever your Spanish language translation pack from WordPress.org, you're pretty safe. If it's a private company that keeps track of its translations, especially a smaller company where maybe they have 30 translations and there's six people in the company, they don't speak those languages. They're not going through every single translation. Almost, I've yet to see anybody do a security review on a translation file. Anything can be put in there. So where John was talking about the escape HTML underscore and underscore, all of his extracredit functions, that's the type of thing you need to sanitize these just as much as you need to sanitize anything else. Like again, you don't see it as much because WordPress.org covers a lot. But on the private side of things, this can get you in trouble pretty quickly. Another one that works, you used to see this a little bit more, especially with really complex plugins and themes is insecure direct object references. The use of a key or name to request an object whereas the target object does not verify the requesters access permission. In other words, I put something in the URL that says user equals and put a username. And I get all the data on my user. Well, what if I just change that username? There's no control over what user I get. So if I wanted somebody in the front row, I'm supposed to see my own profile, but if I wanted anybody else out here and I could just change that username variable, that's an insecure direct object reference. It's allowing me to access data that I'm not supposed to, simply by changing just a little bit. Here's a very simple example. If you had some sort of object that was retrieving users, my WP user and then you have a get user key. Maybe there's 15 users in there you're only supposed to have your own just by changing that user key. You could go ahead and get back the other 14. If you're using WordPress APIs, you're probably safe with this, but this is just like John was talking about with translations. You wanna make sure that you're using your API functions. You wanna make sure that you're using their data access, things like nonces, things like proper permission checks, things like actually using WP users and built-in tables and stuff like that rather than trying to go out there and reinvent the wheel yourself, which is where something like this is quite often gonna come in place. Again, WordPress in its earlier days, before these APIs were quite as robust, you'd see a lot of things like this because people were reinventing the wheel themselves. They were having to build this functionality in. If you're up on WordPress and up on what you're developing, you shouldn't have this problem anymore. Here's another similar one. Missing function level access control, which is failure to verify access rights upon access to a specific function. Targeting the same types of things with a moderate risk but very easy to exploit and it can result in data corruption, sensitive data. This is changing the URL. We've all seen login pages where if you go to, we've gone to a website where, well, how do we log into this? So you start testing things like admin or you start testing things like slash user. Custom systems are really good at this. There's not so much banks anymore. I've seen universities, I think, is where I've seen this happen the most. You're logged in, you see your data and you're like, well, maybe you need to do some other function. So you start guessing at what the URL is and all of a sudden now you have access to what you needed to do. That is missing function level access control. If they didn't provide it to you as a direct, like they wanted you to access it and it's still available to you. They have no control over that function. There's no control over that access and that's a problem. Here's a simple example that you might see in an older WordPress plugin, something along the lines of my plug-in slash user if they had a user screen. And without checking, you can switch over to my plug-in dash admin and you can edit settings. The particular, the last two are actually an old example I have from an actual plugin whose name I'm not gonna list, but it does happen. It doesn't happen as much anymore but it's simply creating the same access for everybody and just relying on the URL to decide who's supposed to be where. Of course then there's cross-site request forgery. Another big one, this is forcing a login victim's browser to send a forged request to a vulnerable web application. Things like this is how people steal your cookies. This is how people steal session information, login information and things like that in order to use it against you from the front end of a website. You're targeting the user and it can be a fairly moderate risk. It might be something as simple as if it's a simple blog, they deface your website, they get a hold of a cookie passwords they can't use. But it can be, once it's out there it's also very easy to exploit and it can result in all kinds of problems. And it can look very simple. In this case it's just an image. Somebody puts an image in your comments or some other little bit of code in your comments with a get my password string. Maybe that's a little bit of JavaScript or something that runs. Maybe that's something some other type of code. Maybe it's something as simple as you don't really want your competition tracking you and just like at the bottom of every, if you use Jetpack, one of the big issues with Jetpack has always been that little smiley face that everybody hates at the bottom and that's used to track users. Maybe you don't want your users tracked. In which case, that's a perfect example. Jetpack is not a CRSF for whoever's listening live. It is not an exploit. That is an intentional, that is something you're agreeing to when you install Jetpack. But these are the types of things that attackers would do. Maybe if they want your data, browser data, demographical data, a simple image logging all that, the same information Google Analytics could launch could be a problem for your users, especially if you're in a European country or something with very strict privacy laws and you now have a third party breaking privacy laws on you. And of course it can get much more advanced if JavaScript was run, maybe it could steal cookies or something like that, but typically it winds up being just more of a demographics target, at least in my experience in the code I review, but it's still something that you often need to look out for. Those are the basic ones there. It's kind of a fast run-through of what you're looking for. Unfortunately with 25 minutes, I'd love to give a whole lot of code examples, but I do actually have this presentation online as well on my personal site, I will tweet out. And I have an extension to this because I used to get this as a one-hour talk on various different PHP functions you could look out for these specifics, things like eval, things like filter var, things like unserialize with a little bit more of an example on why these can be a bit of more of a problem and how these can be exploited here, and then a little bit more alternatives on how to use them. This is what I have for today. Does anybody have any questions with this? Why is it called cross-site? I always, it implies to me there's like a second site which would really be a different thing. Why is it called cross-site scripting? Oftentimes for instance, the question is why is it called cross-site scripting? Oftentimes if you take my example of if we wanted to track my competition's demographic data, so we put an image on that other site, well that image goes out to a second site to download data, right? So it's sending your data to somebody else. It's sending your data off to a third-party server and it's actually running that exploit, let's say it's just a simple Google Analytics tag, Google's a third-party, it's another site that's running it. Does that make sense? Okay, that's one thing, they'll just like put something into a form field and then boom, you'll get that alert box of something and it's really just enclosed on that one site. That's more XSS. I'm sorry, I'm thinking cross-site request forager. I'm still at the end of my presentation there. Same thing with cross-site scripting there. A lot of times, if you just did an alert, one is in demonstration, you're fine, you know it's vulnerable, but what if I put in document.cookie or href equals or window.location equals and started taking you to other sites that looked similar. Or what if I took your cookie and sent it off via a post-request or something along those lines. You can steal all kinds of data, you can get access to sites, you can do all kinds of things with cross-site scripting, mostly by sending data to other third parties and then using that data back against you in a lot of cases. I can't even sleep anymore again. Glad I could help. You mentioned about damages to small businesses or websites, one of the things Malware does is tell the SEO because Google penalized them. They may not know about it, so they don't have that massive tool. They may have a totally useless website because they're the index out of Google because the malware may be in the nobody. My comment is, I deal with this a lot. I'm always looking at logs. And I see in my access logs, www.com slash, and they put junk in the back of my URL. And sometimes it's things like usernames and passwords and then when this is crap that they're putting on here, but there must be a reason why they do that. Do you have an idea of what they're doing there? Sure, a lot of these are what they would call a dumb bot. It basically has a database of like a dictionary of all the exploits found. They can go back to my old plugin, which is better, WP Security. And when we had a problem, they say, oh, well, if somebody hasn't updated, this is the string that we need at the end of a URL or the right form field that we need to hit, whatever it might be. And it can run through thousands of these different ones that it knows about and just keep running and trying at those. And that's what you're seeing there. Yes, oftentimes you're gonna get hit pretty good. And that's where some of the firewall plugins are really good at filtering those out. Securities are an excellent resource for filtering those out. And there's others as well that are gonna, they're looking for that type of behavior. If they're looking for these bots that are attacking and looking for these exploits, and then they just stop. And then they just stop them from coming to your site. It's hard to be a, to move around with a fixed mic. We have a match, right? So do you think it could be related or, and how can we handle something in this case that, you know, it's keeping, you know, coming back and we don't know exactly where it came from and how will the investigators find out, you know, the problem is everything's up to the agent. Sure, the question was, in the beginning of the month, security released details of a major attack it was seeing across a large swath of WordPress and other use, potentially other users. I can't remember the details. And, but they don't know the cause. That there was no root cause identified. How can we protect against that? The truth of the matter is a firewall like security and something that's gonna protect for you, somebody who's identified that the patterns, it uses what they call heuristics. They're building rules based on what they've seen. So those types of firewalls, cloudflare, security in particular, are gonna be able to see that and keep it from your server because unless you know what you're protecting against on your server, you're in trouble. The question was also, could this be part of the G-Lib C? G-Lib C being a very common library used on Linux servers, could this be related? It's possible. I can't really speculate if it is or not. But if you can prevent it from getting your server in the first place, well, either A, update if you can, and B, if you can prevent it from getting that far, that's really your only recourse in a situation. In some cases, that's really your only option is to monitor and look at your logs, watch what's going on and be proactive. You know your site better than anybody. I could go, any given site in here, if something's weird, I get five hits a day, say, normally on my site. Now, all of a sudden I stuck it in 25,000 hits a day. I'm the one who's gonna notice that even before some of these scanners, it's up to me then to respond and then look at logs and see what's happening. Maybe block IP addresses, whatever it might take in order to react to that situation. In the back there? The question was with secure and some of these, is it better to use a third party type authenticator to log into WordPress? In my experience, no, the accounts usually are still there. I mean, there's still a WordPress user in your database. So the type of, unless you completely disable that login form, they're still gonna try constant, the better thing is making sure you have something like fail to ban installed. That's gonna look at the attempts at login, regardless of where it's coming from, and block it there. Does that make sense? Okay. What security, what security plugins or other options do I recommend? If you're looking for best practices, you're a new blogger, you're a new site owner, iThemes Security does a very good job of enforcing best practices. iThemes Security, it is not a firewall. It is not claiming to be a firewall. It's gonna tell you things like make sure all your users passwords are strong, change users, all the best practices that you can do to prevent security misconfigurations and things like that. For true protection, on a plugin level, I strongly recommend Security. They provide a firewall, it is a paid service, but their firewall and their service behind WordPress, its goal is, it doesn't even get to your server, everything goes through theirs, so they can filter out all kinds of things before it gets to your site, and that's really the best way to protect something at that level. Sure. The question is, what would I recommend for IP address filtering that's not necessarily WordPress specific? There's all kinds of, country level gets really weird, because it changes, it's easy to mask. There's all kinds of databases you can buy, and I can't think of the name of the major company off the top of my head. There's a company that sells these databases, and they do them. They subscribe to one of these services for that, but that's very WordPress specific. They get around them so easily now. Exactly. What I recommend is Fail2Ban. If you have a Linux-based server, Fail2Ban, it's a Linux service that you can build in any rules you want, three bad logins. It can replace login lockdown, it can replace jet packs at the server level, and it can watch for anything at all you want. Some guy just hit my contact form 25 times in a row, that's probably weird. So you set a rule up, and you can ban that IP address that way. It's basically sending your own heuristics. It can take some configuration, but for a local something that you can install that is not WordPress specific, that's probably your best bet. And of course, Security has solutions for non-WordPress sites as well. Man, excellent question. The question is, what resources do I recommend for developers to prevent these? The whole idea here is developers preventing XSS, and these are the things you're looking for. 10-UPS engineering best practices, which are public and are all available on GitHub and the 10-UPS website, probably one of the best out there. The WordPress Codex. Using things like standard WordPress APIs. If you wanna build it, if you want the feature, if you want access to a piece of WordPress, there is documentation either in the Codex or someplace close by that's gonna help you do it. WordPress coding standards. If you use PHP Storm, Sublime Text, Adam, you can actually download all of WordPress's coding standards and you can set them to the VIP level. It gives you a few false positives, but what it's gonna do is it's gonna flag all kinds of things through your code that says, oh hey, you're directly accessing a Git variable here. Check this. It's gonna say, you're using JSON and code, instead of WP JSON and code. Check this. It's gonna go right up and down the line and it's gonna, well it's gonna annoy the heck out of you if you're using another project you've been building for a while the first couple of times, but it's an excellent tool, it's free, it's on GitHub, it works with PHP Code Sniffer, very easy to install, and it'll watch all that code for you. It's not gonna fix it for you, but it's gonna give you tons of warnings that you just simply didn't know were happening before. That's WordPress's coding standards. I'll tweet links out for this after as well, and it's combined with PHP Code Sniffer. It's a linter for PHP that does a very good job. It's not built in, PHP Storm can support it, you still have to have Code Sniffer installed, and you can install it as a composer package if you use composer, and then the WordPress coding standards, it's literally a link, it gives you one command to set that part of it up. I think we've got time for one more question. How they do it. So I'm looking like I have the encoded stuff that you talked about, I'm searching for that. Do you know a place where I can find signatures, or what I can use? All my own examples I've built over years of reviewing code and cleaning people's sites. I've never seen anybody for very legitimate reasons, not even business protection. That's probably data that they don't want available. You can use open vulnerable or CVE database and things like that for general. Sometimes they have exploit codes, sometimes they don't, it depends on who's releasing it. But more often than not, I'll look to see if it's a legitimate vulnerability, but if I'm cleaning somebody's site, I always save the code snippets and log snippets and that's really where I've found to be far more reliable than a lot of the databases out there to be honest. Or there was the first talk this morning was also a product that does code scanning, automated code scanning. So maybe that's something that would also be worth looking into. Unfortunately I missed half his talk. I can't say too much on there. But that was very specifically what they did as well is they actually have a product that you could purchase to scan it. Anyway, it looks like I'm out of time, so thank you all very much. If you have any questions, I'll be happy to take them outside of here.