Access control or authorization of web applications determines how access rules and policies are applied in an application to view content and use functionalities. The rules should define if a user may or may not access specific content. The first step in accessing an application will be the authentication which only indicates who a user is. The second step defines authorization and includes the verification if a user has valid access rights to perform certain tasks.
Access control rights can be different between users. When access rights are compromised or not set correctly, it can lead to unprivileged use of functionalities. This may give unauthorized users the ability to view or delete sensitive content or gain full control of the application.
To have a better insight in access control anomalies, we can divide access control risks into three categories:
• context-dependent privilege escalation.
Each of these categories represent a specific functionality of the web application which can be vulnerable for authorization mistakes.
Vertical access control defines rules which decide if a user has access to specific functions of the application. An admin role may for example delete users while a regular user may not perform these actions. With vertical privilege escalation, a hacker tries to bypass this access policy and obtain more privileges than intended. He can do this for examples by performing API parameter-based attacks, abusing platform misconfigurations or just access sensitive functionality that is not protected sufficiently.
When different users have the same functional rights and access, we speak of horizontal access control. Users are allowed to perform the same actions but are not allowed to view each other’s data. An example for this can be a shopping cart which can be used by any user but only the shopping cart of that specific user can be seen.
Gaining access to other account carts or sensitive data of other users is called horizontal privilege escalation. A hacker could modify and abuse sensitive data of other users or act as if he/she was the user and perform malicious actions on the web application.
The third category in authorization is based on the business flow of an application. This type should restrict access to certain functionalities that are based on the state of the application. A breach in the logical flow of the application can have large consequences and can be exploited. A typical example is that a hacker tries to change a shopping cart after the payment was done, allowing him to bypass the payment system for new products he wants to buy.
Because this security risk has a broad range in exploiting, many actions and guidelines have to be taken into consideration to prevent these security risks:
• Deny by default. A good starting point is that every user has minimal rights and not by default create an administrator that has full access, as such the impact of an attack is reduced
• Log access control failures. When repeatable authorization failures or admin logins come into the logging, an automatic alerting system should be in place
And certainly, the most effective way of monitoring access control anomalies, thorough auditing and testing these features is key, with the emphasis on continuously testing it. At Brightest we have dedicated security testing experts that are always happy to help you with securing your application. Send us an email at email@example.com or via our contact form and we’ll come back to you within 48 hours!
Be sure to read our previous blog posts about OWASP.
Written by Dominique Hendrikx