 So, quick disclaimer, I'm a Star Wars nerd, I grew up on Star Wars. If you are more nerdy than I am, please don't just shout out that I'm doing something against Canon or anything like that. Come talk to me afterwards and we'll nerd out about it, alright? So I'm taking a little bit of liberty with Athenae. But if you will join me on this journey, pretend you are building a website with ambitions to take over the entire galaxy. Initial launch was a great success, right? You did it and pushed all the buttons and pulled all the levers and fired your big death ray and blew up a planet. However, there's some bad actors out there and those bad actors are plotting to take down your website. So what we have to do is we have to figure out, with one small hole in our defenses, the entire thing can blow up and destroy everything that you spent all this time building. So, luckily, as Drupal has progressed over the years, its defenses has also gotten better as well as its offenses here. But the rebels are smart, they continue to come back, but luckily for us their ways are consistent. So, no matter what, we can learn from their patterns and from reusing plot lines over and over again to see how these hacks happen. So if you are new to cybersecurity, new to developing, we're going to be going over some basic hacks today. If you are an all-pro, chances are you have one of these vulnerabilities in code you've written, so go back and look at it. But today we're going to talk about Death Star Security and how all it takes is a few rebels to take down your website. So this is going to be interactive, it is 5.40pm on the last day of the last session. So if everyone can get out laptops or whatever, if you want to join along with us and go to DeathStarSecurity.com, surprisingly this domain wasn't taken and I haven't gotten a cease and desist from Disney yet. So for as long as it's up, I'll leave it up there. And while you're going there, I'll tell you a little bit about myself. I'm the founder and CEO of Locker and Cellar Door. I've been fortunate enough to work with everything from startups to large enterprises. I've been working in Drupal for about a decade. I've also been working in WordPress lately as well. Don't hold it against me. They're actually a really fun group of people to be with. And then more recently, I've started getting into policy and advisement and I sit on an advisory committee for the Department of Homeland Security for privacy and data integrity. So, but for this, I am taking the role of the security architect for the Empire. And we're gonna look at a few plugins or modules that I have found in our code base and some issues that they introduced for us. So if you go to the website, you will see a whole bunch of fun puns and jokes about Star Wars. But down at the bottom, there's gonna be two links that you're gonna be following there. So we're gonna be talking about the droid scanner search module that one of our developers built for us. And we're also gonna be talking about Stormtrooper customer targeting. And so I love that I get little laughs because I've given this talk before and nobody got that joke. So the first one, droid scanner. This was an advanced search module that they wanted to consume data from an outside source whenever a search happened. And then also after that search was done, they wanted to do some telemetry and some metrics on it. Now, you might think what harm can a few droids do, right? Well, the harm that a few droids can do is they can connect your site with what we call a DDoS attack, a distributed denial of service. And the idea here is that through nefarious code, bad actors can spin up a whole bunch of browsers or a whole bunch of connections to your website and take it down. Particularly what they're looking for is forms and slow loads, right? Anything that takes a long time to do. And so this search module unfortunately took down our website. And so this is a, if anyone can read the code, it just says sleep. You don't just sleep a module, so. But this is an example of code going out to an external source, right? And I've actually had this happen. We didn't get DDoS on it, luckily. But if you have code that goes out to an external source, and it has to do some processing there, there can be some lab time in that processing. Then if you're doing additional stuff, if you're doing additional work, after the results are back and you're processing through them, and you're connecting a whole bunch of things, we as developers want to do as much as we can with the code that's in front of us. However, if an attacker can see that your code runs slow on a specific form, and they hit that form over and over and over and over again to the tune of millions of times, they can take your site down, right? And so if you go to the website and you click on the droid scanner, what I did is this is actually the code running there. It is on every search result. It's just going to wait four seconds as it's rendering that. And so if you, it's all loremips and then there's just typing some Latin word into the search on that site. And you'll notice that it takes an incredibly long time. If enough of you do it in the room, it'll likely take down the server as well. And that is an example of what a DDoS is. So one of the ways we can do this is move your slow functions to asynchronous processes. I built a site once that was an airline ticketing reservation system, right? There is a lot that goes on once you swipe the card or enter in the details before that ticket is actually purchased. And if we were to put that all in the page load, it would take 30, 40 seconds in order for something to happen, right? I've seen this a lot of times where people will just hook into a knit or right at the beginning of the bootstrap. And then they just start doing a whole bunch of processing and it just slows everything down. So if you're doing anything that a form submission will slow down, move it off to an asynchronous process. Create a queue, Drupal does a really good job with the batch API of working its way through queues. And then you can either create some sort of internal webhook that comes back and does more work on it. The easy way that I've always done it is just to create a cron job and then have that cron portion of your module just churn through all the slow stuff. So A, users are happy, the website loads fast. And B, the company is happy, or in our case the empire is happy because the website wasn't taken offline. This is where we're going to spend a little bit more time, is in the stormtrooper customer targeting. And so how does this module miss? And this module misses because what we're doing here is we're saying, okay, I want this to be some customer tracking. I want to have an identifier that I'm going to give to the customer to track them through their whole process, right? As we start looking at these digital experience platforms and more of the content is dynamic. We're doing a lot more processing like this. A lot of the times that's getting passed in URL strings. So if you ever click on a link and you get these really long URL strings, those are normally just tracking tokens that are being passed along. And so what our module does here is it says, I'm just going to take whatever is in that query string and assign it to a variable to then output into my theme. As a developer, you might not think that that's that bad of a thing, right? Because you know that your front end developer is smart and they're going to be taking care and sanitizing the data that comes in. But our front end developer, or this is dangerous, don't ever trust anything coming in. Sanitized at the moment, it comes through the doors. Because what you don't know is if your front end developer doesn't know that that's sanitized, that's not sanitized, they're just going to use it, right? They're just going to say, hey, whatever's there, just output it. I'm running into some issues I need to hack around. I'm going to turn off, if you notice here, it says the value is get tracking raw. If you put raw as a filter on twig, it will just output and not auto-escape, right? It's a nice hack that for some reason the formatting's not going well and instead of going back and actually talking to the developer and saying, hey, let's figure this out, I'm just going to put raw on it and let it output. What that says is whatever I get, just put it out. So if you click on that next link, and we'll do that here, because this is a fun little demo to do, we're going to, nope, people are playing around with this one already. I purposely made this site to hack around, so you guys are doing a good job. Let's see here. So by doing this, you'll notice up here in the corner, I get a little shake going on. If this was actually able to plug into audio, this would be playing the Harlem Shake right now. This is a really fun script that you can put on. And then pretty soon here, our entire page is going to do the Harlem Shake. So what I have done is I have injected, if you look at the URL up here, at the very top I said, well, instead of input and putting a value into the input, I'm just going to load an arbitrary script from a server that I can control. Once that JavaScript is in your browser, I have full control over it. I can do whatever I want. And while I may just make you dizzy by having things moving around, I can scrape your cookies, I can key log, I can do a whole bunch of things. So cross-site scripting is actually a very common bug or vulnerability that we see. Luckily though, yeah, so it allows you to run arbitrary or remote JavaScript. It can exfiltrate data so it can look at what data is on the screen. If you're in a banking application, it can take that information out. It can capture cookies, and if you're not careful and you're not using your cookies properly, luckily Drupal does. If you're building a website that's not managing its cookies properly, you can actually leak your session data, and then the hacker can then act as you. And there's nothing that will stop that because to Drupal or whatever system, it's a request from you. They can do key logging. For those of you here in the EU and the UK, this is what happened with British Airways when they lost all the credit cards. There was some nefarious JavaScript that was running. And as people were entering their credit card numbers and CVVs and everything into the form, all they were doing was just key logging what was happening on the screen and then sending that back to a server so they could collect all the credit card data. So this can get really nefarious really quickly. So sanitize your user input, never trust anyone, including your admins. Because if a session leaks, a bad password's out there, like is on the demo site there that a few of you have already hacked into. Your admins can put out some bad input as well or somebody can act as an admin and get in there and do stuff. Luckily though, or in the other thing, your inputs aren't limited to what you put out into a form. So just because you have a select list doesn't mean that I can send you back something that isn't in that select list. Luckily, Form API does all this for you. So if you're building a form on Drupal and you're not using Form API, stop and go use Form API. There is zero reason not to. I will be honest, in building this little demo and the couple of click-throughs, it took a really, really long time to figure out how to hack Drupal. Because it is so hard, they're sanitizing everything now, which is good. The same demo and WordPress took me about 10 minutes. I'll just say that. But how do you sanitize the text? You have cross-site scripting classes that you can call with filter and filter admin. Filter admin will allow a little bit more HTML through. So if you say, okay, I can trust my admins a little bit more, it has a broader set of allowable characters in it. But it will filter out any cross-site scripting or any JavaScript. People get really fun and they try doing base 64 encoding their payloads. They'll do a whole bunch of stuff. This takes all that out. So again, the form API, it will sanitize all inputs, outputs, it'll sanitize things that are going into markup. It sanitizes everything. And it sanitizes it as it comes back in after you submit it as well. In Twig, don't use raw filter. Period, full stop, just don't use it. Because Twig, if all you do is you put the double brackets and you put a value in there, it will auto-escape every string that comes through it. So that was one of the nice things of moving from Drupal 7 to Drupal 8, is you had a lot more inherent security in the theming layer itself. And then lastly here, use a code sniffer in, I like to use VS Code now. I'm a convert. I used to think only nerds used this, but it is awesome. Microsoft actually created a really good product. And so, what's really cool is we have official docs up on Drupal.org to how to configure Visual Studio and put code sniffers and linters in there. Not only will you be creating nice and pretty code, that's according to community standards. So your modules will not fail any tests. It also will highlight, hey, you haven't sanitized this, or hey, you have an error here. And the nice thing about VS Code is it makes that very apparent. If you look at your code, and then also it will do some, every time you hit save, or I haven't set up, so every time I hit save, it'll come up and tell me all my errors, all the issues that I have. And it's caught, I mean, I do security for a living. And it's caught errors that I've been putting in code as well. So with that, I want to leave you with the idea of Death Star security. We focus on the perimeter a lot. We put up WAFs. We put up as strong of servers as we can. But it doesn't make up for bad code. So make sure that as you're working on your systems that you're also focusing on the little functions and the little things inside your code that could eventually blow up the entire thing. So with that, we have about five-ish minutes. If you want to go get beer and food, you won't offend me by leaving. If you have a question, I'll take those now. All right, I think a lot of people want beer and food. So with that, thank you. Make sure that you go to the contribution sprints tomorrow and be sure to take the surveys as they're up there.