Security in Drupal: what can go wrong?

Um, security and Drupal. What could possibly go wrong? And the answer, unfortunately, is way too much. So get a few introductory things out of the way. I'm Benji Fisher, I just use my name. No creativity as my my handle on drupal.org. Also on GitHub and GitLab. Um, I do uh, I contribute. I'm good. See, I push the button. Um, I do some contribution for Drupal Core and a few things. Um, I moderate the weekly usability meeting and I'll probably be doing that this Friday at the beginning of the contribution event. I'm one of the maintainers of the migrate API or the migration subsystem, and I'm a member of the security team. And because I'm a member of the security team, um, I give this presentation because part of our job is to educate Drupal community about security issues. Um, you can also scan that QR code or go to slides banffshire.info um, to get a list of all of my presentations, including today's. Um, and don't be afraid of the outline. Um, we're in the introduction now. I'll talk a little bit about what is the OWASp top ten.

I'll talk a little bit about what is Drupal. Um, and then I've listed all of the top ten security vulnerabilities from the OWASp top ten. Um, but I will only talk about two of them because that's all we have time for. And I haven't even prepared. I've prepared four of them. Let's, let's let's think positively. What have I done rather than what haven't I done? So I've prepared four of them. Um, and there's time in one session to go through two of them, and then I'll wrap things up. Um, so my slides borrow from some presentations from Peter Wolin on Cracking Drupal. And I've also cribbed a lot of text from OWASp. Org, um, which I'm allowed to do because they have a Creative Commons license, just like all of my slideshows. I'm going to open that in a new tab, because navigation in JS is doesn't work well. The back button doesn't work well. So so yes, all of my slide presentations, um, use a Creative Commons license. Um, so that's the end of the introduction. What is the OWASp top ten? Uh, let's see if I can remember it.

OWASp is, um, the open web application security project. That's right. Yes, I got it right. And that is a non-profit foundation that works to improve the security of software. It's not Drupal specific. So this is one way of getting off the Drupal island and looking at Drupal from an outsider's point of view. Um. The OWASp top ten is a standard awareness document for developers and web application security, and it represents a broad consensus about the most critical security risks to applications, and the list is updated every few years. The most recent revision was in 2021, and I hope to prepare all of the ten before they revise it again. I'm not sure when that will be. Um. What is Drupal? How many people in this room are new to Drupal? Only a couple. Um, so still, I want to take sort of an outsider's point of view. So for those of you who've been using Drupal for years, pretend for a few minutes that you're a newbie. And what exactly is Drupal? How would you describe it? So Drupal is a content management system, and that basically means that Drupal goes out to the world and it shows a form on a web page and it says, enter something into this form.

Whatever you enter, I will save in my database, and then I'll use it to create web pages. And what does a hacker think when they see that? Let's get started. This sounds like fun. So, um, when a hacker sees a field like name, they say, well, the person running this website expects me to fill in something like Robert, but I won't do that. I'll put in Robert. Close quote. Right, friend. Semicolon. Drop table. Students. Semicolon. Dash. Dash. How many people have seen this before? About half the room. Um, that's pretty typical for when I give this talk about half the room recognizes this example, and the hackers hoping that when when I, the website owner, process that form, I'll do something like this. I'll create a string variable named SQL insert into students name close paren values, open end quote, and then I'll insert dollar name the variable, whatever's been entered in that form. Close quote right for n end of the string. And if I am foolish enough to do that with the value that the hacker provided here, um, that will turn into two SQL statements.

The first is insert into students name values. Robert. So that's just the SQL syntax for adding an entry to a database table. But then the second statement will be drop table students. So if the hacker has correctly guessed what my code looks like behind the scenes and correctly guessed the name of my database table, the hacker has done a lot of damage to my site. Make sense? Hackers do things like. They're very clever. Um, whoops. I meant to go on to the next page. There we go. So this example that that half the room recognized comes from xkcd, um, which also offers Creative Commons license. So, um, so, so, uh, rent Randall Munroe, is that his name? Yes. Thanks. Um, wrote wrote a little story about that exploit. And, and the title of the comic is Exploits of him. Um, although it's often referred to as the Bobby Tables comic. Um, so actually, before I go on, um, so what is a web CMS? It is one of the worst ideas ever from a security point of view, because we're we're just wide open to this, this sort of, um, attack.

Um, you know, every website is subject to certain things, like distributed denial of service attacks. You know, someone has a botnet, and every computer in their botnet is sending requests to your website, and they just want to overwhelm your resources. Um, any system is vulnerable to that. Um, but not every system is vulnerable to or not. Resistant invites you to enter text and save it in the database. It is fundamentally insecure and we have to work very hard to get around that. So what else is Drupal? It's an active international open source software project. Um, and I cribbed some text from the about page on Drupal.org. Um, it's one of the largest open source communities in the world, and more than a million passionate developers, designers, trainers, strategists, coordinators, editors and sponsors. Um, working together, um, and Drupal takes security seriously. So we recognize that a web CMS is a terrible idea. Um, and we have a security team. It's an all volunteer group who work to improve the security of the Drupal project.

Um, we come from four continents North America, Europe, Asia and Australia. Um, it was it's it was started in 2005 and has had three team leads in that period. Um, the current team lead is Michael Hess, who might have checked you in registration. Um. So any, um, any questions about OWASp or Drupal? There were a couple of Drupal newbies. Any questions before I go on? So this is the choose your own adventure part of the talk. Um, so there are ten things in the OWASp top ten. Um, you can see from this view of the presentation which ones I've prepared. Uh, number one is broken access control. Two is cryptographic failures. Three is injection. I've prepared all of those. Insecure design just for the sake of knowing what they are. I'm not offering to talk about them because I haven't prepared them. Security misconfiguration. Vulnerable and outdated components. I've prepared that one. Identification and authentication failures. Software and data integrity failures. Security logging and monitoring failures and server side request forgery.

So going back to the ones I've prepared. Um, which of these four would you like to start with? And we'll again, we'll probably have time for two. Six. Six vulnerable and outdated components. Um, so the best kept secret in web security is that the most important stuff is to do all the boring stuff you already know. Like you, I may be disappointing you. You may have come to this talk thinking that I'll tell you all the deep, dark secrets that will help keep your website secure. And what I'm telling you now is that there are no deep, dark secrets. Just do the obvious stuff. Um, it's sort of like. What if you saw this? Would you think it was clickbait or would you follow it? How to live a longer, healthier life. It just takes four minutes a day. Does that sound too good to be true? I'm seeing a couple of people nodding their heads. Yeah, that sounds. It's not. It really is true. What can you do in four minutes a day that will give you a healthier life? I'll give you another hint. It's not four minutes all at once.

Breathe. Well, I like to breathe 24 hours a day.

>>:
Drink water. Water. Drink lots of water. It's not four minutes all at once. It's two minutes twice a day. Does that help? Brush your teeth? Yes. Brush your teeth.

>>:
Um. It's the best advice you'll get today. You should also floss, and you really will live a longer, healthier life. Okay, so that's what it's like. The important stuff, the things that will really help you that that sound too good to be true are the stuff you already know. And it's the same with web security. The important things about keeping your site safe are the things you already know. Um, use good passwords, have a policy. Don't let people use PA dollar dollar word as their password. Um, keep your software up to date. And that's sort of what the OWASp is telling us. Number six um, avoid vulnerable and out of date components. Um, but along the same pattern of things, you know, um, you should probably not be running your own web servers unless a, that's your core business. Then run web service service, if that's your business. Um, but if you're a university, if you're, um, an e-commerce site, you should not be running your own servers. You should let someone else do it. Who knows what they're doing?

Um, the the only other use case is if you're a hobbyist. And I think lots of us are hobbyists. I have a web server. I don't use it for anything mission critical. Um, no. No one will be at all upset if the things on my web server go away, get hacked. Um, but but it's kind of fun. And you learn about the how to configure Apache and stuff like that. So it's it's a learning experience, but it's not something to use for production. Um, so a little more Drupal specific. You should know the schedule. Um, if you're going to keep your Drupal core and your Drupal contrib modules up to date, you should know the schedule a security release. Windows are Wednesdays from 12 to 5 eastern time, so I guess that means 11 to 4. What's that right now? Um, yes. Um, yeah. And these presentations are full hour, which is a little more than I'm used to. So. So I can do things like, um, I could go to. drupal.org/security. Um, and the most recent notice is from March 6th. So two weeks ago. Um, I could, uh, I could continue to reload this page.

Um, I am sharing my whole screen. Right? Yes. So let's see. I think I can do this without exposing anything terribly private. Just bring bring my slack window over.

>>:
And. Uh, make that go to. There are some private channels here. I have to be careful not to click on those, but security team is the public channel. Um, and you can see the only, uh, activity today is a question for direct message from the security team member and someone joining. So, so this slack channel security team in the Drupal slack is one of the ways, um, to check for updates. This page on Drupal.org is another. Um, so if there will be any security releases for Drupal core or contrib modules this week, they will be announced pretty soon. Um, and released within the next few hours. Um Drupal for Drupal core security updates are the third Wednesday of the month. That's today, so there might be a security release today. Um, contrib modules can be any Wednesday. Uh, so regular Drupal core updates, bug bug fix versions, um, are released on the first Wednesday of the month and then Drupal minor version updates are twice a year in June and December. So Drupal 10.2 was released last December, and Drupal 10.3 should be coming in a few months.

And you should know that minor versions are supported for year. So when Drupal 10.2 was released, that was the end of support for Drupal 10.0. Um, currently I hope you're running either Drupal 10.1 or Drupal 10.2, and in a couple of months when Drupal 10.3 is released, that'll be the end of the year for Drupal 10.1. So you should know the schedule and you should know the channels. Um, so that link to security advisories goes to this page that we were looking at a minute ago. Um, there there are RSS feeds. There are three of them, um, for core contrib and public service announcements. Um, so if you like to keep track of things with an RSS reader, you can do that. Um, if I. Show public service announcements. So this is the the web view of rather than the RSS view. Um, the last one was in November. The final announcement, the Drupal nine, was end of life. There were a bunch of previous warnings about that. Um, announcements about the upcoming end of life for Drupal seven. Um, and how it affects contributed modules.

Um. Um, but but just other channels to notify yourself about updates you can subscribe to email. So yeah, I'm pretty sure I can do this without exposing any private information. I'm just going to look at my my own user page on drupal.org. I am already signed in, so I'm not showing my password on the screen as I go to the edit page. Um, and then where is it? This second row? My newsletter's. There used to be a bunch of things here. The only one left is the security announcements. So you can see I've got that checked off. So I do get emails to my personal, not my work email address. Um, whenever there's a release, um, and the, the final channel I've listed here is the security team channel and Drupal slack that we were looking at a minute ago. Still no announcement. Um, and there are a couple of unofficial, um, channels. There's a Drupal security count, both on EKS and on Mastodon. Um, another thing to do is to, to be that's important to be aware of is the difference between major versions, minor versions, patch releases, and security releases.

So a major version like going from Drupal ten to Drupal 11. Sometime this year, either July or December, um, Drupal 11 will be released and that will be a major version update. Um, you expect that to be fairly disruptive? You might want to wait for Drupal 11 .0.1 to come out before you upgrade. You might even wait for 11.1. Um, because of the disruption. Um, some things will be removed from core. Um. Forget going to Drupal ten, we removed a couple of themes. Um, we added we made Claro the default admin theme, and we made Oliveira the default front end theme. And we got rid of seven. And I'm blanking on the previous French front end theme. Um, we, we upgraded from C editor for to C editor five. That was a big disruption. How many people had trouble upgrading their sites from Drupal 9 to 10 because of editor C? A couple of people. See more people. About half of people in the room are raising their hands. Okay, so major versions are disruptive. There may be bugs that haven't been discovered yet.

Um, that that matter. Um, it's not as big a deal as going from Drupal seven to anything later, but it's still a big deal. Minor version updates like going from 10.2 to 10.3 in a couple of months. That's less disruptive. Minor versions can introduce new features. Um, they certainly include bug fixes. Um, patch versions generally don't include new features. So like ten .2. 3 to 10 .2.4. Um, so they're mostly bug fixes and generally they're not disruptive. Occasionally someone makes a mistake and they're disruptive, but generally a patch version is not a big deal. And a security release, the most recent one was going from 10.1, I'm sorry, ten .2. 1 to 10 .2.2. So it is a patch release. A security release is always a patch release. Um, we make our best effort to make sure that they are not disruptive. Again, we're not perfect, but a lot of effort goes into making sure that a security release just does minimal change necessary to fix the problem. No unrelated changes. Um, and we try to make them non-disruptive.

So when a security release comes out, um, if you have kept. Your software up to date. If you're if you were already running Drupal ten .2.1 when Drupal ten .2.2 came out, then you'd be in good shape to upgrade. You'd have pretty high confidence that it's not disruptive. On the other hand, if you hadn't upgraded to ten .2.1, you'd have sort of two steps that you were applying at once, or you'd be putting off deploying the security update. And that's what I want you to avoid. That's that's the brushing your teeth every day aspect is to stay on the current version on a good release schedule, so that when a security release comes out, you can just apply it and have that minimal disruptive change to patch the security problem. Um. You have to trust the security team. You don't have a choice. Well, I'm sorry, you do have a choice. But either choice is trusting the security team. So the first option is when a security release comes out. You can carefully read the security advisory, decide whether it applies to your site, and if it does, patch immediately.

And if it doesn't, we can put it off till the next break. Your second option is to go ahead and update your site. Now. Either way, you're trusting the security team in the first option. You're trusting the security team to have identified all the ways that the security problem could be exploited. And when you say, oh, this doesn't apply to my site, you're trusting the security team's description of the problem and your knowledge of the site in combination to say that it doesn't apply. That's a hard thing to do when you have a bug anticipating all the ways it can be exploited. It's difficult. I said earlier, hackers are clever. The second way, you're trusting the security team to be non-destructive, and that's actually easier, right? It's our own code that we're updating. So we're in a better position to say that this change will not be disruptive. Then. Then we are to say that this is the only situation in which it can be exploited. So if you're going to choose the secure, if you're going to trust the security team either way, I suggest the second option.

Don't spend time evaluating the advisory, deciding whether it applies. Um, apply the patch, run it through whatever tests you do, and you update and get it deployed right away. Um, so Drupal is based on Symphony. That's, um. That was one of the big changes from Drupal seven to Drupal eight is that we, um, rather than providing a complete web application, we decided to use components from Symphony. And when the version of Symphony goes end of life is is no longer supported, the version of Drupal using that version of Symphony will also go end of life. So last November, um, Symphony four reached its end of life. It was no longer supported. And so Drupal nine security ended in November 2023. Even though we try for the June December release schedule, we had to stop support support for Drupal nine a month early. Um, and it's been a learning process. Drupal eight was around for five years, and that meant that one of the Drupal eight minor upgrades, like maybe it was 8.3 to 8.4, um, involved a major version update of Symphony.

We're never going to do that again. Um, going from Drupal eight on Symphony two, I think, to Drupal nine on Symphony four, we skipped a version. So all the changes that symphony made, going from Symphony 2 to 3 and from Symphony three to Symphony four. Um. Now I'm sorry. Drupal eight with Symphony three. Drupal nine with Symphony for Drupal ten is Symphony six. Is that. That's when the jump happened. So going from Drupal nine to Drupal ten, all the changes from Symphony 4 to 5 and from 5 to 6 had to be accommodated. We're never going to do that again either. So Symphony has a release schedule every two years, and going forward Drupal will follow that release schedule. So Drupal 11 will be released this year. I expect Drupal 12 to be released in 2026. Um, so just as you site owner need to keep your dependencies up to date, Drupal is a project has to keep its symphony up to date. Oh, and I guess that was the the end of that section. And I should have said at the beginning, don't wait for the end to ask questions.

Uh. I know you're paying attention if you ask questions, so I love it if you ask questions. So any questions about this topic? Keeping software versions up to date. Update strategies one. To apply security updates one to apply regular updates.

>>:
Yes, I have a tangential question of what about server side infrastructure updates. So PHP versions Apache or nginx version. Okay, so I'll repeat that for the sake of recording. Where is the microphone? There it is. Microphone is hiding back here. The question was the tangential or related question about server side updates. Things like PHP version, the underlying operating system version. So that's exactly why I said earlier that you should not be maintaining your own server. So someone else should be worrying about the operating system and applying patches to Apache and so forth. But your PHP version, um, yes. That you also have to stay on the secure version of that. Um, there are Drupal sites, Drupal seven sites running on PHP 7.4, maybe even 7.3, um, which is no longer supported. That's a bad idea. Um. Unfortunately, I'm responsible for some of them, um, which does not make it easy for me to sleep at night. Um, and and yes, you have to keep up to date with PHP versions. And you may notice that when you upgrade from PHP 8.0 to 8.1, I think 8.1 is the oldest supported version currently.

When you did that upgrade, you probably started seeing warning messages in your Drupal logs. And boy is that annoying. Yes it's annoying. Um, but it's the price to pay for keeping up to date with the software, staying secure, getting new features. Um, and that that's, you know, the people who maintain your modules have to deal with that. If you have custom code, you have to deal with that. And of course, when the maintainer of the module does their part and updates their module, you have to do your part and and apply the update. Does that answer the question. Yeah. Good. Any other questions. Okay. So it's back to choose your adventure. Um. Broken access control and cryptographic failures or injection. And let's throw in access to access control. Access control. I'm just looking at the time. It's about ten minutes before the hour, but this goes till 15 minutes after the hour. And I'm not sure whether that clock is on Central Time or Eastern time. Anyway, broken access control. I have time.

Um, so cribbed from the OWASp site. What this includes are information disclosure, um, entity. I'm sorry. Edit or delete by an unauthorized user. Cross-site request forgery CSRF, which I'll talk about later and more. Um, so access control um, familiar with the Crud acronym create, read, update, delete. Each of those requires some level of access. Um, often the read is not restricted. Anyone can look at the public parts of your website, so anonymous users are allowed to read. Um, but create and update and delete are typically access controlled. Um. What's the situation where you might give create access to anonymous users? Contact form or. A contact form. Yes, that that will generally send an email. And and we'll often save some database like a web form submission. The comments comments. That's the one I was thinking of. Typically, comments are the only thing you let anonymous users create on your website. Um, I guess on an e-commerce site, if if an. I guess it's a question of what you consider an anonymous user.

They're not actually logged in to a Drupal account, although they can be. But anyway, um, some, some interpretation of anonymous means you allow people to create orders if you're running an e-commerce site. Um, horror stories are. Years ago, um, I was working for an agency, and we got new accounts, and we started by looking at their code, and they decided they needed custom access control for user one, for the for the edit page for user one, but their custom code left off a knock. So instead of saying only user one is allowed to edit this page, anyone but user one has to edit this page.

>>:
So. How do you protect yourself from mistakes like this? How do you avoid horror stories? Don't do don't write custom control. Okay, I heard two, two closely related things. One is don't do custom access control, which I agree with. Um, I have no idea why they thought they needed custom access control and user one. Um, all I know is that they broke it when they did. And then the second suggestion I heard it just about at the same time was don't have custom code, which is also a good idea. Um. We'll say a little bit more about it. Any any other suggestions on on how to avoid great tests? Don't normally use user one. Um, so someone said write tests. Yes. Um, if you're going to have custom code that does something as important as controlling access to the edit page for user one, you should have a test for it. And what was the other? Don't use user one. Um, yeah, I think, um, a lot of people will block user one. Um, and I guess there are two reasons for that. Um, one is that guessing the you need to guess both the username and the password to get access to an account.

Usually guessing the password is the hard part, but if you have user one enabled and they have full admin access, then the easier of those two is something you don't have to guess you already know. Um, and then there are still in Drupal we're trying to get rid of it. There's an issue to get rid of it, but they're still in Drupal some special treatments for user one beyond being an admin user. Um. Um, some edge cases, mostly an admin user can do anything user one can do, but there are a few edge cases. Um. But writing tests is, um, is a great suggestion. Anything similar to that?

>>:
You have someone test your code. Manual tests? Yes. Have someone test your code. Have some. Review your code. And so these are the answers I gave. I think you came up with most of them. Um, I sort of had to tease out of you code review, um, automated tests and avoid custom code. If customers knew the true cost of custom code, they would probably ask for less of it, or they would be willing to pay more for it. They're not willing to pay more, we know that. Um, so so basically, um, Drupal core and some contributed modules have a lot of eyes on them. So a lot of people have done code review, a lot of people running automated tests on them. And that is reliable, lesser used contributed modules. They have fewer eyes on them. They may not have as good test coverage. They're less reliable. The code I write is less secure than those less commonly used contrib modules. If especially if I'm the only one to look at it. Um, you have to have a little bit of modesty. I don't have a lot. You have to have a little bit of modesty in this business to recognize that the code you write is probably less secure, probably less performant than the typical contributed module.

Um, and anything that is good for code quality in general is also good for security. So the automated tests and the code review, um, are all important. So. Broken access control. Yes. If you're going to use access control, best of all, let Drupal Corps do it. If you really have a special use case where Drupal Corps isn't good enough, try to find a well supported contrib module that does it, or a less supported contrib module. Use custom code as the last resort and if you do, then have tests, manual tests, automated tests and code review. Um, so I promised to explain what a cross-site request forgery is. And this this is it. On on one side, Mysite.com, for example, we have an image chat and the the source for that image tag, instead of being an actual image goes to some other site. That's the cross site part. It goes to example.com slash node slash 123 slash delete. So other than creating a broken image on the site, what will this do? Um, generally it doesn't do anything, but every so often an admin user for example.com visits mysite.com.

What happens then? The admin user's browser goes off and makes a request to node slash 123 slash delete on example.com the site that the admin user is an admin of. And chances are, if I'm an admin user for some site, there's a good chance that I'm logged into it. Um. Forgot that that's that's the cross site part. The request forgery. So it's making a request, and it looks like the admin user is trying to go to the site and, and do something like delete a note. Um. Right. That's what node slash 123 slash delete does it deletes a note. Um so some questions. Why does this particular attack not work. Confirmation on delete right. Confirmation on delete. So in Drupal um when when you do visit that that URL, it does not delete the page immediately. It gives you a confirmation form. You have to submit that form which is a Post request not a Get request before it actually deletes it. Second question. Um, and this is this is of course, a very simple example. As I've said twice before, hackers are clever.

What I tell you three times is true. Um, and hackers have much more complicated versions of this. Um, what are the underlying assumptions that can expose similar vulnerabilities? What are the underlying assumptions that you, as a site builder or a module developer, are prone to make that make you vulnerable to this sort of attack? So you might assume that someone visiting example.com slash node slash 123 delete. You might assume that when an admin user visits that they actually intend to delete the page. So the. So the assumption is that when someone visits one of your page, they're there for the intended purpose. Um. But, um. Especially with forms, it's an easy trap to fall into when you're processing a form to assume that the Post request that submits that form actually comes from the form you provided. No Post requests can come from anywhere, and hackers love to exploit post requests. Um, so how you avoid CSRF? Use confirmation forms? Um, don't don't do anything on the simple get request.

Um, expect users to tweak URLs so you know, they might add, slash, edit, or delete to the end of the URL just to see what will happen. Um, or they, you know, they might be trying to find a page that they know that they should have access to and they can't quite find the link. So don't assume that because you haven't given a link to the delete page that no one's going to go there. Um, and use tokens on to prevent cross-site request forgery. Um, let me say just a little bit about that. Um, and I guess it's it's related to that last point that forms are hard. Um, so in Drupal, every time you have a form built through the form API. Oh, and I've seen a lot of people just put in a block of HTML code for a form that use the form API. Um, every time you build a form Drupal through the form API, it has some hidden fields. Um, with AA1 time token for that form. And then when Drupal processes that form, it checks the token. So it actually confirms it doesn't assume it confirms that the Post request to submit the form comes from the actual form that was generated.

Um, and a CSRF token is a sort of similar idea, and I won't go through the details, but that link does go to a documentation page that explains what CSRF tokens are, how to use them in Drupal, and they're there to prevent this particular vulnerability. Um, and I'll say it again, forms are hard, and a web content management system is a terrible idea from a security point of view. Um, so what does it look like in Drupal? Um. We'll let that open in the background while I read what's on the slide. Um, so in 2021, the sixth security advisory for Drupal core, um, came out in September, September 15th. Um, it has this rather cryptic. Security risk description that it was moderately critical. That much I understand. But then ECA CI the vulnerability was a cross-site request forgery and it had a cve id common vulnerability. I don't remember what the E stands for. Um, and again, there are several channels for for getting this information. Here it is on the web page. Um, here's that cryptic field.

If you hover over it, it explains what those various abbreviations mean. AC is access control, A is authentication. And based on those properties the numeric risk score is calculated. The maximum is 25. This one came out to ten which I think is the low end of moderately critical. Um, and maybe I'll read it here. I've copied it to the slide, but the description is that the Drupal core media module allows embedding internal and external media in content fields. In certain circumstances, the filter could allow an unprivileged user to inject HTML into a page when it is accessed by a trusted user with permission to embed media. In some cases, this could lead to cross-site scripting. So the idea is that not an anonymous user, but a less privileged user, maybe a content editor would be able to edit a page and either accidentally like they're copying and pasting something from Stack Overflow or maliciously. They could put in something that when a more privileged user, the full site admin, was also editing that page, bad things could happen.

Um, so I think the next slide is just copying that text. Um. The fix as always. I guess I can look at it here. The solution is to install the latest version, and depending on which minor version you're using. At the time this was released, the supported versions were 8.9, 9.1 and 9.2. Um update to the patch version that's released along with the security announcement. Um. And it was a fairly simple change to the code. Um, and it just added a CSRF token so that, um, and then it validates that token so that um. I guess if. You like looking at code, you can look at the code, but it just adds an extra level of validation. Um, that, uh, that stopped that particular attack was relatively small patch. Uh, no. It wasn't so small. It was. I guess I'm not looking at. Here we go. 64 editions, 24 deletions. Okay. So. Um, yeah, that's the end of that topic. Um. Any questions? Various ways people can get around access control. And in Drupal, by far the most common broken access control is controlling read access.

So information disclosure is when there's a problem with access control for information that should remain private. Um. And frankly, the typical Drupal security advisory. When you read it, it doesn't sound so bad. You know someone who already has, who's already a content editor, you know, might be subject to this. Every so often we get something that's really serious. So. Time to go over to conclusion. So I've just repeated the outline. We talked about the OWASp top ten. What is Drupal? Why is a CMS a terrible idea? We went through a couple of those. Broken access control and number six vulnerable and outdated components. Um, so here are a few references. Um, so I do all of my presentations in revealed JS and they're all listed here. I've mostly been doing this versions of this security presentation for the last couple of years. I have links to the OWASp top ten, um, link to the Drupal security team, the Drupal Core release cycle. So again, I said it's important to be aware of that. Um, that's where all the information is listed with particular dates.

There's a link to the security advisories page. Um. I think it's important to be aware of your biases. And one of mine is that I think mostly about Drupal Corps, and I tend to forget that there are also important contrib modules out there. So I'm also biased against JavaScript. I'd rather build the page right the first time rather than have to fix it after it's already been delivered to the client. But anyway. But there are contrib modules that are useful. There's security review which will check your site for common misconfigurations. Um, the paranoia, which was probably more important in Drupal seven. It checks to make sure that PHP eval is not used from the web interface. Like don't let people run arbitrary PHP code. Um, the security kit, which is a sort of grab bag of things. It lets you set content security policy and other, um, HTTP headers. Um, it has origin checks against cross-site request forgery and cross-site scripting. Um, garter is a distribution with security in mind and the two factor authentication module.

Um, I kind of think should be part of Drupal core. You know, once once we get rid of the aggregator module and some of those other things that I've never used. Can we get two factor authentication into core? Um, but it is a contrib module. Um, any more questions? Okay. Well thank you for coming. Hope you have a good mid camp stay for contribution day on Friday. And thanks for coming to my talk. Thank you thank you.