If you are not already familiar with the concept of Privilege Escalation, we suggest that you review the article entitled “What Is Privilege Escalation ?“.
For insights into how to detect Privilege Escalation vulnerabilities, please see the article entitled “How To Test For Privilege Escalation“.
Since Privilege Escalation vulnerabilities are the result of the failure to verify that the user has the authority to perform a requested action, prevention boils down to verifying permissions.
Checking Permission By Role
The application must know what role (or roles) the current user is associated with as well as what commands, actions, or requests they can submit. Note that this is a positive (whitelist) model that represents a “deny by default” design approach. Simply put, if a permission is not listed, then it is not available.
Application permissions can be thought of as a “role/permissions matrix”:
| Perm 1 | Perm 2 | … | Perm N | |
| Role 1 | X | |||
| Role 2 | X | |||
| : | ||||
| Role N | X |
Where each role represents a “class” of user enjoying a common set of permissions, and each permission represents a potential command, request, or action that a user might potentially initiate. The presence of an ‘X’ would indicate the role enjoys the permission whereas the absence of an ‘X’ would indicate the absence of that permission.
The above “role/permissions matrix” would be accompanied by a mapping of user accounts to roles (i.e. a users/roles matrix):
| Role 1 | Role 2 | … | Role N | |
| User 1 | X | |||
| User 2 | X | |||
| : | ||||
| User N | X |
Where each user is identified as being associated with one or more roles.
Now when a user submits a command, request, or action to the application, the application need only check whether the permission is granted for one of the roles associated with that user.
Other Vectors
Even with properly implemented permissions checking, it is still possible to “drop the ball” in other ways. Clearly, the role/permissions matrix and user/roles matrix should be configurable outside the application and stored in a secure manner with role-based access control. The insecure storage of the role. permission, or user information used by the application can render permissions checking a moot point. Also, any misconfiguration of that same information can lead to Privilege Escalation, even if the application itself is properly checking permissions.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.