Security Code Challenge for Developers & Ethical Hackers – The Damn Vulnerable RESTaurant

April 1, 2024

Introduction to a security code challenge dedicated to developers and ethical hackers. This challenge focuses on identifying and fixing web API security vulnerabilities in a Python FastAPI-based restaurant API.


Introduction

Damn Vulnerable RESTaurant is an intentionally vulnerable API service designed for learning and training purposes dedicated to developers, ethical hackers and security engineers. The project’s goal is to provide an environment that can be easily extended with new vulnerable endpoints and mechanisms that could be utilised in training sessions focused on detecting and exploiting identified vulnerabilities. The vulnerabilities cover the most popular API issues, including those listed in the OWASP Top 10 API Security Risks 2023.

It serves as a learning and training playground:

  • For Developers — engage in a dedicated game where you will identify and fix vulnerabilities interactively.
  • For Ethical Hackers — exploit vulnerabilities manually or use automated tools. Treat it as a CTF challenge, you can start from a low privileged API user and escalate to a root user — there is more than one path to achieve this. API documentation is provided to support your hacking adventure.
  • For Security Engineers — utilise various security automation tools such as SAST, DAST, IaC, etc., to test vulnerability detection mechanisms.

This challenge is particularly beneficial for Python developers and can be included as part of Security Champion and Developer Security Awareness Programs. Damn Vulnerable RESTaurant is available on GitHub:

If you’d like to learn more about API security, take a look at the Web API Security Champion series. It explains the top 10 web API security risks in a practical way, utilizing Damn Vulnerable RESTaurant vulnerabilities in examples.

Disclaimer

This educational tool simulates security vulnerabilities to enhance ethical hacking skills and security awareness amongst developers. Unauthorized exploitation of real systems is prohibited and may result in significant legal actions. Responsible use is encouraged.


Introduction to the Game

Damn Vulnerable RESTaurant is operated by a mysterious Chef who has discovered that threat actors were able to compromise his restaurant’s API and the underlying system. He suspects that a competing restaurant located across the street might be involved in this attack! The goal of the challenge is to identify and fix vulnerabilities based on provided hints. During this adventure, you will have the opportunity to investigate how the attack was carried out and fix security issues to safeguard the application. Moreover, you can uncover the identity of the person behind the attack by the end of this adventure.

Alternatively, you can choose to act as an attacker, exploiting vulnerabilities! The application contains more vulnerabilities than those presented in the challenge, and various paths can be taken to achieve root access, starting from an unauthenticated API user. The vulnerabilities are associated with the OWASP Top 10 API Security Risks 2023 such as:

  • Insufficient Authorization Checks
  • Server-side Request Forgery (SSRF)
  • Remote Code Execution (RCE)
  • Broken Authentication and JWT Issues
  • Security Misconfigurations
  • Denial of Service Issues

At the time of writing this article, the RESTaurant API offered the following features. All of them are available in Swagger UI and ReDoc documentations:

  • Menu management
  • Creating orders (to order food from the restaurant)
  • User management
  • Administration mechanisms utilised by Chef

Last but not least, the application is utilising a Role-based Access Control (RBAC) approach to restrict user access to API endpoints. The following roles are implemented within the app:

  • Customer — the default role for authenticated users of restaurant’s API
  • Employee — a role dedicated for restaurant’s employees
  • Chef — the highest level of API access, reserved exclusively to Chef

Launching the Game — Developers Approach

I believe I’ve provided you with enough context to dive into the game. Let’s not wait any longer — let’s start playing!

As a developer, you can easily begin your adventure by executing the commands shown below. The only prerequisite is having Docker installed on your machine:

git clone https://github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game.git
cd Damn-Vulnerable-Restaurant-API-Game
./start_game.sh

These commands initiate the Docker containers hosting the Python FastAPI application and PostgreSQL database. Upon starting, you’ll be greeted with a welcome screen that introduces you to the game:

Now, by pressing any key, you can proceed and unveil a screen presenting your first challenge. Here’s an example of one of the challenges:

Each challenge includes notes left by the attacker who managed to infiltrate the Chef’s restaurant, a possible fix which serves as a hint for resolving the issue, and a test file containing a Python script with the proof of concept of the vulnerability.

Fixes can be implemented directly in the application’s source code without the need for reloading. After applying a fix, simply press any key, and the fix will be validated for you! Upon successful mitigation of the vulnerability, you will be congratulated:

At the time of writing this article, the game was consisted of 6 levels, but bear in mind that more vulnerabilities exist, and additional interactive challenges or seasons may be released over time.

Launching the Game — Ethical Hackers Approach

If you’d like to follow an ethical hacker approach, you can launch the application directly without interactive screen, by executing the following command:

git clone https://github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game.git
cd Damn-Vulnerable-RESTaurant-API-Game
./start_app.sh

API Documentation

At this stage, the API service will be accessible at http://localhost:8080 by default. The API documentation, which is useful for understanding application’s features can be found at the following endpoints:

Authentication through Swagger UI

For testing purposes, Swagger UI can be utilised. It allows to authenticate and execute API calls directly from the web UI. Authentication against the API is straightforward — simply click on the green “Authorize” button. However, firstly it’s required to create a customer account via “/register” API endpoint which can be found under “auth tab.

By utilizing Swagger UI, identifying and exploiting most of the API vulnerabilities can be accomplished conveniently, without the need for an advanced setup.

Stopping the Game

The application (Docker containers) can be easily stopped by exeuting the following command:

./stop_app.sh


Development Stack

I hope many of you are already launching the game and starting your hacking journey. If not, you might be interested in the development stack and some details how I developed this application.

The application is developed with Python FastAPI framework for the restaurant’s API, with a PostgreSQL database. Both the API and the database are containerised with Docker, allowing for quick setup and play with minimal configuration effort via Docker Compose.

For testing, I utilise pytest to run unit tests before committing changes. To speed up the development process while maintaining service quality and preventing future regression issues, I employed GitHub Copilot for assistance in writing unit tests. I found Copilot to be extremely helpful during the development of unit tests.

Additionally, I utilise black, isort and autoflake to make the Python code formatted in a standardised way. The tools autoflake, black and isort, along with the unit tests, are executed before commits using the pre-commit tool. I highly recommend such setup for hobby and more advanced projects for its simplicity and a significant value to development processes.

Regarding the game’s CLI, it’s a simple Python script that runs unit tests with implemented exploits. A level is considered solved if a test with an exploit fails. The CLI, for now, avoids complex libraries, employing only basic colors and simple tricks for cursor movement and notification clearance. Nevertheless, the CLI is robust and practical, making it easy to add new levels without modifying the CLI. To implement a new level, one needs to write a proper unit test and place it in a dedicated directory, following specific conventions that I established.


Summary

In this article, I’ve introduced you to the Damn Vulnerable RESTaurant security code game, which can be used as a challenge for expanding developers knowledge about security vulnerabilities. It can be incorporated as a part of Security Champion and Security Awareness Programs for developers, serving as practical and engaging way to reinforce security best practices within the development teams.

I’m considering extending this challenge with new endpoints and vulnerabilities, potentially by releasing a new season. I will use this project as a battlefield for testing various security automation tools and as a resource for explaining web API vulnerabilities in my articles.

I warmly welcome any feedback, particularly from those who have completed all the challenges or are finding them difficult to understand. I’m considering adding simpler entry-level challenges for newcomers to coding. Furthermore, I’m thinking about incorporating GitHub Codespaces to facilitate a quicker setup process for beginners. The future direction of this project will be guided by the community’s needs, so please don’t hesitate to share your thoughts and suggestions!

Interesting Article?

Join DevSec Selection!

DevSec Selection is a bi-weekly Newsletter with the latest outstanding articles related with DevSecOps and application security.


Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments