This is a transcript of the A01 - Broken Access Control training session. Click here to return to the OWASP Top 10 Security Vulnerabilities page
[00:00:00] Michael Meyers:
Thank you guys so much for taking time out of your busy schedule to join us this morning. Um, really appreciate you having us back. This is the third year.
Which is really exciting. I'm Michael Meyers, the managing director at Tag1. We're going to be talking today about the Open Web Application Security Project, the OWASP Top 10 vulnerabilities for the most common vulnerabilities found in software applications. And we're going to do so in the context of Drupal. This is being recorded and should be made available.
So if your peers are unable to make it, or you need to drop off early we should be able to provide you with a link. Uh, we also have recordings to previous years available for you. If you'd like, I know there are a couple of new topics this year. So if anything dropped off from previous years that you're interested in, please let us know, we're gonna be doing, it's around 9:30 Eastern time.
Right now we're scheduled to go through 10:50 Eastern time. We may end up early, really depends on the number of questions that you guys have. Please feel free to [00:01:00] interrupt at any time. If you have questions, we're going to save time at the end of each topic for questions as well. Um, today we're covering Broken Access Control, Cryptographic Failures.
Injection, Cross Site Scripting. Um, and today's talks are going to be led by Janez Uvrec who's based out of Europe. Uh, Janez is one of the most well-known top contributors to Drupal with a really diverse and interesting background. He's authored research papers and given conference presentations on enterprise scrum.
Uh, he's a community leader that's helped organize and participate in many code sprints, meet-ups conferences and spoken at numerous conferences on a variety of topics. Um, he's a leading authority on multimedia and media handling in Drupal. He was the Drupal Core Media Initiative Coordinator responsible for overseeing and leading the re-architecture of Drupal's media handling capabilities.
Starting in Drupal 8. He's contributed to around [00:02:00] 100 contributed modules ranging from MongoDB to the Entity System. And you know, has a diverse background in security and application scalability as well. So Janez, thank you so much for putting together presentations on these three topics. I'll hand it over to you.
[00:02:20] Janez Urevc: Thank you for the introduction, Michael. Hi everyone. Um, yeah, Michael told everybody everything about me, so we'll just jump into it. I pasted links to the topics that we will cover today into the Zoom chat so we can follow along. Um, this year's list is slightly different than the list that we had last year and years before that. Different types of vulnerabilities definitely moved on the list, some [00:03:00] climbed a little bit, some became less common. There are some new topics. There are some things that got merged into like, multiple things into a single one, et cetera, et cetera. Um, here on the homepage of the report, you can see like in detail what happened. Um, it's quite interesting read to follow, what's going on in the industry.
I will also suggest, like if you're interested in methodology and how this data was collected there are these other topics that you can, that you can explore here from the menu. Uh, but what we will do is we'll go through the list of most common categories of security vulnerabilities and talk about them in context of Drupal.
[00:03:56] Janez Urevc: And as Michael already said, the first one that [00:04:00] we have on the agenda today is Broken Access Control, which actually climbed up, from previous years. Um, which means like, if we look at the list, we can see that Authentication is it's relatively lower on the list, which makes me think that we are getting better authenticating people correctly.
But then when they are authenticated, we are still quite often exposing data and services that they should not have access to, to them. And that's the main difference, like Authentication is about who you are and Access Control is about what you should have access to. Um, and if we check, if we see like in every section, [00:05:00] there is list of three most common types of vulnerabilities.
Um, the first one is Exposure of Sensitive Information to Unauthorized Actor. Um, this is quite broad, but, it's probably, that's why it's very common. And Exposure of Sensitive Information Through Sent Data, like sending data that we didn't intend to send over to the user and Cross Site Request Forgery.
And in context of Drupal, we have pretty good solutions to prevent all of them. Um but it's not that Drupal prevents us from doing bad things out of the box. We have to be aware how to use Drupal's APIs and you know, what guarantees they assure us and what guarantees they don't. Um, and then when we [00:06:00] understand that and when we use APIs properly, then we can have reasonable level of protection.
The first system that is important in context of access control is the routing system here. Oh, I assumed that you all see my screen share.
[00:06:23] Janez Urevc: Okay. So what I'm showing here is the route definition file from the user module from Drupal Core and each of these sections is given route and the important part in context of access control is this requirement section Probably one of the most common requirements or like access checks for routes is this underscore permission one, where we, [00:07:00] um, tie access to a route to user permission from the permission system, that Drupal has, and that's quite effective and why we use the Core and also country and, custom modules, but there are more possibilities. Uh, like we can see here, we have a route which lets us create users.
And instead of having a permission that says, like create user, we have another type of check, which ensures that somebody who is trying to access and use this route will have access to create entities. And in this case, obviously, and these of the type user and this leads us to another [00:08:00] access control API, the Drupal has, and this is entity API, and more specifically the access control handler, access control system of the entity API, which we will get to a little bit later.
Um, but besides that we, we still have more, interesting things that we could look at. Um, for example, we have another interesting requirement here, which is not like excess control per se. But it's a regular expression that defines how this parameter in the route code modules should look like.
Um, and you know, this ensures that if some [00:09:00] attacker is trying to achieve something by trying different forms and funerals we have the permission check, which, you know, we'll make sure that the attacker should have the permission to actually access this route. But even if they have permission and if they try to put in something strange as a modulus parameter, we can use this regular expression to limit what they can do.
And in effect here, we have like two layers of protection, which is, which is one, one of the important principles in security sometimes also called the fencing bed that, you know, we tried to have multiple layers of protection because we accept [00:10:00] that some layers will fail and we try to rely on other layers to save us in that case.
Uh, it's almost like I'm an aviation geek a little bit. And when it comes to aviation safety, they also always say that, you know, there are multiple systems on the airplane that ensure that we safely come back to the ground. Um, and usually when the accidents happen, multiple systems have to fail for things to go really wrong.
And here we are trying to follow the same principle. Um, so this is definitely something that you can use when, when you're trying to protect your routes.
Um, [00:11:00] okay. So here we have another route that is open to everyone like this requirements here effective says everyone should have access to this. Um, Which, on the first side, it sounds a little bit scary, but then when we see that this is the password reset form it also kind of makes sense. If you forget your password, you're probably accessing the site as an anonymous user.
Um, and you want to be able to reset your password then authenticate. Um, so in this case it's probably fine. I'm pretty sure it is. And there are, there are many different, different requirements that already shipped with the Drupal Core, but then we also have a [00:12:00] possibility to, to write our own custom handlers. One example,
um, we saw here where we looked at the module. Uh, regular expression check before we can see that there is another custom access defined that handles some other specifics of the route. And when you are, when you're writing your own modules, you can use this and create like, completely custom logic.
And it's very simple. It's usually just a class like this. I will have to increase the font again a few times. Um, so it's, it's a class that is defined as a service in the dependency injection container that has this access function which gets, you know, the [00:13:00] route that we're dealing with and the account of the user that is trying to access the route.
And then here we can basically, you know, implement any logic that we want. Um, and we are returning this access result neutral or access result. You know, access granted or granting access in, you know, under some condition. Um, and this is really powerful and can basically allows you to do and implement any business logic that you want or need.
Um, so with, with, with this we, we already achieve a decent level of protection, but then as I said, we have another layer in Drupal, which is the entity access. Um, [00:14:00] and no entity access is also implemented this entity access control handler classes, which are defined. Uh, on the entity, this is, the, then the definition of the node entity, which is one of the most commonly used entities in Drupal.
Um, and we can see that it defines node access control handler as, as its handler. Uh, but even if you have your own custom entity and you omit this line there will be default logic applied. Uh, so you know, your, your custom entity, even if you're not aware of the system will be protected to some extent will, will be protected, like quite well.
Just [00:15:00] the flexibility won't be, you know on a level that maybe it should be.
So, if we look at the access control handler, handler from node we have some boilerplate stuff, and then most importantly, we have this access and create access functions. Um, and here we can see that we deal with the entity in question, the operation, the operation would be something like view, edit, delete. Things that you can do with the entities.
Um, and then account of the user to this trying to access this entity. And then some logic in here
in the node case, we can see [00:16:00] that first it checks. If the user has the bypass node access permission, which is a, you know, an admin permission that if we granted to a user, they will basically be able to do anything with nodes and sharing that case. We gave access no matter what. Um, and then, you know,
if they don't have the access content permission, we deny access and then we fall back to the default logic to, to do the rest. Um, so this is quite powerful and this basically. Uh, you're probably familiar with the permissions page in the Drupal UI, where you have this various permissions related to nodes and who can [00:17:00] create and edit various content types and things like that.
This is all implemented in this entity access logic. One thing that is very important to know is that various querying APIs definitely like the, the lower level database create API, but also the entity create API. They won't check this access by default. So if you misuse entity query, for example, and, you know, load some entities and display them to a user, you might be exposing something that. Uh, you didn't intend to.
So if you're using these more low level database APIs, you should always check the access as well, in order to be [00:18:00] secure. Um, yeah, and if we do that, if we, if we use the routing requirements correctly and the entity API access control correctly we've already achieved a lot.
Uh, another thing that you can do if you want to be on the safe side is to use API for that are already provided by Drupal things like views, like views we'll check Access control to some extent depending which plugins you use or if you have, you know, it's possible that there are some used plugins that come from contrib, or if you write your own, it is still possible to, to go around the access control.
[00:19:00] Um, but for the most part, things would become good Core. Um, do offer you some level of security as well.
Another API in Core that is also important from this perspective is for me, API for API has a lot of security mechanisms. Um, mostly about other types of vulnerabilities, but it's a part of format. API will prevent users from seeing parts of the forms or entire forms that they don't have access to.
It's especially useful when we have entity forms cause they're entity forms will rely on entity access API to to determine what can be seen in what can be used and what not, but also in the [00:20:00] custom forms, it is possible to use permissions to define, you know, if a given form elements should be displayed or not.
Um, so that's also something that we can use. And while Form API, I'm aware is quite complex and sometimes it's quite hard to understand and fight with. Um, I would still advise against coding raw forms from scratch. Cause you know, that's where we really start exposing ourselves to attacks.
So yeah, then in this context, in context of access control, another important thing is logging, which is another topic later this week, but I wanted to mention it nonetheless. Um, if we are at fact, and there is some [00:21:00] data exposed to somebody that should not have access to this data it's way better to know that this happened and what exactly happened compared to not knowing.
So, this is where logging comes in. Um, and we have to think about that as well. Um, one thing that I think I will mention in under every topic is the, the culture of the team of the, of the engineering team or development team, and you know, how we approach quality, how we approach code reviews, um how we treat people that decide to speak up their concerns.
Like all these things are very important. Um, it's nice to have, you know, best practices and [00:22:00] rules that you follow and you know, that that helps you stay secure. These soft skills, if I can call them, like, these are probably the most important ones. Like if we, if we don't follow the, the like peer review practice and not just for, you know, for the sake of it, but also, but to actually use it, you know, to improve our code.
Um, and if we don't have culture that allows people to speak up and give their opinions about things then bad things will sneak in way sooner than did they would have. Um, if we have this culture of doing everything to ensure high quality code and high, high quality engineering of our systems. [00:23:00] Um, so I think like this is very important.
Uh, as much here as with every other topic we will cover.
There are some other things that we could do that we can do. Um, like a lot of times you will see sensitive data committed into code versioning repositories this, you know exposes this data to, well, if its a public repository, basically to everyone, and there are, there are sites that, that search GitHub for passwords and release them almost immediately when they are pushed.
Uh, on, on GitHub. So this is [00:24:00] something to have in mind. Um, also when we have private files in Drupal and, you know private files, maybe configuration, it's really good practice to put all these things outside of doc root, which maybe sounds obvious. And if, if you're using default Drupal composer project, that's already implemented there.
But a lot of times we see people not doing that. And there's no sense of having private files if they are in the doc root and somebody that can tweak URLs a little bit can get to that. Um like, no, no, no use of those private files basically. Um, Yeah. So that's what I have about broken access control.
No, I'd like [00:25:00] to open the floor for any comments or questions.
[00:25:08] Michael Meyers: Any questions for Janez?
Um, well, if things come up, please note them down. Um, we'll save time at the end. Um, and you're welcome to reach out to us one-on-one as well. And if you don't want to bring up questions in a group forum, we'll provide a contact email for you at the end of the trainings. Um, that was awesome. Janez.
And as I um, I think that you know, Core versus Contrib versus custom code, you know, Core provides a lot of protections, but through your own code, you know, or what people have done in contrib you need to make sure that you're not circumventing those protections. And I really loved your point about culture.
Um, you know, it doesn't matter how great all of these technological solutions are. [00:26:00] You know, if, as a team, you guys aren't encouraging and fostering an environment where. You know, these can be discussed and people are doing code reviews and checking each other, and that, you know, security is in paramount.
Then, you know, these underlying technology solutions are going to be able limited value and help. Uh, so awesome. Okay. Um, if there are no takers for questions, let's move on to the next topic.