OWASP Top 10 - Broken Access Control

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.

Table of Contents

Basics: OWASP Top 10 and Broken Access Control

What is OWASP?

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.

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.

How secure is your web application?
Are you prepared against all OWASP top 10 security risks?
To the Web Application Penetration Test

A01:2021 - Broken Access Control

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:

  • The horizontal access control: Horizontal access controls are mechanisms that limit users' access to the resources for which the users are authorized. This includes the online banking scenario just described.
  • The vertical access control: Vertical access controls are used to limit access to important features that should not be available to other types of users. This means that different types of users have access to different application features. For example, an administrator can change or delete any user's account, while a regular user does not have access to these actions.
  • Context-dependent access control: Contextual access controls restrict access to features and resources based on a user's state or interaction with the application. For example, contextual access control prevents a user from performing actions in the wrong order and changing the contents of their shopping cart on a shopping website after they have already purchased the goods.

With regard to access control, we also have to consider authentication and session management, as these represent the starting point for access control.

  1. The authentication the user logs in to be authorized.
  2. By the Session management This ensures that subsequent HTTP requests come from the same user because the Internet protocol HTTP is stateless. This means that as soon as a request from a client has been processed by the web server, the connection is terminated again. However, since a user does not want to re-enter their login information on every new page accessed, the information must be stored, transported and verified in some way.

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.

Practical test OWASP Top 10: Broken Access Control Attacks

What does the OWASP Juice Shop have to do with the OWASP Top 10?

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.

  1. Attack: Post some feedback in another user's name. (Eng. Attack: Post feedback on behalf of another user.)
  2. Attack: View another user's shopping basket. (Eng. Attack: View another user's shopping cart.)
  3. Attack: Put an additional product into another user's shopping basket. (Eng. Attack: Add an additional product to another user's shopping cart.)

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:

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.

3 Broken Access Control Attacks in the OWASP Juice Shop

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.

Burp Suite Community Edition “Proxy” Tab

Then we open over Open Browser the browser…

Burp Suite Open 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.

Owasp Juice Shop

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:

Attack 1: Post some feedback in another user's name.

Possibility 1

In the first step we click on the top left Burger menu and choose About Us .

OWASP Top 10
OWASP Juice Shop

On this page you can see the existing and already submitted feedback in the slider.

OWASP Juice Shop

Now let's go over that Burger menu on the side Customer Feedback.

OWASP Juice Shop

Here we can give our own feedback on the test, which we can provide on the About Us You can then view the page.

OWASP Juice Shop
OWASP Top 10

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

Burp Suite under the “HTTP history” tab

And then that Response of the web server.

It is noticeable that there is a UserID Field with the value null is available.

Web server response

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.

Burp Suite in the “Intercept” tab

The button is up Intercept is on, we will give feedback again.

If the button is set to “Intercept is on”, we provide feedback again.
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 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.

Burp Suite “Intercept” tab

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.

Parameter “UserID” Button “Forward”

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.

A successful Broken Access Control.
Possibility 2

Another way to solve this challenge is to show the hidden one UserID field on the website Customer Feedback.

“UserID” field on the “Customer Feedback” website.

To show the hidden field we open via Right click – Investigate its general Developer tools.

“Right click - Examine” the “Developer Tools”.
OWASP Juice Shop

In the rider Elements Let's search for the word using the standard keyboard combination CTRL+F hidden (German hidden).

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">
				
			

Once we find the line, we see the field id=”userId” from type=“text”. This one is hidden, so hidden.

We remove the “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.

Broken Access Control
Broken Access Control

Attack 2: View another user's shopping basket.

Possibility 1

For this attack we need to log in as a user. To do this, we click on the top right Account and choose Login .

OWASP Juice Shop
OWASP Juice Shop 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.

OWASP Juice Shop Login
OWASP Juice Shop shopping cart “Your Basket”

After successful registration we call up our shopping cart Your Basket .

OWASP Juice Shop 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.

“HTTP history” in Burp Suite

Let's change these.

To do this, we start the interception in Burp Suite and call the shopping cart Your Basket again.

OWASP Juice Shop shopping cart “Your Basket”

In the GET request By calling the shopping cart, we can manipulate the parameters or fields, as in the first attack.

OWASP Juice Shop shopping cart “Your Basket”

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.

OWASP Juice Shop shopping cart “Your Basket”

Our shopping cart is now different. And again there is one Broken Access Control .

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.

HTTP history
Possibility 2

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

Developer tools Application Session Storage tab

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.

Change the value 2 to 1 once

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 .

Broken Access Control

Attack 3: Put an additional product into another user's shopping basket.

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.

Fruit press

This means we add a product to our shopping cart. We chose them Fruit press .

Fruit press

Then we look at the process in the HTTP history at. By POST request we find that one BasketID is passed.

POST Request “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.

“Fruit Press” deleted from jim's cart before the interception
“Fruit Press” deleted from jim's cart before the interception

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

Broken Access Control

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 product “Fruit Press” is added to the admin’s shopping cart.

OWASP Top 10 Solution: How to protect your web application from broken access control attacks

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:

  1. The implementation of access controls throughout the web application
  2. A developed and documented role, rights and auditing concept
  3. Clean logging of errors
  4. Session cookies should be invalidated on the server after you log out
  5. Stateless JWT tokens should be rather short-lived
  6. Following OAuth standards
  7. Raising awareness among developers
  8. The implementation and configuration of a Web Application Firewall (WAF)

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.

Do you need help hardening your web app?
We find all security gaps for you and guide you through closing them.
To the Web Application Penetration Test
Follow for more!
Newsletter Form

Become a Cyber ​​Security Insider

Get early access and exclusive content!


By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!
OTHER CONTRIBUTIONS

Table of Contents

PSN_KU_Cover
NewsLetter Form Pop Up New

Become a Cyber ​​Security Insider

Subscribe to our knowledge base and get:

Early access to new blog posts
Exclusive content
Regular updates on industry trends and best practices


By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!