May 2, 2023
Table of Contents After introducing 3 Broken Access Control Attacks in our first OWASP Top 10 post, we now move on to
Anyone concerned with IT security cannot ignore the OWASP Top 10. The non-profit organization Open Web Application Security Project (OWASP) publishes the 10 most critical security risks for web applications in this list, which was last updated in 2021. At number 1 on this list is Broken Access Control, which we cover in theory and practice in this article. After clarifying the basics, we'll show you 3 Broken Access Control attacks in the OWASP Juiceshop. Finally, we explain how you can protect your web application against such attacks.
The Open Web Application Security Project, or OWASP for short, is an international non-profit organization dedicated to the security of web applications. OWASP's work includes several free projects that address everything from development and testing to the secure operation of web applications. Probably their best known project: The OWASP Top 10.
OWASP periodically publishes an updated list of the ten most critical security risks for web applications. The last update was in 2021.
OWASP itself describes the Top 10 as an "awareness document" and only as the minimum in terms of security, which should go hand in hand with web applications. For a first introduction to the topic of security in web applications, however, the TOP 10 are just right. However, if you want to delve deeper into the topic, you should refer to the OWASP Web Security Testing Guide (WSTG) or OWASP Application Security Verification Standard (ASVS) projects, depending on the use case, as these cover the topics in greater depth.
At the top of the OWASP Top 10 is Broken Access Control, which we address theoretically and practically in this post.
Before we get into the topic of Broken Access Control, we first need to clarify what Access Control means with regard to web applications:
An access control describes the rights and restrictions of an object to a resource or an action.
For example, a user should only be allowed to access his own accounts with his online banking account and make bookings there accordingly. However, access to another user's account should not be allowed.
We divide access control into the following categories:
In terms of access control, however, we also need to consider authentication and session management, as these are the starting points for access control.
Now that we know what an access control is, we can understand what is meant by a broken access control:
A Broken Access Control is when a user is able to bypass vertical, horizontal, or contextual access controls. Put simply, users gain access to sensitive data or are allowed to perform tasks for which they should not be authorized.
OWASP Juice Shop is a web application with a lot of security vulnerabilities. The application is intended to allow anyone to exploit the OWASP Top 10 once themselves without incurring any penalties.
For a better understanding, let's take a look at three Broken Access Control attacks based on the OWASP Juice Shop below.
The OWASP Juice Shop can be installed on Windows, MacOS or Linux or used as a container. The documentation of the Juice Shop is in English, but nevertheless very well described:
Installation OWASP Juice Shop
Warning: OWASP Juice Shop is an application with a lot of vulnerabilities that can be easily exploited. Therefore, you should install it on a test device that is accessible only to yourself.
In our case, we chose the Docker container because Docker itself is easy to install and the OWASP Juice Shop container is quick to download and launch.
When starting the Docker container, it is important to note that the variable
NODE_ENV=unsafe
is passed along so that all Broken Access Control attacks (challenges) can also be tried. This can be done via the Docker Desktop interface:
or you start the container via the shell:
docker run --name juice-shop -e "NODE_ENV=unsafe" -p 3000:3000 bkimminich/juice-shop
Any browser can be used to exploit the vulnerabilities (difficulty level: High). However, we recommend the use of a proxy server. You can read more about this in our Proxy Basics article.
In the rest of the article we will use Burp Suite Community Edition.
Have you started the OWASP Juice Shop?
The Burp Suite Community Edition open?
If you answered yes to both questions, we're ready to go.
In Burp Suite Community Edition, if not already preselected, we select the Proxy tab.
After that we open the browser via Open Browser ...
...and go to the website:
http://"Docker-IP":3000
Since we have Docker installed locally, we can reach our Juice Shop at the address http://127.0.0.1:3000.
If everything is set up correctly, we will now see the OWASP Juice Shop home page and can begin the first challenge.
Note: The following attacks including the solutions can also be found in the OWASP Juice Shop documentation:
In the first step, we click on the Burger menu in the upper left corner and select About Us.
On this page, the slider shows the existing and already submitted feedbacks.
Now we go to the Customer Feedback page via the Burger menu.
Here we can give feedback ourselves once for the test, which we can view on the About Us page afterwards.
Now, to manipulate the Author field or the UserID, we intercept the POST request to the web server (interception) and modify it.
To do this, we first look at the POST request made in Burp Suite under the HTTP history tab.
And then the response of the web server.
You will notice that there is a UserID field with the value zero.
This gives us a hint that the server requires a UserID when submitting feedback. In turn, we can try to manipulate this field in the subsequent POST request. To do this, we start intercepting the web requests in Burp Suite in the Intercept tab by clicking on Intercept is off.
If the button is set to Intercept is on, we provide feedback again.
We notice that this time we did not receive a pop-up window confirming the submission of the feedback. This is because we stopped the web requests through our proxy to manipulate them.
To do this, we go back to the Burp Suite and click the Forward button in the Intercept tab until we see the POST request of our feedback.
We now manipulate this by adding a value to the UserID parameter and clicking the Forward button. After that we can turn off the interception again and view our manipulated POST request in the HTTP history tab.
Here we see that the server has successfully accepted our POST with the changed UserID. This means that we no longer submitted the feedback with UserID null (anonymous), but as a user with UserID 2. A successful Broken Access Control.
Another way to solve this challenge is to display the hidden UserID field on the Customer Feedback web page.
To display the hidden field, we open the Developer Tools via Right Click - Inspect.
In the Elements tab we search for the word hidden using the standard keyboard combination CTRL+F.
We are looking for the line:
<input _ngcontent-reo-c122="" hidden="" type="text" id="userId" class="ng-untouched ng-pristine ng-valid">
When we find the line, we see the field id="userId" of type="text". This is hidden, that is hidden.
We remove the hidden and already we see the UserID field on the web page, where we can enter any ID we want: A Broken Access Control.
For this attack we need to log in as a user. To do this, we click Account in the upper right corner and select Login.
After that we log in as user jim.
E-mail address: jim@juice-sh.op
Password: (doesn't matter, just must not be empty)
The peculiarity of the login is that we do not know the password of jim. Therefore, we have to perform the login via an SQL injection. This is done by adding '-- to the end of the email address.
Explanation: The apostrophe ' terminates the string of the e-mail field in the SQL query and the two dashes -- indicate that everything following the two dashes is a comment. That is, the password is commented out in the query.
A blog post on SQL injection will follow.
After successful registration we call our shopping cart Your Basket.
Then we search our HTTP history in Burp Suite for the shopping cart call. In the request, we notice that the URL includes the UserID (in the case of jim = UserID 2).
Let's change these for a change.
To do this, we start the interception in Burp Suite and call the Your Basket shopping cart again.
In the GET request from the shopping cart call, we can manipulate the parameters or fields, as in the first attack.
We change the 2 in the URL to a 1 (the admin's UserID) and click Forward. Then we stop the interception and look at the result in the browser.
Our shopping cart is now different. And again there is a Broken Access Control .
But we can also have a look at the result in our HTTP history. There we can also see the response to our manipulated GET request.
As in the first attack, there is a second possible solution in this challenge.
To do this, we open the developer tools again and this time look at our session storage in the Application tab.
There we find the parameter bid, which possibly stands for BasketID, with the value 2. Since our user ID is 2, the most obvious thing is that the value 2 in bid is also related to the UserID.
We change the value 2 to 1 and reload the shopping cart web page.
And also this time we don't see jim's shopping cart anymore, but the admin's one. This means that there is a Broken Access Control on this path as well.
Our last challenge.
However, the procedure at the beginning is the same. We execute the action we want to test or manipulate once.
That is, we put a product in our shopping cart. We have chosen the Fruit Press.
Then we look at the process in the HTTP history. In the POST request we notice that a BasketID is passed.
We try to manipulate these again. So we change the parameters and fields while we stop the web call with the interception process, manipulate it and forward it again. We notice that changing the BasketID does not lead us to the goal here.
So we have to manipulate our POST request differently in this case. Instead of a parameter change we add a parameter this time (HPP = HTTP parameter pollution).
Important: In this Juice Shop scenario, note that the added item is not already in the shopping cart of the logged-in user. In the attack shown here, we deleted the Fruit Press from jim's shopping cart before the interception.
After we pass the POST to the web server, we can see a successful Broken Access Control in the server's response in the HTTP history tab.
Since we now know how to view the admin's shopping cart, we can also control our successful attack in the browser: The product Fruit Press is added to the admin's shopping cart.
Unfortunately, there is no one right solution for Broken Access Control, as every web application or access control differs in its implementation. However, there are some points that can be considered:
Recommendation: Because web applications are different and change over time, we recommend performing regular audits and web application penetration tests to identify flawed broken access control vulnerabilities.
Table of Contents After introducing 3 Broken Access Control Attacks in our first OWASP Top 10 post, we now move on to
The status report of the Federal Office for Information Security (BSI) 2022 shows: IT security in the public sector is increasingly
Interview with Christian Rosenzweig (Johner Institute) - Part 2 In the first part of our interview, we asked basic questions about