Anyone who deals with IT security comes to this OWASP Top 10 not over. The non-profit organization Open Web Application Security Project (OWASP) publishes this list, which was last updated in 2021 The 10 most critical web application security risks. 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, OWASP for short, is an international non-profit organization that promotes the security of web applications. The work of the OWASP includes several free projects, which deal with the development and testing to the secure operation of web applications. Probably your most famous project: The OWASP Top 10.
OWASP periodically publishes an updated list of the Top ten security risks for web applications. The last Update took place in 2021.
OWASP itself describes the top 10 as an “awareness document” and only the minimum in terms of security that should accompany web applications. For a first introduction to the topic of security in web applications, the TOP 10 are just right. However, if you delve deeper into the topic, you should focus on the projects depending on the application OWASP Web Security Testing Guide (WSTG) or OWASP Application Security Verification Standard (ASVS) as they deal with the topics in more depth.
At the top of the OWASP Top 10 is the Broken Access Control, which we deal with theoretically and practically in this article.
Before we deal with the topic of broken access control, we first have to clarify what access control means with regard to web applications:
An access control describes the rights and restrictions of an object on a resource or an action.
For example, a user should only be able to use their online banking account to access their own accounts and make bookings there. However, access to another user's account should not be permitted.
We divide access control into the following categories:
With regard to access control, we also have to consider authentication and session management, as these represent the starting point for access control.
Now that it is clear what an access control is, it is also clear what is meant by a broken access control or an incorrect access control:
Broken access control occurs when a user is able to bypass vertical, horizontal, or contextual access controls. Put simply, users are given access to sensitive data or allowed to perform tasks they shouldn't be authorized to do.
The OWASP Juice Shop is a web application with many security vulnerabilities. The application is intended to enable anyone to exploit the OWASP Top 10 themselves without committing a criminal offense.
For a better understanding, let's look at three Broken Access Control attacks using the OWASP Juice Shop below.
The OWASP Juice Shop can be installed on Windows, MacOS or Linux or used as a container. The Juice Shop documentation is in English, but still very well described:
Equipment installation OWASP Juice Shop
Attention: The OWASP Juice Shop is an application with a large number of easily exploitable security holes. Therefore, you should install this on a test device that is only accessible to you.
In our case, we chose the Docker container because Docker itself is easy to install and the OWASP Juice Shop container downloads and starts quickly.
When starting the Docker container, it must be noted that the variable
NODE_ENV=unsafe
is handed over so that all Broken Access Control attacks (challenges) can be tried out. 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 security gaps (difficulty level: High). However, we recommend using a proxy server here. You can find out more about this in our Proxy basic article.
In the remainder of the article we will use the Burp Suite Community Edition.
Have you started the OWASP Juice Shop?
Burp Suite Community Edition open?
Do you have both questions with you? Ja answered, we can get started.
In the Burp Suite Community Edition we select, if not already preselected proxy Tab off.
Then we open over Open Browser the browser…
…and go to the website:
http://"Docker-IP":3000
Since we have installed Docker locally, we can reach our juice shop at http://127.0.0.1:3000.
If everything is set up correctly, we will now see the homepage of the OWASP Juice Shop and can start with 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 top left Burger menu and choose About Us .
On this page you can see the existing and already submitted feedback in the slider.
Now let's go over that Burger menu on the side Customer Feedback.
Here we can give our own feedback on the test, which we can provide on the About Us You can then view the page.
Now to enter the Author field or the UserID to manipulate, we catch him POST request to the web server (interception) and change it.
For this we look under the tab in Burp Suite HTTP history first the one made POST request
And then that Response of the web server.
It is noticeable that there is a UserID Field with the value null is available.
This gives us an indication that the server has a UserID needed when providing feedback. We can try this field in the following ones POST request to manipulate. To do this, we start in the Burp Suite tab Intercept with a click on Intercept is off intercepting web requests.
The button is up Intercept is on, we will give feedback again.
We notice that this time we did not receive a pop-up window confirming that we had submitted feedback. This is because we have stopped the web requests through our proxy in order to manipulate them.
To do this, we go back to the Burp Suite and click on the tab Intercept so long on the button Forward, until we get it POST request see our feedback.
We now manipulate this by using the parameter UserID with a value and click the button Forward click. Afterwards we can turn off the interception again and in the tab HTTP history our manipulated POST request look at.
Here we see that the server received our POST with the modified UserID successfully accepted. This means we no longer have the feedback with them UserID null (anonymous) submitted, but as a user with the UserID 2. A successful Broken Access Control.
Another way to solve this challenge is to show the hidden one UserID field on the website Customer Feedback.
To show the hidden field we open via Right click – Investigate which makes Developer tools.
In the rider Elements Let's search for the word using the standard keyboard combination CTRL+F hidden (German hidden).
We are looking for the line:
<input _ngcontent-reo-c122="" hidden="" type="text" id="userId" class="ng-untouched ng-pristine ng-valid">
Once we find the line, we see the field id=”userId” from type=“text”. This one is hidden, so hidden.
We're removing that hidden and we can already see this on the website UserID Field in which we can enter any ID we want: One Broken Access Control.
For this attack we need to log in as a user. To do this, we click on the top right Account and choose Login .
We then log in as users jim
Email address: jim@juice-sh.op
Password: (it doesn't matter, just can't be empty)
The special feature when registering is that we have the password from jim not knowing. That's why we have to do the login via SQL injection. This is done through the addition '‐‐ at the end of the email address.
Declaration: The apostrophe ' ends the string of the email field in the SQL query and the two hyphens - indicate that anything following the two hyphens is a comment. This means the password is commented out in the query.
A blog post on the topic of SQL injection follows.
After successful registration we call up our shopping cart Your Basket .
That's what we're looking for in ours HTTP history in Burp Suite after calling the shopping cart. In the request you notice that in the URL the UserID (in the case of jim = UserID 2) must also be specified.
Let's change these.
To do this, we start the interception in Burp Suite and call the shopping cart Your Basket again.
In the GET request By calling the shopping cart, we can manipulate the parameters or fields, as in the first attack.
We change the URL 2 to a 1 (the admin's UserID) and click Forward. We then stop the interception and look at the result in the browser.
Our shopping cart is now different. And again there is one Broken Access Control .
But we can also see the result again in ours HTTP history look at. There we also see the answer to our manipulated one GET request.
As in the first attack, there is a second possible solution in this challenge.
For this purpose we are opening the again Developer tools and look at us this time in the rider Application unseren Session storage
There we find the parameter bid, which may be for BasketID stands, with the value 2. Since ours User ID 2 is, the most obvious is that the value 2 in bid also in connection with the UserID stands.
We change the value 2 to 1 and reload the shopping cart website.
And this time too we no longer see Jim's shopping cart, but rather the admin's. That means there is one on this path too Broken Access Control .
Our final challenge.
But the procedure at the beginning is the same. We carry out the action that we want to test or manipulate once.
This means we add a product to our shopping cart. We chose them Fruit press .
Then we look at the process in the HTTP history at. By POST request we find that one BasketID is passed.
We're trying to manipulate these again. So we change the parameters and fields while we stop, manipulate and redirect the web call with the interception process. We notice that changing the BasketID doesn't lead us to our goal here.
So we have to have ours POST request in this case manipulate differently. This time, instead of changing a parameter, we add a parameter (HPP = HTTP parameter pollution).
Important: In this Juice shop scenario Please note that the added item is not already in the logged in user's shopping cart. In the attack shown here we have the Fruit press before the interception jim's shopping cart deleted.
After we got the POST passed to the web server, we can use it in the Response of the server in the tab HTTP history a successful Broken Access Control . see
Since we now know how to display 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.
The one suitable Unfortunately, there is no solution for a broken access control because every web application or every access control differs in its implementation. However, there are some points that you can keep in mind:
Suggestion: Since web applications are different and change over time, we recommend regular audits and web application penetration tests to identify faulty Broken Access Control vulnerabilities.
