 All right, welcome. It's a backend track if you're in the right room. And our next session is for man who needs no introduction, as he said himself, Sam. And he's going to do dissecting security audit. Great. I did say I'd introduce myself. So yeah, it's called dissecting a security audit. So I'm going to look at five issues with Drupal Sides that come up all the time. If you're getting an external security audit done on your site. So hopefully, if you see some of these tips, you can maybe apply them to your site. Even if you're not getting a security audit done, maybe it will make things a bit more secure. So I'm Sam Becker. I am on Twitter, dripal.org. That's my previous next team bio page, if you want to see some blog posts. But that's where you can find me online. I'm going to crack straight into it. So the first thing that comes up all the time is password strength. So in Drupal, auditors pick this up. You can set your admin password to ABC. You can set it to 123. There's actually no kind of strength or enforced onto any of the passwords. So this is something that comes up all the time. But luckily, we're using Drupal. There is a module for almost anything. And password policies are no exception. So a few more people coming in. Welcome, Daniel. Lee, Gbrand. Hello. Cool. We all settled? Great. So let's design a password policy. So what are some things that go into password policies? Like capital letter. Got to have a number in there. Let's call them out if anyone has any symbols. Great. Length. Can't reuse the old one. That's a good one. No more than six characters. Bit sketchy, but what's our password one? Yeah, password one. Yeah. So there's a blog post by one of the co-founders of Stack Overflow. And it basically says password rules are bullshit. So it goes into a lot of detail. And the basic summary is for a lot of password rules, you can have some really sketchy passwords that are actually accepted. So this top one, we've got the capital letter. We've got the symbol. We've got the number. For a lot of password policies that you might just decide to design one day, you may actually be allowing some really bad passwords. But for really secure ones like this, it's a bunch of random words. They're actually a lot more secure and they have a lot more entropy. So for that reason, I would actually suggest that we shouldn't just be installing a module that actually encourages us to design and configure our own password policies. So there is an alternative. And someone said minimum password length as one of the items. So the kind of hypothesis of the blog post is that's really the only factor that matters when choosing a strong password. So this is a super, super simple module. It requires no configuration whatsoever. You don't actually have to go and think about what's going to go into your password policy. You can actually just install it. And with a couple of lines of code, it actually enforces that all your users, when they sign up or when the accounts are created, they're going to have a password that is quite secure. So that is an alternative. Next thing that comes up all the time is single factor authentication. And that is you have a username, you have a password. Oftentimes, a third factor makes your accounts way more secure. You need that third factor to log into the accounts. So again, this is Drupal. We have modules. And there's actually a whole suite of modules that do things related to two factor off. And it's a bit of an ecosystem. So TFA is kind of the main module. And there's plugins that sit on top of that. And underneath TFA, there's the encrypt module and the key module. However, all of these modules actually require quite a bit of knowledge to set up. You have to know what an encryption key is. You have to set up encryption profiles. You have to configure them. You have to find these modules, put them all together. And the other thing is some of these actually aren't covered by Drupal's security team. So depending on the scope of the security audit you're going through, if you fix one problem, you may actually introduce another one by adding alpha C modules. So that is definitely something to look out for. So there is an alternative, much like a password policy one. There is a simpler version. And this is just a single dependency you can install on your site. It has absolutely no configuration whatsoever. You have no options. And enabling it will do one thing to your website. And it will add a little one-time password box in the footer. You scan a QR code on your user account. And then you have a second factor of all set up. This is it running on the previous Next website. We have it there. And I would say it probably wouldn't be running on our website if it required us to spend hours sort of digging into the configuration of all of these other modules and maintaining like a bigger ecosystem. So it's great as a really low barrier to entry to increase the security a little bit. There are some caveats with the simplest solution though. So none of the secrets that the module stores are encrypted. There's no kind of wizard or confirmation step. There's no backup codes. So it's really rudimentary. It may not be something you want to deploy out to a site that maybe has thousands of users because they can't do all these sort of extra nice features. But for a site like ours where there's sort of 10 user accounts makes a lot of sense. So the next one I'm going to look at that comes up. That has come up in a lot of the audits that we've gone through are the security headers that are sent by Drupal. There's actually a great site called security headers.com. And you just plug in your website. And it does some analysis. And it says, OK, tick, tick, tick, doing these things well or you're doing these things poorly. Again, I put the previous next website in there. And we scored an A, which is pretty good. But it looks like there's some work to be done still. So out of the box, this is what you get with Drupal. You get the xFrame options, which is a security-related header, and the xContentTypeOptionsHeader. It sends sort of like the most secure version of those headers by default. So xFrame options is about limiting what other sites can do in relation to framing your website. So I think by default, if you try to put a Drupal site in an iframe, it'll browser will kind of stop you and say, no, no, no. So the next one is the xContentTypeOptions. So this is around sniffing the type of content that the browser is receiving. So you couldn't say, create a script tag that pointed to an image or a script tag that pointed to, say, a text file. If you send this particular header with a particular value, which Drupal does by default, it'll limit all of those kind of scenarios. So the header that the browser sends is the type that the content will be interpreted as. So for the things that Drupal doesn't have by default, like the content security policy, this is kind of what the header looks like. It's a really long header. It's got a lot of information in it. And this is one I actually generated for the previous next site when I saw that we didn't have it. And it defines all of the kind of other resources on the internet that the browser will be able to access when your page loads. So here I'm saying we can actually download fonts from fonts.gstatic. We can get sort of an image from Google Analytics. There's a couple of other domains that we can pull data from. But it's pretty complicated to write these. They're kind of technical. You've got to know the ins and outs. There's a great browser plugin. And it's for Firefox. You install the plugin. And then you actually just go record a session and click around a website. So that's what I did here. I just hit record, opened up the previous next site. And it recognized that since we were running Google Analytics, that we needed access to those domains and a bunch of other things. So it's a great way to generate those headers and increase the security of a site. So the next one is the refer a policy. So this is an interesting one. If you actually load the previous next site and you click on a link somewhere else, by default, the browser says, OK, since we're coming from previous next, I'm going to tell the next website that traffic actually came from previous next into that site. And this has a few nasty security implications. I'm going to look at a case study in where this was problematic. So this is a post by a security researcher. And he created this great zip bomb that sort of caused a bunch of issues in a lot of contexts. And a couple of weeks after publishing this exploit, he had this line at the bottom. And he said, I noticed that in my web server logs, there were a bunch of referrers pointing to my blog post. So he had a look at that data. And he said, I wonder what is linking to this page about security? And he noticed that all of the domains were actually bug trackers for various companies. There were Fortune 500 companies, open source projects. And all of them had raised tickets about this security issue that they were vulnerable to. And he was actually receiving information about the other projects that were impacted by this bug. So that's a pretty nasty example. But it kind of demonstrates why it's important to sort of lock that down. Cool. Next one is feature policy. So this is about the things you can use on the device when the page loads. So you can do things like turn off the accelerometer. You can turn off geolocation. You can say you can't use the microphone. So if some kind of incident happened where maybe there was like an XSS issue and someone injected some code, the actual security headers for the browser would have totally disabled those features. So if you're not using these things, it's great to send a header to say, OK, just switch them off. Pretend they don't exist for my website. The next one is username enumeration. So this is being able to look at a Drupal site, kind of do some work on it, inspect it, probe it a little bit, and figure out all the usernames that are available on the site. So this is actually a common problem with Drupal. Some people see it as a problem. The official sort of message is that it's not actually going to be fixed. It's not a bug. It works as designed. So again, contrib to the rescue, there's a username enumeration prevention module. And this sort of closes a lot of the little loop holes that exist around being able to sort of pull out usernames out of a Drupal site. So this module is great. There's no sort of alternative or gotcha here. There's no configuration you have to go through or ways to shoot yourself in the foot. It's just sort of plug and play does its job. And this is the last one. So it's being able to fingerprint a site as a Drupal site. So anyone got any ideas on how to fingerprint a site as a Drupal site? How would you recognize a Drupal site if it's running? Drupal.js. Dries's birthday in the header. That's a good one. That was my first one. I didn't think anyone would think of that. That's great. Site default files. Yeah, that's a good one. Change log, that's a great one if you go to slash core slash change log you get a list. Let's go through. We've got the generator, metatag, common parts. Robots.txt is the same on every Drupal site. Someone already mentioned JavaScript. There's a lot of ways. And the kind of outcome is there. There's really no point and don't bother. There's too many things to close. You'd need to just sit down with someone who's recommending this and say, listen, we understand. We don't want to advertise information about the software we're running. That's great. But it's simply too difficult. And with a lot of the attacks that are kind of really widespread, like the Drupal get-in ones, they weren't sort of fingerprinting or profiling sites ahead of time. It's just kind of like an automated sort of thing that's sprayed out and deployed en masse. So yeah. So final thoughts for all of this stuff. These are actually some graphs pulled from reports done on Drupal sites around security issues. And the thing you'll notice about all of these is there's actually no high or critical ones, a lot of medium, low informational ones that are pretty easy to patch over. So I think in general, we're pretty fortunate to deal with Drupal as a framework, which has a lot of abstraction that deals with security really, really well, especially in Drupal 8. It's actually almost hard to write code that's insecure. So we're pretty fortunate in that regard. And that's it. Any questions, comments? Let's give a round of applause to Sam. When are you applying for Drupal Security Team? Sorry? When are you going to apply for Drupal Security Team? I don't know. I don't have time. If anyone does have time, you can go to security.drupal.org and work with the security team. They triage all the sort of bug reports and security reports that are done across all the supported contrary modules. And their job is to work with the maintainers of the contrary modules and work with them to deploy security fixes. So when you get that red bar at the top of your Drupal site that says go to the status page, you're running insecure versions. Chances are the security team has done some work to tag security releases of contrary modules. So just a question about the fingerprints. You're saying there's too many to actually hide, but would you recommend at least one or two to change? Example being probably most of us went to what CMS to check out which CMS website is running. And I found lately a lot of Drupal sites actually hiding a minor version to not disclose which security vulnerabilities they might be running. Do you know any other fingerprints? You would recommend which is easy fix? Yeah, I mean you could remove a couple. Like I mean the generator meta tag is a really easy one. I think there's like an altar hook you can call and to get rid of it. So if you specifically didn't want to appear on a list that was fingerprinting your site with one particular mechanism, you could probably do that and it might be valuable. But again it's just sort of like a small part of a bigger problem that's probably never going to go away. So it'd probably be more for a bit of theatre to make someone feel comfortable by removing the word Drupalite from the source. But in general it probably doesn't have like a lot of real world impact on the security of your site, yeah. Yeah, just on that line of fingerprinting as well, just thinking extemporaneously here. But like when it comes to being able to fingerprint what modules a certain site is running and then obviously there's a critical security flaw in one of the modules. Then I don't know, I think I'll put my head here but if there's a way to obfuscate kind of what modules the site may be wanting to spy, you know not loading the front end resources directly from those directories and having another layout and other anything just that way. But do you reckon that there is a potential like security or not vulnerability but exploit or way of people being able to use a known security flaw and then do a board scan of known Drupalite sites that may have that particular flaw? Yeah, I mean it is possible. And you mentioned a couple, right? So like loading resources from like a module folder or something like if it's color.css from the color module or something like that. But again that is just kind of one way that a module sort of surfaces its identity to the Drupal site. So even if you obscure a couple of things, you're still not secure. It's kind of more security by obscurity. And you might stay hidden from some lists and some search engines, but you're still running insecure software. So really the kind of thing that's not mentioned at all is like the absolute bare minimum is you just have to be running secure versions of your software. So that's kind of like almost assumed for this talk, right? It's like you've upgraded your modules, you upgrade core. Yeah, I guess that's the best way to deal with it. Just make sure you update it regularly and make sure it's up to date. Yeah, for sure. Bigger on the, one more, last one. I was just gonna ask, how much weight do you give when considering modules that they're only alpha or release candidate? Personally, not much. Because again, like all the custom code you write is not covered by the security team either. So as long as you're kind of doing due diligence, like you review modules, every module I install I try to review it and look at what it's doing. That is how some of these other modules were written, like one time password for example was written because password policy does a lot, a lot. Has stuff all over expiry of passwords and all these different rules and these plugins and personally I find that too complex to support. I want something super simple. So I don't give weight to that. That is just kind of, it's almost like an anecdote to say like, you try to increase security and you're adding a ton of code which actually isn't covered by the security policy but personally I don't give it a lot of weight. Yeah. So are there any top tips for people writing code to make it secure? Like we all know the SQL injection type stuff. Are there any in your experience that aren't being hit on the head by module writers? Yeah, I mean, I don't think so. It's kind of out of the scope of the session. Like there's a lot of literature out there about writing secure code but again, like I think we were talking in our back end Slack channel at previous Next and there was a trivia question. Someone was like, how do you actually introduce an XSS vulnerability into Drupal8? And it was, you know, a couple of people answered but it's actually not that obvious because there's so many layers of abstraction with twig templates and auto escaping that even introducing an XSS vulnerability in the first place is kind of hard. So I think in a lot of cases if the framework doesn't make it blindingly obvious whether or not you're adding a security issue then maybe that's an improvement that can come into the framework but Drupal has been around 10 years. It's only gotten better every release. So thankfully we don't have to deal with a lot of that. It's pretty secure by default. Round of applause for Sam.