From the course: Learning the OWASP Top 10
Broken access control
From the course: Learning the OWASP Top 10
Broken access control
- [Instructor] The first item in the 2021 OWASP Top 10 is Broken Access Control. OWASP says this exposure occurs when confidential information is viewed by a user who should not have permission to access that data. Let's break it down. In order to talk about Broken Access Control, first, we should define Access Control. Access Control is making sure that people have access to what they're supposed to have access to and making sure people don't have access to what they're not. Broken Access Control is exactly the opposite. You have access to information you shouldn't. And what happens when people have access to information they're not supposed to? Well, this is a perfect way to breach the confidentiality, integrity and availability of a web application. A person with unintended access might be able to read, edit, or delete private data. Let's explore a couple different examples. The first scenario is when sensitive information is exposed to an unauthorized person, software is built assuming that different people are going to use it. And each user will have permissions that are specific to their user role. Typical roles might include an anonymous user, a visitor, an employee, a content contributor, an administrator or developer. Broken Access Control occurs when a user is able to act beyond the permissions of their role. This might happen if a web app accidentally shares information with users who are not supposed to have it. If I have a social media account that's private, the only people that are supposed to see it are my friends and family that I've approved. If someone else goes to my profile and can see all the photos, my kids and pets, that's Broken Access Control. It's also kind of like if someone in the human resources department prints out a document that has all the employee performance evaluations and forgets to pick up the paper from the printer, leaving it out in plain view for anyone who walks by to see that confidential information. The key takeaway here is to make sure that you're not unintentionally leaving private data around for just anyone to stumble upon physically or on the web. Our second scenario is conceptually similar to the previous example, but instead of just leaving sensitive data out in plain sight available for anyone to view, it accidentally gets sent to someone who is not supposed to have it. The subtle difference here is in the first scenario, the private data is just there for anyone to see, it's accidentally shared. In this case, the private data is actually sent to the person who shouldn't have it. Imagine if that same human resources person from scenario one tries to send all employee performance evaluations, to someone else in the human resources department in an email, but accidentally types the wrong email address into the to field and it unintentionally gets sent to everyone in the company instead. Another example to consider might be if you're at the doctor's office and you finished your appointment, you're just waiting for the nurse to bring you a printed summary of your diagnosis and treatment. The nurse comes in, and hands you the paperwork, you look at it and it's actually not yours, it's someone else's, the nurse made a mistake, and now you have access to someone else's medical data. The takeaway here is that when you're sending private information, you need to really make sure that you're sending it to the right person. These examples might seem kind of obvious, but this is the most common vulnerability in the 2021, OWASP Top 10. When we're building and testing new web applications, we tend to test the positive path a lot, but we don't always consider what an alternative path might be. People aren't as altruistic as we'd like to believe, and people misuse and abuse things all the time. If we don't take into account that people are going to do the wrong thing, a lot more than we want them to, it has the potential to result in huge problems. The bottom line is that when you're building a web app, you have to be really intentional about building solid access control into your system.
Contents
-
-
-
Broken access control4m 37s
-
(Locked)
Cryptographic failures3m
-
(Locked)
Injection4m 19s
-
(Locked)
Insecure design2m 58s
-
(Locked)
Security misconfiguration3m 6s
-
(Locked)
Vulnerable and outdated components3m 2s
-
(Locked)
Identification and authentication failures3m 17s
-
(Locked)
Software and data integrity failures3m 35s
-
(Locked)
Security logging and monitoring failures3m 17s
-
(Locked)
Server-side request forgery (SSRF)1m 43s
-
-