Access Controls

Access controls is the application constrain on who or what is authorized to perform actions or access resources. There are three types of access controls they are:

Vertical Access Control

These restrict access to sensative functionality to specific type of users. Here different types of users have access to different application functionality and one user might not be able to access functionality of another user. For example: an administrator user might be able to modify or delete any user's account but a normal user might not be able to access or modify or delete other user's account.

Horizontal Access Control

Horizontal acess controls are mechanisms that restrict access to resource to specific users. For example: an administrator might be able to view all the application logs but a normal user might not be able to do it. If an employee is able to records of other employees as well as their own this is horizontal access control issue. IDOR falls under horizontal privilege escalation.

Context dependent access controls

Context dependent access controls restrict users access to functionality or resource based upon the state of the application or the user's interaction with it. For example: a retail website might prevent users from modifying the contents of their cart after they have made the payment.

Vertical Privilege Escalation

A normal user might be able to access administrator endpoint eg /administration-portal via endpoint exposed via robots.txt file, some javascript files or simply bruteforcing.
Even if the endpoint is not guessable it might be leaked via some javascript file.
Some applications determine the user's access rights or role at login and then store this information in a user controllable location like a hidden field, a cookie, a query parameter, etc a user might always be able to modify the value and get access to restricted functionalities or resources.
IF an appliation enforces access control like DENY: POST, /admin/deleteUser, managers which restricts users in manager group to send POST request to /admin/deleteUser endpoint however if application accepts http headers like X-Original-URL, X-Rewrite-URL we may be able to bypass the access control via

POST / HTTP/1.1
X-Original-URL: /admin/deleteUser

Maybe access control restriction is based upon http methods? example from a normal account we may not be able to use an administrative functionality to delete a user like

POST /admin-functionality

username=alex&role=admin

but we may be able to change the http method and use the functionality like GET /amdin-finctionality?username=alex&role=admin

Maybe /admin/deleteuser is restricted but /ADMIN/DELETEUSER is accepted because the application is case in sensative.
Maybe /admin/deleteuser is forbidden but /admin/deleteuser/ is not?

Horizontal Privilege Escalation (IDORS)

Maybe changing the value in url parameter or some other locations allows access to resource? eg: /GET/apikey?username=wiener => GET /apikey?username=carlos, GET /accountdetails?id=1 => GET /accountdetails?id=2
The application might use GUIDs for identifying users which are unique and unguessable but the GUIDs may be leaked in other parts of the application? maybe the user has made some comment, written blog post maybe we can somehow view their profile or anything and find their GUID?
Sometimes substituting the value might cause redirect to login or automatically logout but the redirect response might contain the needed information
An example a website might save pdf documents uploaded by user as https://insecure-website.com/static/12144.pdf here simply an attacker can access pdf uploaded by other users incrementing or decrementing the filename value.
In some applications completing a functionality might involve multiple steps, access controls may be placed correctly on first or second step but might not be implemented correctly on third step because the application assumes that the third step will only be reachable after completing first and second step in this case an attacker can directly access third step to complete a functionality. eg: in a banking application sending money to an acount results in below request

POST /send-money

accountNumber=12345&amount=500

After this the application may proceed with confirmation of amount and number in frontend website it may show "are you trying to send 500 to 123?" and if we press yes another request may initiate

POST /confirm

accountNUmber=12345&confirmed=true&amount=500

Here, proper access control might be in place on first request but not on the second request resulting into an attacker directly crafting and sending the second request

Some websites place access controls based upon referral headers. The Referral header can be added to requests by browsers to indicate which page initiated a request. For eg: for functionality residing at /admin/deleteUser, /admin/modifyWebsite the application may check only the referral header if it contains /admin url the request is allowed. In this case, the Referer header can be fully controlled by an attacker. This means that they can forge direct requests to sensitive sub-pages by supplying the required Referer header, and gain unauthorized access.
Some websites enforce access controls based on the user's geographical location. This can apply, for example, to banking applications or media services where state legislation or business restrictions apply. These access controls can often be circumvented by the use of web proxies, VPNs, or manipulation of client-side geolocation mechanisms.

PreviousInformation disclosure NextFile upload Attacks

Last updated 10 months ago

Vertical Access Control

Horizontal Access Control

Vertical Privilege Escalation

A normal user might be able to access administrator endpoint eg /administration-portal via endpoint exposed via robots.txt file, some javascript files or simply bruteforcing.

Even if the endpoint is not guessable it might be leaked via some javascript file.

Some applications determine the user's access rights or role at login and then store this information in a user controllable location like a hidden field, a cookie, a query parameter, etc a user might always be able to modify the value and get access to restricted functionalities or resources.

IF an appliation enforces access control like DENY: POST, /admin/deleteUser, managers which restricts users in manager group to send POST request to /admin/deleteUser endpoint however if application accepts http headers like X-Original-URL, X-Rewrite-URL we may be able to bypass the access control via

POST / HTTP/1.1
X-Original-URL: /admin/deleteUser

Maybe access control restriction is based upon http methods? example from a normal account we may not be able to use an administrative functionality to delete a user like

POST /admin-functionality

username=alex&role=admin

but we may be able to change the http method and use the functionality like GET /amdin-finctionality?username=alex&role=admin

Maybe /admin/deleteuser is restricted but /ADMIN/DELETEUSER is accepted because the application is case in sensative.

Maybe /admin/deleteuser is forbidden but /admin/deleteuser/ is not?

Horizontal Privilege Escalation (IDORS)

Maybe changing the value in url parameter or some other locations allows access to resource? eg: /GET/apikey?username=wiener => GET /apikey?username=carlos, GET /accountdetails?id=1 => GET /accountdetails?id=2

The application might use GUIDs for identifying users which are unique and unguessable but the GUIDs may be leaked in other parts of the application? maybe the user has made some comment, written blog post maybe we can somehow view their profile or anything and find their GUID?

Sometimes substituting the value might cause redirect to login or automatically logout but the redirect response might contain the needed information

An example a website might save pdf documents uploaded by user as https://insecure-website.com/static/12144.pdf here simply an attacker can access pdf uploaded by other users incrementing or decrementing the filename value.

In some applications completing a functionality might involve multiple steps, access controls may be placed correctly on first or second step but might not be implemented correctly on third step because the application assumes that the third step will only be reachable after completing first and second step in this case an attacker can directly access third step to complete a functionality. eg: in a banking application sending money to an acount results in below request

POST /send-money

accountNumber=12345&amount=500

After this the application may proceed with confirmation of amount and number in frontend website it may show "are you trying to send 500 to 123?" and if we press yes another request may initiate

POST /confirm

accountNUmber=12345&confirmed=true&amount=500

Here, proper access control might be in place on first request but not on the second request resulting into an attacker directly crafting and sending the second request

Some websites place access controls based upon referral headers. The Referral header can be added to requests by browsers to indicate which page initiated a request. For eg: for functionality residing at /admin/deleteUser, /admin/modifyWebsite the application may check only the referral header if it contains /admin url the request is allowed. In this case, the Referer header can be fully controlled by an attacker. This means that they can forge direct requests to sensitive sub-pages by supplying the required Referer header, and gain unauthorized access.

Some websites enforce access controls based on the user's geographical location. This can apply, for example, to banking applications or media services where state legislation or business restrictions apply. These access controls can often be circumvented by the use of web proxies, VPNs, or manipulation of client-side geolocation mechanisms.