Training: Best Practices for Drupal Security [April 30, 2014]
Want to learn more about Acquia’s products, services, and happenings in the Drupal Community? Visit our site: http://bit.ly/yLaHO5.
Join Ben Jeavons, Cash William and David Stoline for an up-to-date review of security best practices in Drupal. Drupal is a powerful tool but it can be built, configured, and managed insecurely, far too easily. You can use three basic principles to guide your efforts around securing your site and processes:
• Don’t trust user input
• Stay up-to-date
• Defense in depth
Security is a process, not a one-time action, so it is important to have a practical plan and guiding philosophy that will ensure you cover your bases.
In this webinar you will learn:
• How to evaluate user permissions and trust in the context of site security
• Common security risks on the web
• Tips and good processes for staying up-to-date
• How to practice limit security exposure and plan for the worst
Moderator: Today’s webinar: the Training Session on Best Practices for Drupal Security. I have my colleague, Ben Jeavons, on the line who is a Senior Software Engineer here at Acquia, Cash Williams who’s a Technical Consultant, and David Stoline who’s also a Technical Consultant. Thanks so much for taking time out of your day today to present to us.
Ben Jeavons: Thanks everybody for joining us today. Today we want to talk about Drupal Security. There are three sort of main categories that we’re going to be covering. Obviously Drupal and security are very large topics and we can only get into so much today. So we’re going to outline some of the vulnerabilities and risks that are popular and common on Drupal sites. As well as delving into understanding user input and how most attacks get started. Specifically we’ll talk about permissions and roles of Drupal sites and how you can evaluate the trust model of your Drupal site. We’ll also go into further tips and best practices regarding security by talking about backups, logs and strategies for managing quick deployments and staying up-to-date with your Drupal site.
What we hope to be some of the main goals that you get out of the training today are these three ideas. We’re going to talk a lot about user input and trust and the idea of that being the main risk on the web and the source for a lot of the vulnerabilities that occur. We’ll also talk about just this idea of staying up-to-date, how important that is for Drupal and for the rest of the software you’re running on your site. As part of all of these is this idea of defense in depth. In a sense building a castle-like structure where different strategies maintain security from first build of the site through ongoing maintenance.
Security is obviously very important and in lots of cases, it’s becoming even more so. So in the last year a data breach investigation study talked about how the importance of these cyber-attacks are very important for small businesses. So in this case 71% of the data breaches, as found in this study, occurred for businesses with less than 100 employees. This is something that not only affects small businesses but obviously large organizations and businesses. So a recent data breach at Target affected roughly 40 million debit and credit users that have purchased from Target. So this affects not only the small organizations but large organizations as well. As well as even affecting at a small level the software that they’re specifically running. The Heartbleed incident from last month was a huge vulnerability that affected roughly 66% of the internet due to a vulnerability that infested in the OpenSSL library used on a large amount of sites. So while it can affect individual businesses in the way that they’re affecting – they are going about their business goals, it also affects larger, very specific things and the applications being used on the internet. So the Heartbleed incident for instance might have allowed somebody to attack the actual encryption used when you communicate, for instance, with your bank or with your Drupal e-commerce site and the like.
As I said, we can only get into so much on this topic today. The good news is that DrupalCon Austin, we’re offering a full day, hands-on training as part of the DrupalCon Austin schedule of events. So on Monday, June 2nd we’ll do a full deep dive into the different vulnerabilities that we’ll just sort of talk about today. Vulnerabilities like cross-site scripting, SQL injection and access bypass. If you register before May 2nd this week, you can take $75.00 off the cost of the training. The profits on the training are split with the Drupal Association. So along with educating your site developers and builders and themers, you’re also helping to support the Drupal Association. You can find more about this training on the DrupalCon Austin site.
Let’s get started talking about some of the vulnerabilities and risks that exist on Drupal and in the web in general. So some of the data that we’re going to be showing has been compiled as part of a report on the state of Drupal Security. So what this report did was analyze the security advisories that are published by the Drupal Security Team. These security advisories highlight a bunch of the vulnerabilities that have been found in Drupal Core and stable contributed modules and themes on Drupal.org. So what this chart is showing right here is popularity of vulnerabilities. I won’t explain each individual vulnerability in detail but you can see that this classification of vulnerability, XSS or cross-site scripting, is one of the most popular vulnerabilities found in Drupal code. That is code that’s been published to Drupal.org. This gives us a sense that cross-site scripting as well as access bypass, cross-site request forgery, that’s the CSRF, are very popular vulnerabilities that exist in Drupal code. When we further differentiate these vulnerabilities by Drupal Core and contributed projects, those contributed projects such as modules and themes, we can see that again cross-site scripting is very popular but is more popular in contributed projects than in Drupal Core. Drupal Core just being the main download of the actual Drupal Project has had a lot of eyes that have reviewed that code. So it’s something that vulnerabilities have been discovered before this code has been published and that doesn’t require as much security fixes. Contributed modules though, there’s a wide variety of them. There’s tens of thousands of contributed modules and themes available on Drupal.org. Of those stable releases such as those not being developed or into beta release, there have been a lot of vulnerabilities found. That’s just a matter of having less eyes on that code. As we know from the Heartbleed incident, even heavily used code can still have vulnerabilities but it’s a fact of the matter that having eyes on the code does result in more secure, better written code. We see this when we look at Drupal sites, actual Drupal installations that have been built by customers and are in use on the web. When reviewed by any sort of security auditor, so for instance WhiteHat Security team did a review. Acquia provides a service for reviewing Drupal sites. We find that most vulnerabilities are just in either the custom code that the site is running whether those are the modules or themes or actually in the configuration or practices in running that Drupal site. Oftentimes sometimes sites are also running out-of-date code. So those vulnerabilities that we saw just a moment ago, things like cross-site scripting and access bypass, those do exist. They exist most often, though, in custom code or as a result of insecure configuration.
So we’ll talk about some of the ways that you can configure securely and processes for maintaining up-to-date code and being sure that you’re not running a vulnerable or insecure modules and sites. I should note that, outside of Drupal, cross-site scripting is a very common vulnerability as well. So it’s not just within Drupal. It’s in a larger web state that cross-site scripting is such an issue. This stat from WhiteHat Security is from their website security statistics report, found that 66% likeliness that a website is vulnerable to cross-site scripting.
Let’s talk a little bit about what is at the heart of cross-site scripting and a lot of these other vulnerabilities. It’s all about the way that user input is used. So we’re going to say that user input is the root of all evil in the sense that a malicious user can manipulate the way that they provide data into a system to carry out some sort of attack whether that’s a cross-site scripting or other form of attack. So when thinking about user input, what does that mean in regards with Drupal? Lots of times that’s any place where a user can submit information. So for instance what pages have forms on your Drupal site? Whether these are places where a user can submit a piece of content like a blog post or maybe they can add a comment to existing pieces. Or maybe also they can submit some sort of web form entering in feedback or perhaps entering data as part of a shopping cart, e-commerce experience. These are all standard examples of user inputs on any site as well as nodes and comments particular to Drupal. There are lots of other properties the way that a user interacts with a website that allows them to submit information, that could be a part of the HTTP request such as a depth request of the parameters in the URL that they’re requesting or actually parts of the HTTP header information that’s being sent along as part of the request. Those are all used by the system to do certain things. If a malicious user passes along dangerous data, they might actually change something about the system and carry out some form of an attack.
So in a sense, this picture demonstrates what is happening clockwise when a user is interacting with a Drupal site. This is a standard Drupal installation site. We’ve got a user on the left using a browser, submitting information into Drupal at point one. Perhaps they’re adding a comment on a blog post or adding something to a shopping cart. That information is used by Drupal, stored in a database at point two. Then perhaps that user is wanting to see their comment posted or see that item in their shopping cart. So when Drupal renders that page back to them, it pulls out data out of the database in point three and renders that back at point four to the user so that it’s viewable in their web browser. So when we talk about user input we are referring to that point where a data is coming in at point one. Then different parts of the system need to make sure that it’s not being manipulated or insecurely used such as to open up a type of attack. To get into more detail on that, I’m going to pass it off to David to talk about the ideas of trust.
David Stoline: Thanks Ben. So who can you really trust? When I audit websites I see a lot of situations where maybe it’s just a simple intranet or maybe it’s an internal website where trust has been given kind of overtly to just anyone. Trust is really the, I guess, essence of web security and defense in depth. Trusting user input, it’s definitely not a good idea. So we get to – just make sure that when you’re making your Drupal site, you do audits of your roles and permissions so this makes sure that your users aren’t able to go out and do dangerous and malicious or potentially malicious things. Keeping your modules installed at a minimum. Modules definitely increase the surface area of your site leading to a potential - things can get missed, new permissions get added. Just even enforcing strong passwords everyone may have their quick ABC123 password but making sure that user doesn’t have access to very important things or even that user might be an admin. It’s just ensuring that these things are safe and secure. So this really brings up the principle of least privilege. Giving users the ability and access to do exactly what they’re required to do. So on some sites, that just might mean logging in to your e-commerce site, adding something to your cart and purchasing, on other sites that might mean no access for an authenticated user. On some other sites it might mean your administrators have access to do everything but in a very specific and controlled way that you’re able to basically audit and keep an eye on so that they’re – you can ensure that they’re only allowed to do what you actually want them to do.
Here are a couple of examples of kind of the core, very important and kind of risky permissions to give to your general users. So this is obviously administering permissions, administering users, administering filters. So filters are how Drupal will output text in a sanitized manner to the web. So those are definitely a place to watch out for. There’s also the content type permissions and site configuration but there’s also several contributed modules that just about every Drupal site has installed. So that’s Views, that’s CTools, and inside of those there are some rather important permissions to kind of keep yourself informed of and be aware of and kind of monitor those things on an ongoing basis. The kind of final tenant of trust is ensuring people have strong passwords. It says administrators here but I really think it’s people in general. Administrators obviously have more access to do anything to the website but more often when attacks do happen, they happen because a malicious user is finding one vulnerability and then using several other vulnerabilities to either do something or do something more malicious by getting further access to the websites through bad passwords or what have you. You can look to breaches on say, Adobe or Sony or even on Drupal.org to kind of exacerbate that issue.
So let’s talk about best practices and what we can do. Kind of the most important thing you can do is just stay informed. Drupal.org has pretty advanced policies for dealing with security releases. Generally that’s every Wednesday. Actually Ben, Cash, and I are all on the security team so we are kept abreast and involved in these issues and work to get the schedules out or the releases out. Your install of Drupal has a built-in check for updates. So if your site is regularly checking for updates and configured properly to check for updates, you’ll see that your modules are out-of-date or there has been a security release. It should stay on top of those and make that a regular part of your release cycle. There are two Twitter accounts. So you can follow @drupalcore and @drupalsecurity to follow release announcements. There’s also a mailing list that you can subscribe to that will send out the same security advisories that you’ll see on @drupalsecurity. When these releases do come out, it’s really important that they be applied to your site and tested in a manner that fits with your organization’s workflow.
So the update process, what does that look like? At Acquia we provide three tiers of protection basically for testing changes to your site. So when an update comes out, you don’t have to just go and directly apply it to your production site and kind of hope that it doesn’t break everything or I’m sure that your change control process people are not going to look forward to having some downtime on your site. So we suggest definitely running updates in Dev or Stage and then vetting them and then applying them to your Production Tier. Drupal makes this really easy to do through Drush. If you’re not familiar with Drush, please Google it. It’ll save you a ton of time. So once you’ve committed your changes with version control system and hopefully you are using version control system, you are able to run updates then you can do your vetting and testing and really quickly and easily deploy it with your version control system and with that I’m going to hand it over to Cash.
Cash Williams: Awesome, thanks guys. So we’re going to shift gears ever so slightly here and kind of talk about maybe not as Drupal specific but just best practices in general. This is probably I assume where a lot of people’s eyes would be rolling, right. We all know we need to make backups. However, backups is just the first step. David and I are both security consultants and we work with customers quite a bit. So a lot of what I’m going to talk about is driven from actually seeing customers run into these problems firsthand. So I think this is a quote and if it is, I don’t know where it came from but I use it often. Not just with respect to backups but with anything really but if it isn’t tested then it doesn’t work. So it’s one thing to say, “Yes, we make backups. We have daily backups.” It’s another thing to say, “We actually know how those backups work. We know that they do work and the process of restoring a backup is easy.” So if we go back to say the Target incident, a data breach isn’t necessarily the type of attack that we’re talking about here. This is more if someone deletes your database through a SQL injection or defaces your website, how quickly can you get that problem corrected? So backups can kind of be our “Get out of jail free” card in this case, right? In order to use this as our “Get out of jail free” card we have to ensure that the process end to end is both tested and documented.
So a question that I’d like to ask clients is, how complicated is the process of restoring a database? It’s a multi-step process that has a lot of moving parts and a real world of it happens where, let’s say that your website is defaced and you’re under pressure or multiple people are moving quickly to try and get the website back up. It’s easy to make mistakes, right? So if possible, it’s best to automate as many things as you can. If running your restore is a simple click of a button versus some 10-step process, it’s going to be much more successful. The next question is: is everything documented? If Bob is you DBA and he knows how to do a restore right off the top of his head, what happens when he goes on vacation? You have to make sure that anyone that may be filling in for a position can easily step in, find the documentation as needed, performs a backup and know which backup to restore and how to do the process. Another thing that I run into a lot of times is there can be some technical barriers to performing this. So if someone knows how to perform the process but doesn’t actually have the account or the credentials to do so or can’t find the log in, can’t get access to the backups if they could, all these things have to be fully documented and have a plan in place to be able to perform this. Then just going back to the testing nature of it, this should really be tested regularly. I think it came out a couple of years ago, Netflix shared with us that they have a process running in their data centers called, I believe Chaos Monkey. What Chaos Monkey does is runs around on their data centers and breaks things on purpose, right? So if anybody is developing any piece of a system, they know that Chaos Monkey could break it at any point. This kind of holds developers and system administrators accountable to know that all their systems have to be tested.
So another common way to refer to this is a fire drill. So it’s important to run a fire drill every now and then and actually test to restore. See what it looks like. Then to the next point is how long can this take and the only way to know is by testing it. If your site is defaced and a manager walks in and says, “How long is it going to take to get this back up?” It’d be great to have a very specific answer and say, “In 15 minutes, the site will be restored and we’ll be back where we were yesterday morning. The other piece of this is logs. Again, going back to kind of what I’ve seen firsthand, a lot of sites actually don’t have logging enabled because at one point someone declared that it may be a performance impact if the site’s logging too many things. So maybe they unchecked the database log that comes in Drupal but forgot to enable the system log that comes with Drupal or they just turned them off completely because production ran faster without them. So without logs you can actually get access and see what your system was doing at any given time. The other issue is a lot of times a site will have a lot of warnings. If this is because it’s either developed poorly or misconfigured to be a little too verbose in the logs. There’s actually so much noise in the logs that it’s not very useful. If something does happen or even if you’re just trying to debug something and the process looks like – well let me go manually find the logs from two days ago and download an 80 Megabyte zip file and then I’ll need to map out all of these warnings so that I can even see what I’m looking at. Now I can try to find the timestamps for – this is already just way too busy and it’s not very effective. So it’s important to fix all of the errors and warnings and make sure that your logs contain what you need to know and only what you need to know. A good way to do this too is aggregating used systems. If you have multiple web servers, it doesn’t make sense for each of them to have their own log. They should be aggregated across all the web servers so that you can really see what an attack looks like from a whole against your site not just specific servers.
So hopefully this kind of rings a bell in some people’s mind especially in America. I don’t know what our demographic of the audience looks like but there’s a public service announcement that used to go out at 10:00 PM and it said, “It’s 10:00 PM, do you know where your children are?” I found it kind of laughable that we think we need a TV or public service announcement to remind us to look for our children but I have to figure that they did it for a reason. So in this case, “It’s 10:00 PM, do you know where your data is” or are for the mean there? The reason I ask is sensitive data can be littered across your system both in the code and in the database. So it’s important to track and know where all of it lives. So again, back to questions I like to ask clients is: do you have a list? Do you know where all of your data is? You should ensure that it’s not in the repo, right because a lot of people say, “Okay. Well our repo is hosted on GitHub. It’s a private repo. It’s protected. We feel like it’s safe to store sensitive data there.” Examples of this could be AP ITs, system settings, usernames, and passwords. So the problem here is if a year from now, you bring on and hire a consultant such as myself to come and audit your site and you just hand over repo access. So there could be the chance that your repo has hard coded AP ITs. It could also be the chance that you realize this and sort of remove them but are they still in the history? If I did a checkout and backed up to three years ago would I find valid sensitive data that’s still in there? I’ve heard of a couple of used cases where this happened where, I think it was something like a test needed to log in as user number one or the administrative user. The username and password was hard coded into the test and it was available in the repo. The other side of this is what’s not in the repo will be put in the database. It’s very important that all non-production systems be sanitized. Typically non-productions like Dev and Stage are held to a much less security standard because they’re not production, right? As well as - well you know, something a lot of people think about is developers’ laptops. The typical onsite, onboarding process for a consultant is you get access to the repo, you download that and then you get a copy of the databases and you can spin the site up locally. More than once I’ve looked through my local database and realized that I had some very sensitive client data that A, I don’t want to have and B, the client probably doesn’t want me to have. So there are things to think about is if I chose to be malicious and leak this data or if I didn’t do a proper job of securing my own personal laptop or let’s say that it got stolen at the airport, what does that mean to the client as far as where their sensitive data goes. So another thing I like to say is what if I leaked your production database today? How big of a deal would that be? One of the ways to protect against this is encryption. So if anything is in production that you don’t want to be known public, you should encrypt it. Drupal offers a couple of different contrib modules to encrypt data fields, user input and these kinds of things. So when we look at this as a whole this means that we could encrypt the data but the AP IT should not be in the repo, nor should it be on the database. So you have to think of these things as multiple levels and this comes back to the defense in depth that we’ve kind of touched on earlier but it’s just the whole picture of where all your data is and where it lives.
So thereabout wraps it up for this just to kind of recover the principles that we’re kind of touching on today. Don’t trust user input and think of user input can be anything coming from the user not just a simple field or form they can fill in. How to stay up-to-date? It’s important to stay up-to-date. The different ways that Drupal offers, users to know what’s going on. What the contrib and course space as well as defense in depth and best practices to keep up with those. So here’s just a few links and resources, if you want to look into and do more research on them. Ben mentioned the Drupal Security Report and that’s at drupalsecurityreport.com. Drupal.org has quite a few resources available and here’s just a few: drupal.org/developing/best-practices specifically calls out best practices when you’re creating custom code, drupal.org/security/secure-configuration calls out best practices when you’re configuring and site-building your site and again, drupal.org/writing-secure-code is another reference for how to write secure code when you’re creating modules.
Just to kind of set a reminder, the three of us will be providing hands-on training at DrupalCon in I think about a month, June 2nd. If you register by May 2nd which is, I believe this Friday, I don’t know my dates very well. You can save $75.00. Great, thanks. Our contact information is up here and I think I’ll hand it back to Hanna. So we can open up for some questions.
Moderator: Awesome. I know you had some questions come in. So we can start taking those now. If you have any additional questions, please ask them in the Q&A section. [Pause] The first question is when these updates come out, I never know what to test to check for things that might have been broken by an update. Can these sort of suggestions be added to bug reports?
Ben Jeavons: Thanks for that question. So when security updates are put out for Drupal Core or contributed modules, yes they often point out to specific vulnerabilities but it’s not clear exactly where those vulnerabilities happen and what effects that those vulnerabilities might have on your site. So could that information be added to the bug report is the question. That information can be added to some extent but it often really depends on how your website is built to decide like in which cases that vulnerability might apply or that vulnerability might be exploitable. So for something like Drupal Core oftentimes that functionality that might have a security issue is pretty common place. So that might be, for instance file uploads there that previously were not there in a Drupal Security Core release. There is an issue where file uploads could be exploited depending on certain I think Apache versions. So if you didn’t have file uploads, you’re probably not vulnerable to that attack. In cases of the security advisories for contributed modules, it gets a lot more difficult to recommend very specific ways or very specific things that you need to do to check. So my recommendation, at least to start for now, is to think about what are the main goals of your site. What are the business goals of your site and to document those goals and specifically how those goals are accomplishable on your Drupal site? So for instance if you have an e-commerce site, obviously you would like to make sales possible. You would like to allow user to purchase products and complete a successful transaction. So you might document that process and then when a security update for Drupal Commerce or for Drupal Core or other modules involved in that process come out, you can just step through that process, your goal and make sure that it’s still achievable. Furthermore, you can then adapt that into an actual automated test through things like Selenium or other forms of automated behavioral testing and then as for just the general idea of can it be added to bug report? It can, yes but that would be a process that I’d recommend going through the Drupal.org web masters process for getting that potentially added to security report. Thank you.
Moderator: Awesome. The next question is, what is Acquia’s recommendation for PHP version for Drupal 7? Drupal.org currently recommends PHP 5.3. However, it’s reaching the end of life and security fixes will end in July 2014.
Ben Jeavons: Sure. Thank you for that question. So I think as offering this forward, there’ll be some continued support for the current supported versions of Drupal so for instance PHP 5.2. So our recommendation going forward is to stay with the supported versions of PHP, so for instance 5.3, 5.4 and beyond.
Moderator: Awesome, alright. The next question is, are there any recommended automated tools to parse accounts newly created also that can parse from non-strong?
David Stoline: Yes, there are a couple of great modules for doing exactly that kind of thing. So on automated tools to parse new accounts. So my first thought there is the Mollom module. What that does is it’ll check the text that a user enters for kind of known spam vectors and can either deny that account being created or put it into a moderation queue. On the parsing for non-strong passwords, there are several modules actually and we recommend the Password Policy module which allows an administrator to basically configure length requirements and special character requirements and even history requirements around what passwords get configured by the users. So you can’t just go in and put like asdf or password or qwerty or kind of any of those low value, weak passwords.
Moderator: Awesome. The next question is, can passwords be moved to a separate database from the main Drupal database?
Cash Williams: I don’t know if Ben or David know of a way to do it specifically for Drupal but Drupal accounts can definitely be created and stored in other places. A lot of Enterprise clients have LDAP servers or active directory servers that are set up and so the passwords are stored there. More social media facing sites actually use external authentication either through Janrain or directly through things like Facebook Connect or Google Authenticator. So in these cases the passwords aren’t even ever in Drupal.
Ben Jeavons: I would follow that up just by asking if under what conditions would you want to move the passwords out of Drupal because instead of separating that, you could just further increase the security of the encryption of those passwords. That’s part of this idea of defense in depth. So with Drupal 7 passwords are repeatedly hashed and stored much more secure than in Drupal 6. Going forward you can actually change the encryption mechanism and also some of the other details around the way the passwords are still unencrypted which certainly allows for that risk if something like a database was extracted from your Drupal site.
Moderator: Great. The next question is, are you aware of a module to provide Drupal’s install with two factor authentication?
Cash Williams: Ben, do you want to take that one?
Ben Jeavons: Sure, thanks Cash. So very recently I did work on a new two factor authentication module which aims to support a variety of different two factor authentication mechanisms. So for a while there have been some Drupal modules that provide very specific two factor authentication support, such as support with Google Authenticator which is a two factor authentication service very similar to Duo. So those all exist currently as individual features. Now there is a TFA module which works to fully support Drupal authentication and is well tested and will support individual plug-ins for those variety of services such as SMS delivery for instance or a TOTP type code like Google Authenticator and that’s on drupal.org/project/TFA. Thank you.
Moderator: Awesome. The next question is, do you have any examples of contributed modules that facilitate encryption?
David Stoline: There are two primary sort of leading modules. The AES modules, it’s specifically allows for using AES encryption. As well as the Encrypt module which is more of a plug-in style and allows for a couple of different options. I publicly put the link there. It’s kind of obscure but it’s on drupal.org. There is a comparison of the two modules. I can post it in the primary chat as well.
Moderator: Awesome. The next question is, is it secure to use Pressflow instead of Drupal Core?
David Stoline: So for those of you who don’t know what Pressflow is, Pressflow is a Drupal 6 – I think it’s a spoon not a fork. So it’s a very focused distribution of Drupal that is really around performance and scalability for Drupal 6. So on the security of Drupal Pressflow, really it is secure. It doesn’t have a formal process that drupal.org has around security releases. So there is a little lag time between when a Drupal 6 security release happens and when Pressflow will pick it up I’ve noticed in my experience. So that is maybe a thing to be careful with is just when a core release comes out maybe attempt to patch core yourself. So patching your Pressflow installation yourself or even providing a patch that the community can use and vet on the Pressflow’s GitHub page would definitely be helpful.
Moderator: Great. The last question is any significant improvements to the security environment in Drupal 8?
Ben Jeavons: Yes, great question. So some of the improvements that I can think of off the top of my head, one of the biggest ones is the PHP Input Format module. That’s been removed. So in Drupal 6, actually prior to Drupal 8, all versions of Drupal shipped with a module that actually allowed the execution only under certain configuration of PHP code through the Drupal user interface which certainly is a security risk. The reason that they did existing prior versions of Drupal was just that there were cases where in the development stages that that was beneficial at times but that’s now been removed from Drupal Core. That’s a great one and a secondary one, a security improvement in Drupal 8 is there is now cross-site request forgery token support actually built-in to the Drupal menu system. So while we didn’t dive in to the vulnerability of cross-site request forgery, one of the ways to secure against it is the use of tokens. In prior versions of Drupal that happened to be an issue in some cases. So now Drupal 8 has better built-in support for that specific case, for cross-site request forgeries. David, Cash I’m not sure if you have other recommendations that you’ve seen in Drupal 8?
Cash Williams: The only other ones – a large one I would say is switching from PHP template being the engine that renders our themes to the twig engine. It’s much more locked down, if you will and reduces specifically cross-sites – CSS, what does that stand for, or XSS – cross-site scripting but also I’m sure reduces the cross-site request forgeries as well. I’m not super familiar with Twig. I haven’t gotten too deep into it but I know it’s much less likely for a themer to accidentally open a vulnerability than as easy it is to do in PHP template as it is today.
Moderator: Alright. A couple of other questions trickled in, what backup systems are out there for easy recovery especially if the database is MySQL?
David Stoline: So I can take that one. There’s actually a lot and I’ve used at least several of the toolsets that are out there. One that’s really simple that I really like is just to kind of doing it by yourself. So MySQL has a great MySQL dump command and it’s pretty trivial to set up like a daily cron job or an hourly cron job to just dump the database to some location on the file system or dump it to like an S3 bucket or something like that. There’s also kind of a script on top of that whole process called – I think it’s AutoMySQLBackup which I’ve used to great success in the past too. It’s largely the same; it’s cron based. It’s basically dumping MySQL dumps to some place. So it’s great but there’s a ton of products in this like MySQLBackup space. So it’s really just kind of a discovery process in what your organization is willing to do or willing to invest.
Cash Williams: I think it’d be great to mention as well. Acquia’s hosting comes with tools dedicated specifically to this process. So you get environments for Dev, Stage and Prod out of the box and all three have dedicated backups. A matter of creating a new backup is just a click of a button as well as restoring a previous backup is just a click of a button.
Moderator: Alright. I think that’s it for question. I want to say a big thank you to Ben, Cash, and David for the wonderful presentation. Maybe you want to end with anything else?
David Stoline: I’ll just say don’t forget if you’re coming to Austin to sign up for our training. It’s a whole day of the three of us in a room together talking about Drupal Security. So if you are able to register this week you’ll save $75.00 on the cost of the training. So hopefully we’ll see you guys in Austin.
Moderator: Awesome. Thanks everyone for attending. We’ll send out slides and recording within the next 24 hours. Have a great afternoon.