Broken Access Control

Access control tells us whether the logged in user is allowed to carry out the action, that they are attempting to perform.

=> Vetical AC => Horizontal AC => Context-dependent AC

Vertical Access Control

These access control models restrict access to sensitive functionality that is not available to other users.

An administrator might be able to modify or delete any user's account, while an ordinary user has no access to these actions.

Horizontal Acess Control

These access control models restrict access to resources to the users who are specifically allowed to access those resources.

A banking application will allow a user to view transactions and make payments from their own accounts, but not the accounts of any other user.

Context-dependent Access Control

These access control models restrict access to functionality and resources based upon the state of the application or the user's interaction with it.

A retail website might prevent users from modifying the contents of their shopping cart after they have made payment.

Broken Access Control

Broken access control vuln exists when there is no restriction between the user's end and the application, which means a normal user can perform tasks which he's not restricted to.

IDOR - Indirect Object Reference

IDOR - Insecure Direct Object Reference

This vulnerability arises when an application uses user-supplied input to access objects.

The attacker can modify the input to obtain UNAUTHORIZED access to pages or any sensitive information.

Insecure Direct Object Reference

This lab stores user chat logs directly on the server's file system and retrives them using url's

Login using weiner:peter and try to tamper the ?username=carlos, so that any password leaks are possible.

There's a new option available called live chat, which enables us to text with a bot and when we try to view the transcript, our conversation with the bot gets downloaded in a .txt format.

It gets downloaded in an incrementing order. Now when we intercept any one request and try to tamper the .txt to 1.txt, we get a text file which leaks the password for carlos.

PortSwigger Exercises

Access control in multi-step processes

Modern Access Control Systems depends on a series of steps :

Loads the form containing details of a regular user

Submit changes

Review changes and confirm

Suppose some control systems are correctly applied to the first and second steps, but not to the third step.

The website's logic will be like, if the user completes the first two steps[ which are properly controlled ] only then he'll reach the third step.

Here the attacker can easily bypass the first two steps and directly jump to the third step with the required parameter.

PortSqigger Exercises

Logging in with the admin credentials will let us to upgrade a normal user to attain admin privileges.

Upgrading the carlos user to admin, send the confirmation POST request to the repeater.

Now logging in using a normal user's creds and sending any GET or POST request to the repeater, just to note down the Session-Cookie ID.

Now replace the cookie in the POST request [In the second step], with the normal user's cookie and forward the request. This will give us admin privileges.

Referer-Based access control

Some access controls are based on Referer header submitted in the HTTP request.

The Referer header is added to the requests by the browser to indicate the page from which a request was initiated.

Suppose a website checks only for the /admin, and not what appends after that - /admin/deleteUser only inspects the Referer header.

If the Referer header contains the main /admin URL, then the request is allowed.

PortSwigger Exercises