Learn about how attackers leverage social engineering, automated attacks, or mistakes in application logic to bypass access control protections.
- [Narrator] The fifth item in the OWASP Top 10 is broken access control. In this section we'll talk about authorization, insecure direct object references, and missing functional level access control. In section two, broken authentication, we talked about a topic which is related but different from authorization, which we will discuss in this section. Remember that authentication has to do with what is yours and proving that you are indeed you so that you can access your stuff.
A common and familiar form of authentication is a username and password. Authentication is about proving you are who you are and confirming your identity. On the other hand, authorization is the idea that, depending on your role, you should have access to specific things and be able to perform specific actions. For example, in my role as a LinkedIn user, once I authenticate by logging in with my username and password, I am authorized to access my account and do things like view posts from my connections and people I follow on my feed, accept or ignore invitations to connect, send invitations to connect, view and write messages, etc.
I should not, however, be able to access another user's account, since I'm only authorized to access my own account. Similarly, Tracey, another user, should not able to access my account since he is only authorized to access his own account. There might be another role called admin, which is authorized to have access to all accounts. If somehow I'm able to figure out a way to break the authorization rules and either access another user's account or escalate the privilege of my user account and act as admin, therefore obtaining access to all accounts, then that means that the application's access control is broken and the authorization rules are not being enforced.
One type of vulnerability that can lead to broken access control is called an insecure direct object reference. The idea is that there's a direct reference to a restricted resource, but the application does not check to make sure that a user is properly authorized to access the resource before allowing the reference to be used. Here's a simple way to think about it. Say I login to my account and I notice that the URL of the webpage now includes some text that says account equals Caroline.
If I can then just change the text to say account equals Tracey and access Tracey's account, then that's a problem. If the LinkedIn application allows me to access a different user's account by simply changing the text in the URL, then that's kind of how an insecure direct object reference works. Basically, the application is failing to perform a check to ensure that the identity of the user is appropriate to the access and resources that are associated with the account before it allows the user to access the account.
Please note that this is not how the LinkedIn application actually works. I'm just using it as an example. Another variation to consider is with regards to admin rights. An administrator is a privileged role, and in this section we've been talking about a role called admin, which is authorized to have access to all accounts. If it's possible for an authenticated user who is not an admin to access this page, that's a problem. If it's possible for a non-authenticated user to access this page, that's a problem.
Applications are supposed to make sure that access rights are in place and confirmed before allowing access to certain application functions.