In this article we cover examples of broken access control, how to find it in your application and possible consequences.
Access control, or authorization, is how a web application grants access to resources to some users, and not others. These resources mostly fall into two categories: sensitive data, which should only be accessed by certain entities, and functions that can modify data on the webserver, or even modify the server’s functionality. Authorization checks are performed after authentication: when a user visits a webpage, first they have to authenticate themselves, i.e. log in, then if they try to gain access to a resource, the server checks if they are authorized to do so.
https://example.com/profile?id=1337. This page might contain sensitive data, which nobody else should see. But what if I replace the ID with another user’s ID? If the webserver is configured improperly, then if I visit e.g.
https://example.com/profile?id=42, then I will get the profile page of another user, with every sensitive data. You might ask how do I know the ID of another user? Well, if the user IDs are random and kept secret, then it’s a bit harder, but this is not nearly enough defense. This is a good example of ‘security by obscurity’, which is widely considered bad practice. The good solution is to implement proper access control in the server, so it does not serve the user with the requested data if they are not authorized to access it.
https://example.com/admin, they might access the admin page if the access control is broken.
https://example.com/novels?file=novel1.txt. On the server side, there is probably a folder where all novels are stored, and the server looks for the given file name in this folder. An attacker could abuse this behaviour for example by visiting the URL
https://example.com/novels?file=../../../../../../etc/passwd. The lots of
../-s will eventually reach the root directory, and the attacker can access any file from there. In order to defend against this attack, the webserver should be configured in such way that it has no access to the files that it does not need. Filtering for
..in the input parameter could also work.
First, you need a well documented access control policy, otherwise you cannot decide what should be considered broken access control. A detailed review of the code that implements the access control should reveal some of the vulnerabilities. Also, penetration testing might help. These vulnerabilities are not too hard to find, often it is enough to craft a request for a resource that should not be accessed.
Depending on the exact vulnerability, the consequences can be devastating. The worst case scenario is when an unauthorized user has access to some privileged function. This can give them the ability to modify or delete contents on the website, or even worse, they might gain full control over the web application.
Try our challenges related to this topic in the Secure coding in Python path on AvataoNext.