Broken Access Control
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 users access to some resources, but not others. These resources mostly fall into two categories: sensitive data, which should only be accessed by select users, 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, they must first authenticate themselves, i.e. log in, then if they try to gain access to a resource, the server checks whether or not they are authorized to do so.
Examples of broken access control
- Insecure ID’s: When looking for something in a database, most of the time we use a unique ID. Often, this ID is used in the URL to identify what data the user wants to get. Let’s say I’m logged in to a website, and my user ID is 1337. When I go to my own profile page, the URL looks something like this:
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 another page, say
https://example.com/profile?id=42, then I will get the profile page of another user, with all of their sensitive data. How do I know the ID of another user, you might ask. Well, using random user IDs that are kept secret makes it 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 better 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.
- Forced browsing: Forced browsing is when the user tries to access resources that are not referenced by the application, but still available. For example, a web application might have an admin page, but there is no link to the admin page on other parts of the website, a regular user won’t find to the admin page by simply clicking around. But if someone directly edits the URL, e.g. visit
https://example.com/admin, they might access the admin page if the access control is broken.
- Directory traversal: When a website stores data in different files, the server might expect a filename as a request parameter. E.g. if there is a web application for reading short novels, the URL might look like this:
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 repeated pattern 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 is another potential solution..
- Client side caching: Browsers store websites in their cache to ensure faster loading if the user tries to access the same website again. This might be a problem if multiple people use the same computer, e.g. in a library or an internet café. Developers should prevent browsers from storing sensitive data in their cache. This can be accomplished by for example using HTML meta tags.
How can you find it in your application?
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.
The impact of broken access control
Depending on the specific vulnerability, the consequences can be devastating. The worst case scenario is when an unauthorized user has access to a privileged function. This can give them the ability to modify or delete contents on the website, or even worse, gain full control over the web application.
Share this post on social media!
We’d also love to hear your thoughts. Leave a comment below if you have any questions or feedback, or let us know what cybersecurity topic you’d like to read about next!
Reading Time: 9 minutes Understanding serialization and deserialization vulnerabilities is the first step toward building secure applications. For most developers, it’s a challenge to find the right balance between coding securely and meeting other objectives like tight deadlines. This often results in products that are vulnerable to deserialization attacks which would be otherwise difficult to stage.
Reading Time: 8 minutes The purpose of this post is to present one of the most popular authorization manager open standards JWT. It goes into depth about what JWT is, how it works, why it is secure, and what the most common security pitfalls are.
Reading Time: 8 minutes Software development and application security go hand-in-hand. We asked the CISO of Skyscanner about this crucial relationship.
Copyright © 2022 Avatao