Forced Browsing - An Overview
Imagine the following scenario! You are an application owner who meticulously reviewed the application architecture before overseeing the development of the entire application. You know it’s a critical e-commerce application which would be used by millions enthusiastically and extensively to shop online, be it the fashion or clothing accessories.
Besides spending many sleepless nights on ensuring the functionality and usability of the application, you have spent sufficient time training your team to develop the same kind of perception towards customer experience because you have always thought, “A satisfied customer is the best business strategy of all!”
The very next day your application is going live and you are very excited about it. At the 11th hour, one of your team members comes to you to tell that you all had ‘overlooked’ something. She understands the perplexed look on your face and goes on to explain further. She tells you that she was able to access the ‘admin’ page just by modifying the URL when she tried 'playing' around the application. Now will that startle you? Will you delay the launch of the product to fix this critical issue?
You have to! This web application vulnerability is called ‘forced browsing’. How is it dangerous? You are allowing a user to access all critical and sensitive information of a website which are not referenced anywhere just by modifying the URL by trial and error method. This can also be referred to as ‘File Enumeration’ or ‘Directory Enumeration’.
For example, let’s assume the e-commerce website is www.myshop.com and it’s vulnerable to this attack.
A user with malicious intent could try out the following by manually modifying the URL:
What will happen if the attacker is able to view the ‘admin’ login page? She could try to execute bruteforce attacks to guess the username and password of the administrator which are, in most of the cases, admin/admin or admin/password or admin/admin123. If one of these works, the attacker would have elevated privileges as those of the administrator.
www.myshop.com/images/architecture.jpg
What will happen if the user tries to access the above URL? She would gain access to the underlying architecture of your application. That definitely is going to put you through some rough times.
What would be the impact if she can access the files in the ‘Logs’ folder? Access to all the events, errors, informational events and warnings. That sounds like juicy information to the attacker!
www.myshop.com/pages.php/authenticated=yes
What's the big deal with this? An attacker can authenticate himself in the application just by changing the authentication from 'no' to 'yes'. Let's deal with the issues in authentication procedures in another post.
Now how are you going to fix this? You could choose to apply the following to prevent such types of attacks:
1. Enforce role-based authentication and authorization: This restricts what a person can view depending on their roles. For example, a user may not be able to access the ‘admin’ page.
2. Focus on Access Control List: This is a list of permissions attached to an object, specifying which user can access what and perform which operation.
3. Authentication: Enforce authentication before any critical and secure operation. The level of risk you would take would be high if you don’t apply this.
4. Common names for critical files and user accounts: This is what encourages brute forcing attacks. Next time, think about something unpredictable while naming these files, directories and accounts.
While beginning to test, review the directory structure and the list of files residing inside. It’s important that you test all the security controls against different directories and files. I am sure there are many more ways to prevent this attack. You can share those in the comments section!
Principle of least privilege often overlooked at various levels. We need to always ensure this principle is followed across different boundaries of application.