 Good morning everybody. You can do better than that. Good morning everybody. You're here to talk about security. So welcome folks. This is securing your Drupal site. It's part of the site building track and is a beginner session. So if you're relatively new to Drupal, then this is a great way to start off your Drupal con. In general, security is perhaps a more advanced topic. So we tried our best to align the topics that we're talking about with that audience in mind. We do have a whole bunch of slides online, and they're full of a whole bunch of links. So the URL is right there. I encourage you to actually, either now or later, actually go to those slides and see all of the links that are from there. So this is advice for site builders and a little bit of coders. I am Greg Canadasen. I've worked with Drupal for nine plus years now, nine and a half years basically. I'm pretty interested in security. That's a little bit of an understatement. Work on the Drupal security team, wrote a book Cracking Drupal About Security, and I work at card.com, a mobile alternative to your traditional branch bank, and of course we're hiring. And Michael Hess? I'm Michael Hess. I've worked with Drupal a little less than Greg, six plus years. I'm responsible for hosting around 900-ish sites at the University of Michigan. I work on a lot of large-scale health projects, and I teach three classes on content management platforms, which is basically Drupal, WordPress, et cetera. All right, so lots of things to cover. We're going to do our best to, you know, there's a very broad area, but we feel like the best thing that we can do is just give, you know, quick touch on a lot of topics and pointers to resources so that if you're interested, you can follow up in a specific area. In the web world, you know, more broadly, outside of just Drupal, there's the Open Web Application Security Project. And they sort of take a broad view of all websites' web services to see what are the biggest problems. And every couple of years, they publish their top 10 list of, you know, most commonly exploited, most dangerous issues that they feel people should really be putting attention on. And so this is their list of the top 10 items. Within the Drupal world, I think that, you know, we have to consider our context, which is a little bit more focused on a couple of different areas. So we have some vulnerabilities that seem to come up more often in Drupal. And you could either be optimistic and say that the framework gives us protection against certain classes of vulnerabilities, and therefore we don't have to worry as much about them, or maybe you could be pessimistic about this and say that Drupal makes it really easy to make cross-site scripting attacks. Drupal's database API makes it really hard to create a SQL injection vulnerability. And I think that, you know, that is why we see that, you know, number one in the broader world is injection attacks such as SQL injection, and yet in Drupal, the frequency of that is much, much lower. So this information is all-time data from 2005 until, I believe, it's the fall of 2014, looking at what are the most common vulnerabilities. But I think it's also interesting that it's evolved over time. So what you can see is that in 2005, there were actually, you know, 50% of the issues were SQL injection. And then that's really thinned out over the years, and we have many, many fewer SQL injection attacks these days than we did back then. Cross-site scripting has sort of been a persistent problem in Drupal projects. And I should have added this is data about contributed modules and core on Drupal.org. So it doesn't necessarily reflect individual sites' experience in custom code or custom themes, but it does give, I think, a good sense of how common different kinds of vulnerabilities are, and therefore what should we be focusing on as developers and as site builders. So we see that, you know, access bypass is kind of a growing type of problem that we've got in the Drupal community. It didn't happen so much back, you know, in 2005, but it's been increasingly large percent of the issues that we deal with. CSRF sort of started off with issues, and then we had more and more, and I think, again, is tapering off. And cross-site scripting is sort of still there and persistent. So, so why are we here today? The FBI notes cyber attacks are eclipsing terrorism as the primary threat facing the U.S., which probably doesn't just apply to the U.S., it probably applies much more broadly. 75% of small businesses' surveys reported cyber attacks, and I'm going to go ahead and guess the other 25% now. And if you think about a single breach in 2010 that was reported, there were 38 terabytes of data stolen. That's twice the size of the Library of Congress. Now, what one organization has that's 38 terabytes that can be stolen, that's a different story. So, everyone gets hacked, and it must be trendy. Out of curiosity, how many people in here, show of hands, who wants to admit it, have had a site for one reason or another. And I'll put my hand up, I've had one too. So, it happens to everyone. And what we're going to do today is we're going to talk about some of the ways in which hackers hack sites, and we're going to do it in the form of telling a story. So it kind of sets context for what we're doing. So, these are real stories, everything here actually happened, but the details have been changed, the organization names have been fictionalized. So, they read like works of fiction, but they're based in truth. So, we're going to talk about the tale of the red ribbon hacker. This is a tale about a shoe store run by a kind woman named Myrtle. And from her online store, she mails shoes around the entire world, and each box that gets sent to people comes tied up with a little ribbon, like a box of candy. Myrtle investigated how to set up her store before she did so, and she wanted to be PCI compliant. How many people know what PCI compliant is? This is a beginner session? So, PCI compliance, and I'm going to summer, I'm going to make this simple, is basically the credit card organizations, and organization of credit cards, consortium of credit cards, standards around data security, specifically referring to card holder data, like the name, the address, the actual credit card number, that little three or four digit code they make you enter, the expiration date, etc. And what Myrtle did is she found someone else to take care of getting credit card numbers for her. So, she kind of outsourced her risk to a third party, so people went to her store, they filled out their form, when they went to pay they were redirected to another website, they entered their payment information, and then they came back to Myrtle's site and got an order confirmation. So, she had nothing to worry about. Myrtle's shoe store was first launched on 2015, I'm sorry, November 15th, 2012, the site received around 3,000 orders per month, that's a lot of ribbons. And on March 11th of 2013, Myrtle noticed that the shoe store wasn't receiving any money into its account. She went online, placed an order, and everything seemed to work like it should. Myrtle was very confused. What was happening to the money? So, upon investigating, Myrtle noticed that the payment URL where people get redirected to when they enter their credit card information had been changed. It wasn't pointing to the right payment URL, it was pointing to somebody else's payment URL. And if we dig into the IP addresses a little bit, there was a post request on the page that's used to change this URL by someone at the company. Well, Myrtle is the only person at the company. She's the one shipping all the boxes, so it had to have been her, but she was very confused because she didn't change the URL. Someone had used a security vulnerability in UberCART and added JavaScript into a field that then ended up changing the URL. Normally, that JavaScript would have been escaped, but since the site did not get patched for security vulnerability in UberCART, the JavaScript executed. So, you know, drawing from that specific instance, in general, what is cross-site scripting? It is code that's inside of the browser. That instance was JavaScript, but it can technically be other kinds of code that's running inside of the browser. And it's making requests, so it's doing post requests in that specific instance, but there can be other kinds of requests and even multiple requests. The code can be doing multiple requests. It can then parse the responses because it's able to get full access to the HTML to whatever content is coming back from the site because it's running inside of that site. And, you know, as I said, it can be JavaScript, Flash, Java, even PDFs, you know, multiple different kinds of technologies have the ability to run script. So this may sound familiar to you because it's commonly referred to, you know, as a positive technology by, you know, being JavaScript or like headless Drupal is all about using the same kind of technology. The only difference is that when you're using it as a developer, you know, day-to-day your purposes, you're trying to make your features of your site better and richer for your customers. The attacker is using it to change data in a malicious way to affect the security of your site in some way. So if you're working with Drupal, you know, I say, you know, as we all are, right, the ways that I commonly test for cross-site scripting are to use basically these two little snippets and they're very basic JavaScript. The, you know, difference between them is that, you know, the work in different areas and I tend to put them in, you know, I use an alert because if you see an alert, it's hard to miss that fact. You know, it's just popping up inside of your browser and I put inside of it, you know, the word title, if I'm trying to inject it into a title field on a node or if I'm putting it into a body, I'll use the word body. And then as I'm browsing around the site, I'm looking for that pop-up to show up. If I see the word title inside of the alert, I'll use the title that I injected three pages ago, perhaps. And so that's really helpful. This will catch, you know, approximately 90%. This catches the majority of cross-site scripting issues in Drupal. If both of these scripts do not execute, you don't know that you're secure necessarily. There are some other forms, such as using iframes or other, you know, more advanced cross-site scripting attacks. But Drupal's filtering mechanisms will filter out all of those if you have them configured correctly, so what is the system that we use in Drupal for fixing cross-site scripting? We say that we should be filtering text when it's output to a browser and do it as late as is reasonable, right? So a lot of people have a reaction while I'm just going to block this before it gets input, but if your site needs to have some JavaScript inside of it in order for, like, Drupal.org has a lot of JavaScripts that's there for tutorials, for example, blocking it while it's input will mean that it can post that legitimate content. And so Drupal takes the stance of filtering it in a context-appropriate way as late as possible. There's also, you know, as I mentioned, the framework can provide benefits to us. So when you do a Drupal set title, the function Drupal set title and Drupal 7 will filter the text by default and just take care of it for you. So that's an example where the framework can really support us, and there's a couple of other examples like that. If you're, you know, writing some code, there is this handy-dandy cheat-cheat about how to filter that out, and that cheat-cheat is linked to an article that talks about it in more depth. So I encourage people who are writing code to follow up on that. So our second story. A site was getting a lot of spam reports and was getting blacklisted by some email, you know, email receiving hosts. They were in some different blacklists related to sending bad emails, and they were really confused by this. They saw their mail list, and they said, wow, this person really opted in. You know, why are we getting these reports? And they saw some of the emails that were getting bounced back to them, and they said, well, we didn't send this email. This email is just straight-up spam. This didn't come from us. So, you know, they looked through their log files and noticed a large number of requests going to one specific URL from a specific IP. And that made them looking to, okay, what's going on inside of that URL? This was a memorial page on the site where people could post comments to that memorial. And, you know, the comments were very simple. They just had an input text box where you could type your comment, and then the submit button, very straightforward. Well, they actually had a text format that was associated with that comment box. And the text format, you know, they said, oh, we don't really need text formats here, so we'll just hide this with CSS. But the CSS did not hide it from a bot, right? So the bot found the text formats that were available. And one of the text formats was the PHP filter from Drupal. And so the PHP filter had been configured, the permissions for it, had been configured to allow an anonymous user to post PHP code. So somebody found that. They turned off CSS, and they injected a little bit of PHP that would run basically whatever they wanted. And this particular attacker wanted to send a lot of spam emails. So, you know, there's a couple interesting things there, I think. But this is an example of Access Bypass that has an Access Bypass vulnerability that's been introduced through the configuration of the permissions on the site. Access Bypass is when somebody can see or do something that they shouldn't be able to, and, you know, that their permissions or that their access should be preventing. And I think what makes Access Bypass so tricky is that we enforce it in a lot of different places. So in that case, it was a permission, but it can also be about what nodes you're showing to somebody and whether that particular query for the nodes has the right tag on it in order to enforce the node access system. Whether you're using the node access function as you build up that list of content. So this is just sort of a really, really tricky thing to do in Drupal because it requires you to work on it at so many different layers of the system, potentially. So how do you test for Access Bypass? Basically, you know, my biggest recommendation is that any time you change the permissions page, which, you know, for me is very daunting, there's a lot of checkboxes there, and I'm always worried, like, am I clicking in the right column? Am I clicking on the right row? So whenever you make changes to the permissions page, always log in as a user that has all the different roles on your site and test out to make sure that they can and cannot do what they should be able to do. In terms of fixing it, there's a lot of different functions that you can use. One thing that I would recommend is to write automated tests. There will be sessions later on during the conference about automated tests, and, you know, it sounds, I think, a little daunting, but increasingly, automated tests using tools like BeHat is very straightforward to do, and it's a natural language way to write tests and very straightforward for basically anybody to do. And it's, I think, a great way to ensure that, you know, you don't have to go through the manual QA process of clicking around and ensuring that people do or don't see what they should. So we're going to go on to another story, and this one's a little different. This is about Harper's LLC, which is a small web development company in upstate New York, and Harper's just signed a brand new contract and was really excited to get started on the site, and they provisioned a brand new domain, and because they were still working on the site, they didn't want somebody to find it by mistake. They put the site maintenance mode. How many people have done this before? Okay. So the site was set up with a newly ordered domain name. The site's modules and core install were all up to date. The site only had one admin account, and the site was developed on a dedicated server just for Harper's LLC's customers. And the site got hacked. And that was strange, because no one really knew how it got hacked. It was brand new. It was just put online. And so if we dig into how it began on the third day of developing the site, the content manager was going to go in there and he set up the content types, which I'm sure we've all set up content types. And he stopped in horror on the front page because there was Viagra spam all over the front page. And he was really not a happy camper at this point. It was a brand new site, and now it's defaced with Viagra spam. So he called his in-house IT person, and they began looking through the logs together to try to figure out how the site actually got compromised. They pulled up the logs for the site and they found only known entrusted IP addresses that access the site. That is, only computers inside their office that access the site. So the IT person did what most IT people would do at this point. She assumed that the internal computers must have malware on them. So she ran a virus scan on those computers. The virus scan was clean. So she just restored from backup and sent the content manager back along. But two days later the site got compromised again. So what happened here actually has to do with their server configuration. It's not really part of Drupal, in that it's nothing you configure inside the Drupal interface. It's not inside of a settings.php file. But it's just as important to securing your Drupal instance to secure the components that host your Drupal instance. In this case, it was Apache. And what happened is this site was hosting multiple sites. Apache has access to read all the files on the file system that it hosts. And so someone had actually compromised another site on the server and using the site that they had compromised they looked through the file system and found all instances of settings.php and were able to connect to the Drupal database directly and then inject the spam by updating the table, the node table in this instance and the node revisions table and the field tables directly. And they did this for WordPress sites as well. So we don't have time to like talk about server configuration here. It's a long, complex session and there's gonna be lots of other sessions on it throughout this con and I suggest you go to them. You look like you're about to say something. Okay. So, you know, I would go and look at how your servers are configured but if you're hosting your own server and you've just installed like a Red Hat or a CentOS or an Ubuntu server and you've got multiple sites on it, they're probably vulnerable to this problem. There are some Drupal-specific hosting services out there and I don't want to name names here you can look around at some of the sponsors and see some of the names, you can go to some sessions you can do a Google search or you can click the link in these slides labeled Drupal-hosts and it'll take you to a list of hosts on Drupal.org but can your hosting provider help you improve your security process? Has your hosting provider, whoever they are, tuned their environment for Drupal specifically? Do they have a mechanism to do managed security updates for you? Can they help you with that? We'll get into security updates a little later on. So, let's change topics for a second. How many people brush your teeth? How many people brush their teeth this morning? How many people brush their teeth yesterday? How many people go to the dentist? So, it's pretty much all of you. Why? Why do you brush your teeth? Like, it takes like three minutes, maybe two or one if you're in a rush. Like, why do you brush your teeth? Brushing your teeth is a best practice. You brush your teeth because well, if you don't brush your teeth really bad things can happen. So, everyone gets up and they take the five minutes to brush their teeth because having to deal with getting your teeth infected, I'm not a dentist. Like, that's a lot more time. It's a lot more time consuming. It's painful. In this case it's literally painful even to look at. Security is a best practice. So, it's, I'm sorry, security is a process. It's not like a checklist that you just check off and you're done. It's like brushing your teeth. You've got to do a little of it every day. So, you should have a process surrounding your security. When you make changes on your site, you should be thinking through how are these changes that I'm making going to impact the security of my site. Oh, I found a really cool module that I'm going to install. Well, should I install the module? How many permissions is it going to add? What type of complexity does it require? You should have a budget for security. Budgeting in terms of money but also in terms of time. It's time consuming. But, in the end, it's worth it because you don't want your site to have a variation of that. You should also think through what your risk level is. So, if you're a blog, your blog is likely to be compromised for spam purposes. Someone doesn't really care about your blog itself. I'm sorry. They just don't. They want to use your blog to either send spam or host spam or do link referrals within Google for SEO. But if you're a complex site, you might be compromised because the data of a complex site has. So, if you're a bank or you're Amazon where you've got people's personal information, people aren't probably going to try to compromise you to send spam. They're going to compromise you to download your database. Security's a balance. So, each site needs to spend time working on security. Some sites may need to spend more time on it. And you should know if your site's a target based on the information it has. How many people recognize some of these abbreviations? YZ is probably not an abbreviation you're going to recognize. But there are certain laws that may be surrounding data you have. If you are collecting healthcare information, for example, if you're dealing with the federal government, then you have certain legal requirements that are going to be forced upon you that are going to change the security profile of your site and change some of the things you might have to do. If you happen to be in commerce, how many people are selling something on Drupal out of curiosity? So, you are likely responsible for PCI compliance in some way. We have a wonderful community written PCI compliance report. I don't know who would have written that or helped write it. It was a team effort. But one of the authors is up here that talks about how to get Drupal's PCI compliant and some of the steps involved in doing that. So, speaking of Drupal security, Drupal actually has a dedicated security team. We actually have our own dedicated security team that kind of helps keep Drupal secure. It helps keep Drupal going in the right direction as far as modules and core. So, what do we do? First of all, we educate the community on security best practices. That's what's happening here. We also write security advisories for every security release of a module or contrib. How many people know about the security advisories? How many people don't know? Yeah, how many people don't know? Let's do that one. Okay. So, we're going to find out more about that. So, I would suggest for those who don't know that you actually follow the Drupal security team. We have lots of ways for you to follow us. Greg mentioned our Twitter account that's Drupal security, no underscore, no space on Twitter. You can do it via email on your user profile. If you edit it and go to Newsletters, you can subscribe to the newsletter, which is emails on Wednesday. Or you can go on the web at the URLs provided. There's also RSS feeds on those pages if that's what you like. So, what does the security team do? Well, the primary visible thing that we do is if you find a security issue in Drupal, you report it to us. And we work with the author of that code to fix the security issue. We test to make sure the issue is fixed. And then we help release a security advisory and release the update in a coordinated release. And, of course, the number one easiest thing you can do to keep your site secure, the easiest step you can do is keep your site updated. That's the easiest step you can take. Just keep your site updated. We typically release security advisories and code on Wednesdays. You'll get emails on Wednesdays about them or tweets if that's how you're following. And keep your site updated. Alrighty. So, from a site builder perspective, the most common places that people make mistakes, I would say, you know, something that we all hear about passwords, right? Insecure passwords in particular, weak passwords, reusing passwords across multiple sites. That's one of the most common ways that people make mistakes. We didn't have a story about it today. We do have some stories, you know, that we've experienced that involve passwords. And it is a surprisingly common way that people get into a site. Also, sessions. So, if your site is not over HTTPS and you're, you know, using it on Wi-Fi that's not secure, sniffing sessions is, you know, a problem that people need to worry about. Next big one is roles and permissions. And I think it's a really easy way to introduce mistakes is just making, you know, one wrong checkbox can ruin a day, right? And then keeping, you know, broadly, more broadly, keeping the site settings secure. So, what are the text input formats that you've got configured and what are the tags that are available inside of that? You know, I think as you're going through the site, it's, you know, can be very easy. You're under pressure to get some new feature out, you know, your boss or your client is saying, oh, you know, we really need this feature. Could you just get out there and you're feeling frustrated and you just enable all of this stuff and it's like, oh, it works, great. I'm gonna, you know, close up for the day. And you never think about, well, did all those configurations I just did in the last hour of flailing, did that really like head towards a secure version of my site? It's super easy, you know, to introduce a security vulnerability or the potential problems that this might introduce. Permissions. Text formats, I talked about, you know, cross-site scripting via adding inappropriate tags there. The PHP module, I would say if you can, just turn it off and maybe even remove it from your site. You know, it's not so much that it itself creates a vulnerability, but if an attacker, you know, gets your username and password somehow, then they can use that as a leverage point to create further attacks on your site, on your infrastructure. And then PHP execution and other modules, you know, as you're evaluating the security of a new module you're thinking of adding to the site, if it allows you as an admin to execute PHP inside of it, it could also allow an attacker to do that. So you have to, you know, say, what are the tools that I'm giving to myself, what are the tools that I'm giving to somebody who might compromise my site? So we've got this list of modules. Every presentation has to have a lot of different modules, right? Here we go. You know, I would say I've listed them in what I consider to be priority order, basically. You know, security review, I encourage on every single site. It's really helpful in identifying those common mistakes I was just talking about and giving you warnings. It has Drush integration. You can set it up in an automated job, in a cron job to send you an email of the output. You can set it up to log the information into Watchdog. So if you're really on top of looking at your Watchdog reports, you can see it there. It's a very useful tool. Next one, paranoia. It's basically going back to that point that I was making about the PHP module and it says if somebody, you know, if you sort of assume that somebody will eventually break into your site, you want to make their next steps as hard as possible. And paranoia will help out with preventing the execution of PHP because what's available is the password strength module. So this is sort of based on the idea that I actually just saw a sticky note on somebody's computer that had their password and the password met most password policies. It was capital T, thunder, and then an exclamation point. That is not secure. And yet it meets, you know, Windows Active Directory rules. It meets PCI rules. It meets all of these really basic rules. What this tool does is it looks for dictionary words. It looks for repeating characters. It looks for, you know, ASDF one, two, three, four exclamation point. It looks for those kinds of common patterns that people use in passwords and it sort of throws those out as not actually being unique content. And so it judges password strength based on the entropy of data inside the password. It gives you more realistic perspective about just how secure that password is. Two-factor authentication. This is something that, you know, how many people have at least one site that they're using that's two-factor authentication? You can go add it to your Drupal site right now. You know, this is something that I think is a really awesome tool. We actually did a security bug bounty for this module that we gave out the username and password and said, hey, if you can break into the site, you get $500. And after two weeks and, you know, dozens of people and dozens of requests trying to break into the site, nobody was able to bypass that. Even though they had the username and the password, they couldn't break into the site. So two-factor authentication I think is a really brilliant technology, you know, that people should be adding at least for admins, if not for, you know, content creators and more users on your site. Permissions lock module. So I mentioned the idea of, like, one mistake with a checkbox and a permission screen. And permissions lock basically pushes you to manage your permissions via code rather than via the interface. Hacked module can be helpful to make sure that you haven't been hacked. It's not so good at preventing it, but can help you with the cleanup and identifying that there has been a problem. And then password policy, if you work in a regulatory environment that requires a specific policy, you know, you can use password policy and password strength together. This is a history constraint so that you can't reuse the same password for over a certain amount of time. So I think password policy is another good tool. Real quickly, so here is, you know, two-factor authentication. It's been recently deployed on Drupal.org for some of the advanced roles on that site. And the basic idea, yeah, yay for that. The idea is that, you know, when I log in to Drupal.org, you know, I have to enter in my username and password. Password is all dots, by the way, so I don't want to break into my account. And then it asked me for my six-digit verification code. And this is a new code that's generated every 60 seconds. And I can say, remember this browser, and it will do that for me for a certain amount of time. Very, very helpful tool for increasing security. Another one, this is the password strength module. This is how it shows up. So it's a slightly different user interface than the default Drupal password strength monitor. You may have noticed this. So Atlassian and Gira, I believe, base their UI on this. Dropbox has a UI based on this, so people are sort of increasingly experiencing a UI that looks like this. And it gives you some advice. It says, hey, this has a keyboard sequence in it, like the QWERTY ASDF. Then it also contains a dictionary word. Once you're in a good place, you know, that bar sort of progresses along and you can enforce it. So this is giving suggestions to people in real time as they're typing their password. The strength module also allows you to enforce it on the server side, so that when somebody then submits their password, if it's not good enough, it can be rejected. That's an optional thing up to you. There's the modules overview. Drupal 6 support. There's probably some people who are saying, I love my Drupal 6. Don't take it away from me. So historically, whenever there's a new release of Drupal, the version of Drupal that is two years old, it meets its end of life as the software industry says. It's no longer supported. With Drupal 6, there will be some extended support for three months after the Drupal 8.0.0 release. So, you know, three months, not a ton of time, but at least it's a little bit more time than what the Drupal project has done historically. There's also sort of, we've sort of thrown out this idea that if somebody wants to provide support for Drupal 6 beyond that, then they could sort of become a focal point for that effort. And the link there points that document about that. So, if you are interested in being the Drupal 6 maintainer for a long time and you're qualified to do that based on the qualifications list on that page, please do get in touch. I also want to, of course, talk about Drupal 8.0 security improvements, the new hotness, right? So one of those is TWIG, the templating tool for Drupal 8.0. It removes PHP from templates, it has some security benefits. There's also automatic sanitization of strings. So a lot of cross-excripting vulnerabilities seem to get introduced inside of the template engine, inside of the templates. And so we hope that Drupal 8.0 and TWIG will reduce the number of cross-excripting vulnerabilities that we see, which is, you know, currently the biggest one. Another area, not so much in contrib or not so much that we have advisories about from Drupal.org, but a place for people to make mistakes in configuring WYSIWYG. I think that in Drupal 7.0 and below it's really painful right now to get your text format configuration and your WYSIWYG configuration to do a slow dance to the same song. And that's what we all want. So, you know, people sort of say, oh, I'm just going to do full HTML and that'll be good enough for everybody. And in the process, introduce a cross-excripting vulnerability. Drupal 8.0 helps to keep those, you know, sort of working together and I think makes it a lot easier to figure right and so therefore they're less likely to just open up full HTML for everyone. I mentioned Drupal or I mentioned the PHP module and how it's, you know, sort of not a great idea. It's gone from Drupal 8.0, so that makes me happy, you know. And, you know, that is, I think, back to Michael. So, there's actually been a book written on how to hack Drupal and you can get this on Amazon.com right now if you'd like. It happens to be written by my friend here. And it's a good book that goes through the basis of how to do some of these attacks and how to protect against them. It's a more in-depth version of this presentation in book format so you can kind of follow along. Anybody have any questions? And if so, please use the mic over there. So just form a line behind the mic. We will take questions. I see this mad dash of hundreds of people running to the mic. Oh, no. Hi. I just created a new Drupal 7 site for the bankruptcy court for the Northern District of California. And as part of the security, when the administrative office has kind of tested the site, what we had to do is only allow, like, certain IP addresses through the server configuration so that the user page could not even come up for anybody else that didn't have that IP. Well, that's working fine, but what we would like to do is be able to have in the future log-ons for attorneys who are not within our VPN or within the court. Is there any way to do that and still keep the level of security that we have? I mean, I think that it's an interesting idea to lock down sections of your site based on IP, and it's a strategy that I've definitely heard of different Drupal sites doing that. There's... I was just trying to find the name of it. There's a Drupal module called something like Halbergion, which is a medieval word for chain mail. I don't know. Not the friendliest name, but it's based on that idea of limiting certain paths to an IP level, to IP addresses or address ranges. I think that probably what you're doing now is more at the web server level, and if you were to pull it into Drupal, then that might make it easier to configure to meet the set of rules that you want. If remote lawyers should be allowed to use the user page and three or four other admin-ish pages, it might allow you to do that. But otherwise, I feel like it's just a process of going through, figuring out what things they should or shouldn't be able to access, and then making really specific rules in your web server or wherever you're putting those rules that allow them to do that. Okay, thanks. This is in response to your XSS in the early introductory remarks. There's actually a sandbox module. Probably you've heard of it, being able to produce this automatically for you. It was created by Matthew Pa... If he's in the room, I'm going to butcher his last name. Potamaya or something. But he's also one of the other Git admins. We use it in the core or in the Git vetting process to validate whether or not a module is XSS vulnerable. I've personally found the date module with it. And those have all gone through and released so it's perfectly fun to talk about now. But it's a really great module to find and hack your own code and only enable it, I guess. Only enable it in a dev site, not in production. So yeah, I think Matthew Donadio, I think he's not here unfortunately, but yeah, definitely a great module. I'm just curious, have you ever seen a legitimate use for the PHP input filter? And... Define legitimate use. One that was absolutely necessary. I'm just curious. Maybe also advice for people who have that. Ways to migrate away from it. Sure. I think that the... I think that the... I think that the... I think that the... I mean... I use the PHP module, right? I think that it's a great tool. I used it in the past. I think that it's a great tool to make that step from, okay, I'm pointing and clicking to build a Drupal site. I need to write a little bit of code. This little input box is, it feels familiar to me and I can put some code in there. So the PHP module I think is a great tool. But then when I wrote my first module, I was like, that's it. It was shrouded behind mystery for me and when I made that jump across into the module, it was like, oh, that was a lot easier than I thought it would be. I think that there is a role for the PHP module to some extent. It does live on and contrib and if you're in love with it, you can download it for Drupal 8. That's fine. Something like that. I think that the answer is that there's basically no place where the PHP module is the only way to do something. There's almost always an altar hook or you can do something in a template or a preprocessed function or somewhere. It's often easier to do it in a PHP module or use PHP field or something like that. It can be easier or faster to get it done that way, but there's always another way to do it. There's no place in Dev, not in Prott. It's basically how I would sum that up. It's great for potentially quickly tweaking this and then when it's time to actually, you know, okay, it works, now we're going to turn that into a module. Same place as the DevL module. DevL module has a place in Dev, not in Prott. Hi. I'm fairly new to coding. I'm a career changer and went to a boot camp and just landed my first Dev job at an awesome company. So I'm new to this. I don't quite know the jargon. I'm still figuring things out. What advice do you have for someone who is so green like I am to, you know, who's suffering a little bit from decision fatigue because there are so many resources out there? How do I focus my energy on learning good, you know, best practices for Drupal in a way that will make sense? So the last slide we have is a resources slide which talks about a book that's available that covers kind of the definitive guide to Drupal 7. It covers some of the secure team stuff. It also has links to how to write secure code and how to secure your site. How to secure your site is kind of geared towards site builders. How to write secure code is geared towards people writing code. Hi, I have a question about locking down a Drupal website having two different MySQL users, one with read-only access and one write. Is there what's the security benefit to that and what sort of protection can you gain there? Yeah, I think that's the idea of creating multiple MySQL accounts that have different permissions on different tables. It's an interesting one that particularly in light of SQL injection this past fall, people have been more interested in. There's one of the resources is groups.drupal.org slash security. You can log in there and join that group and then you'll get notifications about content inside of that group. And one of the recent posts, maybe a month or two ago was somebody who had gone through that process to try to figure out what's the sort of bare set of MySQL permissions that are access that's necessary for a Drupal site to run in kind of a read-only mode from the public and then there would be a separate set of credentials that admins log into on like a private VPN that allows write access into the content and everything else. And I think that they even developed a bit of a script in order to create all of the grant statements that are necessary for enacting that kind of a system. So I would encourage you to check that out. It's groups.drupal.org slash security. I've definitely heard about people using that kind of system and it seems to work well for them. It just depends upon how much interactivity you need from the broader public. There's also going to be a bof so it's focused on the security team and the security advisory process. So if you have thoughts about how we can improve that then we're very interested in that. It is at the same time where it's starting at noon today. So, you know, grab your lunch quickly and then it's in room 401 which is upstairs. Upstairs and that way. Yeah. So going back to your reference about where Apache was compromised and they were able to access settings.php and get access to MySQL database is there a way to secure the password which is on the settings.php by encrypting that? Something that I haven't been able to find so far so maybe if you guys know. The issue is the web server needs to be able to read the password. So you can do things to obscure the password but in the end the web server needs to be able to decrypt that password to make the connection to MySQL. So if your attacker has found a way to read settings.php through the web server it's probably too late to do something from that perspective. What you can do though is find ways to protect settings.php itself. So make sure that it's not it doesn't have unix permissions of 777 it should be limited to just the user needs access to it. Make sure that other sites on that server are protected from hitting settings.php So if you compromise one site you can't find settings.php another one you might be able to find it but you can't read the file. So that worst case scenario if one site is compromised it doesn't let your entire server get compromised. Which was kind of what happened in that story. Thanks. Just one more point on that. The security review module has a check that will look for no it doesn't. It looks for execution of PHP files. Pardon me. It doesn't look for that specific kind of issue. But it helps with some of that file settings permission stuff. But that might be done by Friday. So this might be related to that last question or at least the topic. What kind of limitations do we have as far as what passwords we can use like upside down text or special HTML code characters. Things like that. What kind of limitations do we have? I'm new at all this. I really know the answer. I think that it depends a bit on your MySQL table collation probably. So I would say try it and see. Yeah. It's going to get hashed before it gets written. I don't think it's going to. Yeah. That's a good question. Maybe it's the PHP language stuff? I don't know. Yeah. I saw in the synopsis for this something about can Drupal protect against denial of service attacks. I was curious what you had on that topic. Yeah. So there was actually a great presentation by David Stoline about denial of service at I think the Drupal a year ago. So the slides for that are online. Mostly we talked mostly about Drupal today because for a couple of reasons but solutions for denial of service are generally not Drupal specific. Drupal specific denial of service issues are usually more complex to attack than server level denial of service issues. And so most of the attacks that I've heard of that were denial of service were focused on Apache or flooding the network, things like that rather than something Drupal specific. And so I think that the ways to protect against that are the same ways that you would do it if it were any other kind of a site regardless. It doesn't matter so much at that point if you're getting a slow lower or a network flood the solutions are at a lower level usually. Hi. Hi. Yeah, I help run a multi-site at Cal Poly San Luis Obispo so we have about 200 websites under it. And one of the things that questions I keep getting is to allow more permissions for the site owners so more access to the site. So one of the examples is requested that I give admin role access to somebody like in our health center or something like that so they can do whatever they want on site. I lobby against that. I say I don't think that's a good idea because it's going to give them access. So could you elaborate on the potential security risks of giving them admin access to allow them to set their own filters and all that stuff? So I think there's two issues. Multi-site because of the issue with Apache is a security issue. If you're running different multi-sites, Greg may disagree, but if you're running different multi-sites with different site owners one of those sites get compromised they're able to compromise all the other sites pretty quickly because it's a shared code base. So the first thing you may want to do is do separate Drupal installs for each which of course then you've got to deal with different updates when you need to update modules you're doing it across multiple sites. But if you, given the fact that it's a multi-site install, if one user enabled the PHP filter and made that available to anonymous users that could then be used to target all the other sites on the system as well as the site they enable to go on. Same with cross-site scripting. They could make small configuration changes in there that could break their site and then it probably comes back to an IT organization to then clean up after what was done. At the University of Michigan we've run into this, we've run into similar issues there and we've got two different competing schools of thought. One is there's an organization that gives content privileges out but that's about where the level of access stops and then anything that requires more access goes through an organization that has familiarity with what the consequences are to enabling certain features or disabling certain features. Yeah I would say that, as we've said keeping your site up to date is one of the most important things and so multi-site often helps you to do that so it's sort of, you have to know your trade-offs basically. There is going to be a BOF later this week I saw just a brief mention of it at Ultimate Boy, Matt Tucker works at CU Boulder and they have a lot of Drupal sites and so they're dealing with this question of how do you manage in a scalable way hundreds of Drupal sites so that could be some good solutions there. I agree with Michael that it's very hard to get configuration of multi-site in a way that is secure for everybody and so breaking it apart can be a good solution. Containers I think are increasing the solution that people are looking to because it provides that segmentation but it's a back and forth how do you keep everything up to date give everybody the permissions that they want and satisfy your client's needs. Good thanks you guys. Alrighty Well I think Michael and I will still be here for questions or discussion if anybody wants and other than that it's nearly lunchtime and then there's the BOF at noon if you're interested. Thanks very much everyone.