(Not) Easy authorization

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.