c{api}tal (Checkmarx API Training and Learning) is a purpose-built vulnerable API application based on the OWASP API Top 10 risks. It is built with Python (FastAPI – a quick and easy to use web framework for developing RESTful APIs in Python) and JS (React), and it includes 10 API security challenges.
c{api}tal was created by the Checkmarx Research team to provide users with a “playground” so they could learn and develop their API Security skills. It can be used to learn and exploit API Security vulnerabilities and for conducting your own API Security Capture The Flag (CTF) event.
In computer security, Capture the Flag (CTF) is an exercise in which “flags” are secretly hidden in purposefully vulnerable programs or websites. The goal is to complete challenges as fast as possible, get the highest score, and win the competition. Visit capital-ctf.com to learn about the vulnerabilities and the challenges.
We first introduced C{api}tal to the application security (AppSec) community at 2022 AppSec Village at DefCon30. It was an amazing experience! Dozens of users participated in the event, while only 6 of them were able to complete the 10 API challenges.
We think of all participants as winners for being able to up-level their security skills (why we were all at DefCon), but we obviously must pick 3 for the contest. Full credit goes to the winners:
Once the event ended, many awesome write-ups were done by security analysts and researchers who took part in the CTF event. One great example is this medium write-up by Maor Tal.
Digging into API risks
c{api}tal is a vulnerable, blogging application that allows users to register, create and delete posts, create and delete comments, follow other users, and more. The application can be built and deployed by running a simple docker-compose command:
docker-compose up –d Some of the API endpoints in c{api}tal can be seen here:
The application contains 10 risks that align to the OWASP API Top 10 Risks:
- Broken Function Level Authorization
- Broken Object Level Authorization
- Broken User Authentication
- Improper API Management
- Excessive Data Exposure
- Improper Assets Management
- Lack of Resources and Rate Limiting
- Security Misconfigurations
- Injection
- Mass Assignment
- Security Misconfiguration
- Insufficient Logging
In this blog, we will cover Broken Object Level Authorization (AKA BOLA) and Mass Assignment challenge.
Broken Object Level Authorization
Object level authorization is an access control mechanism that is usually implemented at the code level to validate that only one user can access objects that they should have access to.
Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object-level authorization checks. The checks should validate that the logged-in user does have access to perform the requested action on the requested object. Failures in this mechanism typically lead to unauthorized information disclosure, modification, or destruction of all data. In simple words, BOLA allows a user to have access to fetch/update/delete any resource that they should not have access to.
How to exploit BOLA in a vulnerable application? Let’s look at this example.
This application contains an article written by “Blastoise”, which announces that “Whoever comments first will get 1,000,000$ from Pikachu”. Going into the article, we can see it received two comments as shown below:
As you can see, “Bob_the_dev” was second to comment in this article, and he wished he was the first to comment. Let’s demonstrate how we can take advantage of a BOLA vulnerability to make Bob_the_dev number 1.
We would like to try to delete the first comment of “Blastoise”, an action which we should not be able to perform if BOLA mitigation is in place.
PoC demonstrating a BOLA exploit:
We successfully deleted “Blastoise’s” comment while being authenticated to another user, which means the application is vulnerable to BOLA and we got the flag!
How is Bola allowed in the application?
What we can see is a snippet of the application code, where the
delete comment routeand
delete_comment_from_article function is defined.
We can see the code does not contain a check for the user who requests to delete the comment, and therefore, any (authenticated) user is able to delete any comment, even if it is not their own.
Mitigation
The way to mitigate this type of risk is to have a proper check of the user who tries to access/update/delete any resource in the application. In case they are not the user who should have access to this resource, the application should block the request.
if comment.author != current_user:
raise HTTPException(
status_code = status.HTTP_403_FORBIDDEN,
details = “Forbidden”
)Mass Assignment
An API endpoint is vulnerable if it automatically converts client parameters into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.
How to exploit Mass Assignment in a vulnerable application?
When a user tries to register/login to the application, the response the application returns with contains one interesting field that should not be there—“admin” parameter.
A default user in the application is not an admin, so why don’t we try to change that?
PoC demonstrating Mass Assignment exploit:
How is Mass Assignment allowed in the application?
Here is a snippet of the application code where the user profile returns the “status” of the user in terms of admin permissions as a new parameter in the response – “admin”. We can see the code does not restrict users from modifying such parameters, so any user could update his profile and modify his admin permissions:
We were able to modify the user’s permissions and now the user is an admin! And in the context of the CTF event, of course, we got the flag as well.
Mitigation
The way to mitigate such risk is not to expose sensitive properties and not allow users to update object properties that they should not have access to.
Final Thoughts
APIs are a critical part of modern mobile, SaaS (Software as a Service), and web applications and can be found in customer-facing, partner-facing, and internal applications. By nature, APIs expose application logic and sensitive data, potentially leading to data breaches, account takeovers, and much more. Because of this, APIs have increasingly become a target for attackers.
Without secure APIs, organizations would face many security risks and rapid innovation would be impossible. Therefore, it is extremely important to be aware of the OWASP API Top 10 risks and enforce proper API security mitigations for your APIs.
To help developers and AppSec teams improve their API security skills, Checkmarx researchers developed c{api}tal, which again, is a built-to-be-vulnerable API application based on the OWASP top 10 API risks.
Feel free to use c{api}tal to learn, train and exploit API Security vulnerabilities within your own API Security CTF event. c{api}tal will soon be available as an open-source project on GitHub! We encourage you all to be proactive and sharpen your API security and overall code security skills!
To learn more about Checkmarx approach to API security, and overall application security testing, request a demo of our Checkmarx One™ Application Security Platform today. Or sign up for a 14-day free trial here.
