Well, hello there, I'm John, and this is the InfoSec skills learning path for the 2021 OWASP Top 10. In this video, we're going to look at the number one security risk on the list and that is broken access control. Let's get right into it. As we talk about broken access control, I wanted to take a minute to talk about access versus authorization. Sometimes people will get these things mixed up a little bit. Just to clarify, authorization is the process where request to access a particular resource is granted or denied. Authorization is not authentication and these terms are frequently confused, like it says right there. You can think of it like this. Authentication is providing, invalidating who you are, your identity. If someone were to say, "Hey, I don't even know who you are" and if they were meeting me, I would say, I'm John and that is authenticating that I am who I say I am. Whereas authorization includes the rules that determine if you're allowed to have access to something. If I were to walk into a secure facility or maybe some organization and they've got certain areas that I'm not allowed to be in, but certain areas that I'm or that thing. The first thing that we're going to do is say hey, let me verify who you are and then I'm going to tell them, hey, I'm John, maybe you have to give him a driver's license or some some kind of identification to prove that I'm who I say I'm. That's all about authentication, authenticating who I am. But then authorization is them saying, now that I know who you are, do you have the right? Do you have the permissions to get into these places that you say you need to get into. These are, these are important things to remember. These are important parts of access control. Because when you talk about access control into an application, you certainly didn't need to know who the user is or who the machine is that is wanting to gain access to your application and then you need to have controls around that to say, hey, am I going to allow this user to gain access to my application or to this part of my application. There's all these things that you need to consider around the control of the access to your application. You can see there on the side as well, applications need access controls to allow users to use the application so there's varying privileges and you can imagine. Some users are going to be granted access to more parts of the application than others, depending on their need to know or their level of privilege or those things. Administrators who frankly are a high level of access into an application, they need to manage those access, control rules. Then they need to manage who gets granted permissions or who gets entitlements to what part of the application or not these are all important things to think about. Again, at the heart of it, you have an application and you have users that want to access that application, and also at the heart of it, you have good users that need to be granted access and you don't want to slow them down or put a bunch of roadblocks and they're way that just cause a bad user experience. But you also have bad users. You have these attackers that want to gain access in your application and you need to stop them. It's this very delicate balance. The other interesting thing, and one of the reasons that this is the number one security risk is that it becomes very difficult with the way that applications are deployed today is they're spread all over the place. You have on-prem application hosted environments. You have cloud-based, you have multi-Cloud, you have hybrid, where you're Cloud and on-prem and now we're moving more to like Edge computing. The places that your applications live are wide and various, and it's hard to keep your arms wrapped around. How do I keep the good users access into those applications? How do I keep the bad users out of it. It's an issue out there. We'll go through that here in this video today. A few things about access control, different types of access control to keep in mind. There's role-based, which this is just you have an individual's role and responsibility within the organization. Access decisions are made based on the role that you're in. Whether are you a user, you're a superuser, you're an admin, that kind of thing. Role-based access control. Discretionary access control is a means of restricting access to information. This is based on the identity of users or membership in certain groups. The owner of the information has the discretion to change the access rights at any time in this discretionary access control. You may be in a group like an administrator's group or some other, maybe you're in the finance group or the HR group or the sales group, that thing. Based on the identity of the user, then, it's not necessarily the role that you're in, but rather the identity that you carry based on your position in an organization, let's say. Then moving on down, mandatory access control. This is getting a little more strict in terms of granting access. This is access control based on assigning sensitivity labels on the information itself. Then you compare the sensitivity level of the information itself to the sensitivity that a user has. Sometimes you may see this either in a corporate, confidential type information or maybe in like a government classified information where some information is just publicly accessible, it's free to share with everyone. Other information is saying, "Hey, no. This information specifically has been assigned a sensitivity label of maybe classified or company confidential or whatever." Then if you have a user that's operating at that level or higher then they can grant, they can gain access to that information. But certainly if they're not operating at that level or higher then they can't look at that information. That one gets a lot more strict, the mandatory access control, it's the sensitivity labels, that one gets challenging too because you have to label all of your information and that can be a challenge. But there are definitely areas where that may be needed in terms of creating access to information or not. Then the last one, their permission based access control. This is the abstraction of application actions into a set of permissions. You could have things like you see there where it's a simple string-based name like a read or write or modify or whatever. The application action is based on a string-based name or an action that's given to that particular part of the application. That one is permission based access control. Those are a few different types of access control. You'll see the tab on there, role-based access control, also called, RBAC. You'll see that one quite a bit in applications today. A lot of organizations use that, which makes sense. It's based on your role and so will you be granted access to the information or not based on the role that you currently occupy. But it's good to know about those different types of access control in the context of, do we grant access to information or to an application or not? We don't want to have the broken access control. We'll move along. These are the factors. We talked about this in the overview video. But the CWEs that were mapped to broken access control specifically there were 34 of them. The max incidence rate, which is the applications that were tested against the CWEs that were ultimately configured or collected into what is now considered broken access control. The max incidence rate, 55.97 percent of all of the applications had an incident of at least one of those CWEs that was mapped. Then the average incident rate was 3.81 across all of the applications that were tested against those CWEs. Then the average weighted exploit. These are the, how easy is it to exploit those CWEs that were mapped to this security risk. Average weighted exploit 6.92. That's pretty high. Again, it's out of 10. Then the average weighted impact. This is the impact to your organization if one of those CWEs or if this risk in general were to be exploited, 5.93 again, that's also out of 10. The max coverage. Basically that one means that of the applications tested against these 34 CWEs, there was at least one of the CWEs covered, 94.55 percent of all of the applications that were tested against this particular set of CWE. That's a massive number. It basically tells you that, of the CWEs that are mapped to the problem or the risk and known as broken access control almost a 100 percent, this is 94.55, almost every single application dealt with some problem related to broken access control. That's a massive number. Then the average coverage again, of the 34 CWEs they're listed. The applications that were tested against those had an average of 47.72, which is also a big number when you consider they're looking at 34 different CWEs. The total occurrences, these are, remember, there was almost 500,000 or actually just over 500,000 applications that were tested in this dataset for this 2021 OWASP Top 10. 318,487 of those applications had issues with some kind of a broken access control, CWE. Then the CVEs, the common vulnerabilities and exposures that were mapped back to those 34 CWEs, 19,013 CVEs were mapped to the CWEs listed there. That is a massive amount. Again, you can think of CVEs where you can think of it as it is. It's common vulnerabilities and exposures. These are specific vulnerabilities that are associated with different programming languages, or hardware, or frameworks, or libraries, or some code that are exploitable, they have a vulnerability. When you think about from an attacker perspective, this is over 19,000 unique ways, frankly, to get into an application via a broken access control vulnerability. You think about the fundamental nature of an application. If you are granting access to just anyone and everyone, then you're going to have a problem on your hands. Again, this is why this is such a big deal. It's extremely prevalent in the world today. Again, based on that max coverage, almost, frankly, close to 100 percent of applications deal with this problem. There are almost 20,000 different individual ways to exploit this thing. It's just a big deal. That's why it's number 1 frankly. Well, let's move on and maybe look at just, this is a super basic example of saying, if I'm a user over here on the left and I want to access a web application on the right, then I'm going to type in my URL example.com/info. Then the little question mark, the little query parameter account equals John. Then that should give me access if I am in fact John, and if I have authenticated myself, and I have the authorization to access that part of the application. That's the idea with what you're doing when you access this URL. But then if an attacker comes in and says, hey, I want to access that same thing and instead of account is John now account is admin, then are you going to give access to the admin page to this particular user? If the answer is yes, you are going to give them access, then that's a problem. That's one very simple example of a broken access control. You have granted access to a web application, to a user that did not need to be given access to that part of the application. That would just be one example. In this case, you would need to verify, hey, are you the admin? Have you authenticated yourself? Are you authorized to access this part of the application? Then once all of that is true, once you have authenticated and you are authorized, then I'll give you access to this. But if you don't take those steps, those authentication and authorization steps, then you should not grant access. Here's another similar type example. But this one, let's say we're accessing that same web application. These are two different URLs now. Just like that top one example.com/apps/getappInfo. In order to get the application information, you should be authenticated in order to get to that part of the application. An unauthenticated user should not be able to get to that page. You need to be authenticated to get to that page. Then if you look at the one below it, example.com/app/admin_getappInfo. This is goes back to that admin example that we just had. Then you need to be an admin in order to get to that particular part of the application, that particular page. You can just see the notes down there at the bottom. If an unauthenticated user can access either one of those pages, it's a flaw. Then if a non-admin can access the admin page, then it's a flaw, that's a broken access control problem. Again, for that second one listed there, you need to be an admin to be able to get to that. You certainly need to be authenticated to get to either one of them. Those are just when you think about access control, those are just a couple of very basic examples of what we're talking about here. This is the way that a user would request access to an application, or frankly, an attacker may come in and try to gain access without authenticating themselves. These are examples of what we're talking about. A few things to consider here in terms of, are you vulnerable? Is your application vulnerable? This is certainly not an exhaustive list. This is not a complete list. But these are some things that are out there today that you should take a look at and be aware of, so we'll just go through these things. You can see there at the top, access controls need to enforce policies which begs the question, Hey, do you have a policy in place. You need to make sure you have a policy. Then those should limit users to their intended permissions. You need to keep people within the bounds of what they're supposed to do. Some things that might happen that would be problematic would be, you can just see there the first one, bypassing access control checks by modifying the URL. That's what we did in that example earlier. You could modify the internal application state of the HTML page, or simply use a custom API attack tool. APIs are another big issue in the world today. There's a multitude of APIs that are part of applications today, and so those are other areas that you need to keep an eye on. The next one. They are allowing the primary key to be changed to another user's record which permits viewing or editing someone else's account. This is that session key, can it be changed, can it be modified, those types of things. Are you keeping a close eye and close lock on the primary key for a given user so that it's not allowed to be used to edit someone else's account or used to impersonate someone else. That's another thing to keep in mind in terms of access control. The next one is elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user. This goes back to some of that we were talking about before. You have different levels of user, maybe just a regular user, or like a super user, or an admin, or whatever. If you as the application owner are granting access to a user that is not at their level of user permissions, then you have some problems. Certainly as you go up the permission levels then you need to be authenticated, you need to have authorization to get to those parts of the application. Metadata manipulation, replaying or tampering with a JSON Web Token JWT, access Control, or a cookie, or hidden field manipulated, abusing JWT invalidation. These are things that an attacker could do, and things that you as the application owner need to take a look at and say, hey, I'm allowing these things to happen? This gets back to some testing that you need to do to make sure that, hey, I'm I running through proper checks and validation to ensure that some of these things are not taking place in the application that I own at least. The CORS misconfiguration. This is some of the cross origin of details that can happen with a web application where the server can decide, I'm going to allow different domains to be accessed in the process of loading a page or conducting HTTP request and those types of things. Effectively what could happen here is if you have CORS misconfiguration, then you could take advantage of an API that allows access to that API end point, and via a CORS problem that's allowing some cross domain, or some sort of a cross origin request, then an attacker could take advantage of that misconfiguration and request access to an API that should not normally have access granted to it. Or be able to pull information from an access, or from an API that normally would not allow you to do that thing. Anyway that's another area that you could take a look at to make sure that attackers would not be able to use any CORS misconfiguration to get to an API that they don't need to be able to get to the. Then that last one force browsing to authenticated pages as an unauthenticated user, privilege pages as a standard user. This gets back to what we're talking about a second ago. Are you are you a lower level permission user, and you're just force browsing to, give me the slash admin page or that type of thing. You should not be able to get to that page. Then accessing an API. Again, because APIs are so critical in the building of applications today, then a lot of APIs you should implement access controls. So you had these different HTTP methods like POST and PUT, DELETE, that thing. Let's say you have an API endpoint that you only want to allow post data or get that type of thing, but you don't want to allow the delete method to be used for that particular API endpoint. Well, if you haven't put in access controls to that particular API endpoint, then an attacker could send that particular HTTP method to that particular API endpoint and they could do things that they need to not be doing. It's another issue of access control that could cause problems for your web application. Those are a few things to keep in mind in terms of vulnerability. Again, that's not an exhaustive list, but those are some ideas that give you a picture of, hey, if my application is acting in a certain way or allowing certain things. Again, a lot of this goes back to, hey, you need to build it in, as you build it, you need to build it with these things in mind. But then even after it's built, sometimes you come into an application or like I hadn't even build this thing but I own it now, so I'm responsible for it, congratulations. Then you need to test it. You need to say, let me go back through this thing that someone else built or frankly, a big team of people over the course of many years built this. It's just become this big behemoth that no one even knows exactly what it does or whatever. Anyway, go back and test it. Look for these things and if they exist, figure out a way to say, we need to put some access controls around these things. When we talk about are you vulnerable, also talk about, well, how can you protect yourself? You can see the first statement there, access control is only effective if it's enforced and trusted. Server-side code or serverless API, where the attacker can't modify the access control check or the metadata. Again, on the server-side code, on the application code itself, you need to enforce these access controls, or within the API, like I talked about before, allowing certain methods, or not allowing certain methods to certain API endpoints. A few things to keep in mind are listed here on this slide. You need to deny by default. Unless it's a public resource. If it's publicly accessible like hey, this is the main example.com front webpage, then that may be just a publicly accessible page which is great. But anything else, when you start getting into this /admin or /userdata or whatever, type pages, then you need to deny by default and then you need to grant access accordingly to those users that should be granted access, but don't grant access to anyone else. Frankly, you can have users come to you and say, hey, I need access to that and you could authenticate them. Then you can grant authorization based on their role or based on the access controls we talked about at the beginning. That's one thing to keep in mind. That's one guiding principle, deny by default. Implement access controls once and then reuse them throughout the application. Minimize the cores usage like I talked about before. Attackers could use that to try to gain access to places they don't need to be gaining access to. These access control mechanisms if you use them once and then reuse them throughout the application, it helps you as the application owner to standardize the access controls and it simplifies the access control frankly, where you don't have to keep up with it in one place and in another place is totally different. It's like, hey, what did I do over there? Implement these mechanisms once, and then reuse them to the extent that you can throughout the application. That's a good idea. Then these access control should enforce record ownership rather than accepting that the user can create, read, update, delete, that's CRUD. If you haven't heard CRUD that acronym it just stands for create, read, update, delete any record. You need to make sure that the proper owner owns that record before you just accept that any user can do all of those different things to a particular record. The last one there, disable web server directory listings. Ensure file metadata backups are not present within web roots. Sometimes what attackers will do is they'll come in and say, hey, if I can gain access into any part of this application that I'm not supposed to be allowed access to. If I can figure out a way to list the web server directory. Then that just gives me a map into how this thing is built and where all the corners are and where all the deep dark places and all that are. Then it just gives them a better idea of where to go start poking next. To the extent that you can disable that the web server directory listing, then that's a good thing to help with access control. A few other things I'd list here or I'd mentioned here, you need to log the failures of access control. If someone tries to go to a URL or go to a page that they're not authorized to go to, you need to log that failure and then alert the Admins whenever it's appropriate you need to monitor those logs. We'll get into that in a later security risk in the Top 10. But log does failures. The next one, the rate limit API and controller access. If an attacker were to get to an API endpoint, get to an API that they don't need to gain access to then by rate-limiting that then you're effectively limiting the amount of data disclosure or data manipulation that could happen. It's good to rate limit API and controller access. Again, you're just putting a limit, you're putting a lid on how much access you potentially would leak. Again, if you think of it in the eyes of a worst-case scenario, if you say, okay, let's say an attacker gets in and they do everything that they possibly could do. How bad would it get? That's the idea of here of rate-limiting the access to minimize the harm. The next one, JSON Web Tokens, the JWT tokens should be invalidated on the server after logout. This is the idea of if you have a user that logs out and then someone else may be to come in behind them, that thing and you have not invalidated that JWT token, then an attacker could take that JWT token and then use it on behalf of the authenticated user. Again, if you have not invalidated that token, then even though the first user is logged out, then the attacker could come in and replay that or use that on behalf and that's not a good thing. All that to say when a user logs out and you disable the token, or you invalidate the token. Then I know I've mentioned this may be a couple of times throughout this video, but developers QA staff need to include functional access control unit and integration testing. This is where you look at this whole situation and you say, okay, I own my application, or I have this application and I need to make sure that I'm testing not just the usability, not just the, hey, this is a good user and they're authorized, and does it work? All that does need to be tested of course. But think of it from the eyes of an attacker and say, okay, what if we try to break this thing? What if we try to use this in a not good way? Then you need to make sure that you include those test developers, QA staff, everyone along the way, test it in that way. Those are some things that you can think about to protect yourself from this problem of broken access control. Hopefully, that'll keep your web application safe. A few things that I would mention here and these are listed on the OWASP webpage as well. But you can see here, there's several different resources that you could access. Only if you're authorized, of course, because broken access control. But these are things you can take a look at. The second one there, I'll just call it out again. I mentioned this in the overview video, but that's the Application Security Verification Standard, the ASVS. That's an actual standard that you can use against your application to say, am I doing things correctly? Am I building an application that has the proper access controls in place? There's some cheat sheets listed there for access control authorization. Just some really good resources here that OWASP has put together and in fact, some of these and you'll find this along the way as we do the other videos as well. Not every one of these resources is an OWASP-specific thing. Again, this gets back to the nature of the OWASP organization. There may be, a GitHub page that one of the OWASP contributors just has some really good stuff on, and it's like, okay, we'll go to that GitHub page and just check it out. It's good stuff. But anyway, these are some things that you could take a look at and would help you hopefully in your access control journey as you build applications that don't have broken access control problems. You allow access to the good people, and you deny access to the bad attackers and all that stuff. Again, some good resources for you. With that, let me say thank you for watching this first video in the Top 10 of the OWASP 2021, broken access control. I appreciate you hanging in there with us today and I look forward to seeing you in the remaining videos.
