This website uses cookies

To provide the highest level of service we use cookies on this site.
Your continued use of the site means that you agree to their use in accordance with our terms and conditions.

Pentest Chronicles

(Not) Easy authorization

Jacek Siwek

March 14, 2025

Introduction

Vulnerabilities from the broken access control group according to OWASP TOP TEN 2021 are among the most common in web applications. They give users with lower privileges the ability to, among other things, access data or functions that are not intended for such a role. It also happens that an ordinary user can use functionalities belonging to the administrator, which can also lead to privilege escalation.

Sometimes, these vulnerabilities are unusual in nature because they are not always related to flaws in the application logic... In such cases, testing should also include more complex scenarios that go beyond the classic approach.
Authorization implementation examples:

The use of security implementation approaches and practices varies. Below are some incorrect implementations:

- Hiding functionality in the GUI - if the user does not see the button, he does not have access to the application's functionality.
- No session verification - a user who knows the application endpoints can perform any actions by sending direct requests to the API, because only the active session is verified, not the assigned role.

- Authorization based on the ``Referrer`` header - A regular user can easily modify the header value and perform actions that should be restricted.

- Disabling buttons - the user sees the button in the GUI, but cannot click it. After removing the `disabled` parameter, the user gains access to the function.

- No separation of roles - despite differences in assumptions, a regular user has access to some of the administrator's functionality.

There are also complex authorization vulnerabilities that are not obvious and their discovery requires a deeper analysis of the problem. One such case is described below, which was discovered during penetration testing at the time of verification of newly assigned session tokens, and specifically whether a regular user can provide their own cookie value, which will then be used to create a new session after logging in and whether the session is correctly invalidated upon logout. In the scenario, session verification was combined with checking the assigned permissions (access to the tab and functionalities located under the /admin path).
Real-word case assumptions - There are several roles in the application: a regular user (login: Test) and an administrator (login: Admin).
- A regular user should not have access to administrative functionalities.
Scenario: 1. The user *Test* logs into the application.
2. He receives the following session ID: “Cookie: foo=test”.
3. He sends the following HTTP request to verify that he also has access to the administrator functionality:
4. In response, he is redirected to the application's main page, where the lack of access due to the privileges of a regular user is confirmed: 5. User *Test* logs out of the application.
6. His session ID “Cookie: foo=test'” becomes inactive, which is the correct behavior of the application.
7. User *Test* logs back In and obtains a new session ID: “Cookie: foo=test_1”.
8. He resubmits the HTTP request to verify access to administrative functionalities: 9. In response, he is once again redirected to the main application page: 10. User *Test* uses the session ID assigned during the first login (point 2) and sends the HTTP request again to check if the application engine has not reused it for a new session: 12. In response, data intended for the administrator is returned, which confirms privilege escalation and incorrect session management. This confirms incorrect session token management and the existence of an authorization vulnerability: In this way, a regular user had full access to all application data and functions, such as keys and passwords used for integration, lists of all application users and the ability to fully edit their data (including administrators) and add new ones. The user could also change all application settings available from the API level without having the appropriate permissions. The inactive session identifier only gained elevated permissions after the next login, highlighting that the vulnerability is not directly related to application logic or design assumptions.
Recommendations - A user should be able to access only the resources that he or she owns.

- It is advisable to use one central authorization module and implement the application so that all operations performed in the application pass through it.

- During penetration tests, scenarios that are not directly related to the application logic should also be verified.



Next Pentest Chronicles

When Usernames Become Passwords: A Real-World Case Study of Weak Password Practices

Michał WNękowicz

9 June 2023

In today's world, ensuring the security of our accounts is more crucial than ever. Just as keys protect the doors to our homes, passwords serve as the first line of defense for our data and assets. It's easy to assume that technical individuals, such as developers and IT professionals, always use strong, unique passwords to keep ...

SOCMINT – or rather OSINT of social media

Tomasz Turba

October 15 2022

SOCMINT is the process of gathering and analyzing the information collected from various social networks, channels and communication groups in order to track down an object, gather as much partial data as possible, and potentially to understand its operation. All this in order to analyze the collected information and to achieve that goal by making …

PyScript – or rather Python in your browser + what can be done with it?

michał bentkowski

10 september 2022

PyScript – or rather Python in your browser + what can be done with it? A few days ago, the Anaconda project announced the PyScript framework, which allows Python code to be executed directly in the browser. Additionally, it also covers its integration with HTML and JS code. An execution of the Python code in …

Any questions?

Happy to get a call or email
and help!