Threat Analysis

Welcome to Broken Access Control session. In this first part, we will focus on threat analysis. We will take our time to dig into access control flaws details, and then we will discuss how the system can be harmed, the impact of successful exploitation, and give you some insights to identify who may want to harm your system. Authentication and access control are often combined into a single operation, causing a serious misunderstanding regarding controls boundaries. We have already discussed authentication flaws. In this session, we will just focus on authorization, whereby the system makes a decision to grant or reject access to requested resources from an already authenticated user based on what the user is authorized to do.

Anonymous users are also subject of access control. Although the system is not able to check their identity, authorization checks should be performed just like for any other user or user rule. To make sure that there is no doubt, authorization and authentication are two different things. There are several access control models, but role based access control is the most common one in web applications since it addresses most commercial and government organizations’ needs. Role based access control is defined around roles– such as anonymous user, customer, or admin– and privileges, or what they can do– read, write, update, or delete some resource or execute some function.

This may sound simple, but it tends to become complex when we start adding roles hierarchy or fine-grained privileges. Better than showing complex data flow diagrams, we will exploit different authorization niches in our intentionally vulnerable application. Access control mechanisms of all applications left running in public accessible tend to be broken or outdated, thus easier to exploit. Some applications rely on obscurity to hide administrative end points from regular users, assuming that only admins know the address. Some guesswork and available wordlists and automatic tools are enough to uncover such endpoints. Parameter pollution is a technique that may allow attackers to bypass access control mechanisms just by playing around with URL query string parameters, cookies, or request body.

Some business logic requires actions to be performed in a certain order. Since it should be stateless, then it is up to the backends to track whether those actions are performed in the required order. Messing with actions order may trick the access control mechanism. Accessing other users data may expose sensitive data, such as PII and financial or health records. Compromising admin level functions may expose all user data. If privileged levels do not distinguish users who can only view data, and those who can modify it, then attackers may be able to modify other users’ data, creating some sort of inconsistency or severe data loss. Sometimes, attackers manage to execute actions as other users or even higher level functions.

If the system fails to distinguish malicious activity from legit one, then attackers will be able to perpetrate all sorts of fraud. As with several other flaws we have already discussed, access control ones not only allow attackers to access data, but also execute actions on users behalf. Just considering the confidential or sensitive data exposure issue, you should think about who, individuals or organizations, may benefit from accessing your users’ data. Nation state, competitors, or activists may be among them. The ability to execute actions on users’ behalf is attractive to fraudsters.

Depending on what administrative functionalities your system has, malicious actors may be able to hijack the whole system or take advantage of it to perpetrate other attacks against other systems of yours or even third party ones. You’ll find this table in the OWASP Top 10. Pause the video and take your time to carefully read it. In the next part, we will exploit several access control flaws in order to access some sensitive data and execute administrative functions.