Detailed Report

August 2024Contents
I.INTRODUCTION
crAPI
Key aspects of
crAPI----------------------------------------------------------------------
--2
Tools
Requirement------------------------------------------------------------
-------------3
II.Application
Setup---------------------------------------------------------------------
---- 4-8
Installation Of crAPI Application
Accessing the crAPI Application
III.Vulnerabilities
API 1: Broken Object level
authorization -------------------------------------------9-14
API 2: Broken User
authentication --------------------------------------------------15-
20
API 3: Excessive User
Authentication -----------------------------------------------21-23
API 4: Rate
Limiting -----------------------------------------------------------------
----24-27

Page 1 of 50
 API 5: Broken Function Level
Authorization---------------------------------------28-31
API 6: Mass
Assignment ------------------------------------------------------------
---32-38
API 7: Server side request
forgery---------------------------------------------------39-41
API 8:
Injection -----------------------------------------------------------------
-----------
IV.Conclusion
OWASP/crAPI (Completely Ridiculous API) is a project by the open Web Application Security
Project (OWASP) designed to help developers, security professionals, and students learn about API
security. It's an intentionally vulnerable API that mimics real-world scenarios, allowing users to
practice finding and fixing common security flaws.

Key Aspects of OWASP/crAPI

1. Purpose

crAPI's primary goal is to provide a safe environment for learning about API vulnerabilities and their
mitigations. It helps users understand how attackers exploit APIs and teaches them how to secure
their own applications.

2. Design

crAPI is built to resemble a real-world API, complete with features like user authentication,
messaging, and profile management. The design is intentionally flawed to expose various security
issues that can occur in modern APIs.

3. Vulnerabilities Covered

crAPI includes a range of vulnerabilities, such as:

 Broken Object Level Authorization (BOLA): Where unauthorized access to data is possible.

 Broken Authentication: Issues with login mechanisms that allow attackers to bypass security.

 Excessive Data Exposure: APIs that reveal more data than necessary, often leading to privacy
breaches.

 Security Misconfigurations: Improperly configured settings that weaken security.

 Injection Attacks: Vulnerabilities like SQL injection that allow attackers to run malicious code.

 Improper Assets Management: Poor handling of API endpoints and resources.

 Rate Limiting Issues: Lack of controls to prevent abuse through rapid or excessive requests.

Page 2 of 50
4. Learning Experience

Users interact with the API by exploring its endpoints, identifying vulnerabilities, and practicing
exploit techniques. This hands-on approach helps them understand how each flaw works and the
potential damage it can cause. Additionally, crAPI provides guidance on how to fix these issues,
making it a comprehensive learning tool.

5. Scenarios and Storylines

crAPI includes a set of scenarios that mimic real-world situations. These storylines help users engage
with the API in a meaningful way, enhancing the learning experience. For example, users might be
tasked with recovering a compromised account or preventing data leaks.

6. Educational Resources

The project offers documentation, tutorials, and walkthroughs that explain each vulnerability in
detail. These resources help users grasp the concepts of API security and learn best practices for
protecting their applications.

7. Community and Open Source

crAPI is an open-source project, which means it’s freely available for anyone to use, modify, and
contribute to. The community around crAPI actively collaborates on improving the project, adding
new vulnerabilities, scenarios, and educational content.

Tools Required:

1. Burp Suite

 Purpose: Web vulnerability scanner and testing tool.

 Usage with crAPI: Burp Suite can be used to intercept, modify, and analyze the HTTP requests
and responses between the client and crAPI. It's especially useful for testing vulnerabilities
like SQL Injection, Cross-Site Scripting (XSS), and Insecure Direct Object References (IDOR).

2. Docker

 Purpose: Containerization platform.

 Usage with crAPI: Docker is used to run crAPI in isolated containers. Understanding Docker is
essential for managing crAPI environments and testing scenarios, especially when dealing
with different versions or configurations.

Page 3 of 50
 APPLICICATION SETUP
 1. Introduction
 This document guides you through the process of pulling and running the OWASP crAPI
(Completely Ridiculous API) using Docker on a Windows machine. We will use both Docker
Compose and Docker Desktop's graphical interface to manage the images and containers.

 2. Prerequisites
 Before starting, make sure you have the following installed on your computer:
- Docker Desktop: This tool allows you to run Docker containers on your machine.
- Git: Needed to clone the crAPI repository from GitHub.

 2.1. Install Docker Desktop

 1. Download Docker Desktop from the official Docker website:
https://www.docker.com/products/docker-desktop.
2. Install Docker Desktop by following the installation instructions provided on the website.
3. Launch Docker Desktop after installation and make sure it is running.

 2.2. Install Git

 1. Download Git from the Git for Windows website: https://git-scm.com/.
2. Install Git by following the setup instructions.
3. Verify the Installation by opening Command Prompt and typing:
git --version
- This should display the installed Git version.

Page 4 of 50
 3. Cloning the crAPI Repository
 3.1. Open Command Prompt
 1. Press the Windows Key and type 'cmd'.
2. Click on 'Command Prompt' to open it.

 3.2. Clone the crAPI Repository

 1. Navigate to the directory where you want to clone the project:
cd C:\Users\YourUsername\Documents
2. Clone the crAPI repository using Git:
git clone https://github.com/OWASP/crAPI.git

3. Navigate into the crAPI directory: cd crAPI

 4. Locate the Docker Compose File

 4.1. Understanding the Directory Structure
 1. After cloning the repository, the 'docker-compose.yml' file, which is needed to set up the
crAPI services, is located in the 'deploy/docker' directory.

 4.2. Navigate to the Docker Directory

 1. In Command Prompt, navigate to the directory where the 'docker-compose.yml' file is
located: cd deploy\docker

Page 5 of 50
 2. Verify that the file is present by listing the directory contents: dir
- You should see 'docker-compose.yml' listed.

 5. Pulling and Running crAPI Using Docker Compose

 5.1. Pull the Docker Images
 1. Run Docker Compose to pull and start the services defined in the 'docker-compose.yml'
file: docker-compose up -d (or)
 docker-compose -f C:\Users\username\crAPI\deploy\docker\docker-compose.yml up -d

- This command will automatically download the required Docker images and start the
containers.
 2. Monitor the Process:
- Docker Compose will display the status as it pulls the images and starts the containers.
This may take some time depending on your internet speed.
 3. Verify the Running Containers:
- After the process is complete, check if the containers are running by typing:
docker ps
- This command lists all the running containers.

 5.2. Accessing the crAPI Application

 1. Open Your Web Browser.
2. Navigate to http://localhost:8888.

Page 6 of 50
 3. You should now see the crAPI application running. You can interact with the application
and start working on the challenges

 Alternative Way: Pulling and Running crAPI Using

Docker Desktop
 1. Introduction
 This guide will show you how to pull and run the OWASP crAPI (Completely Ridiculous API)
using Docker Desktop's graphical interface, without relying on command-line tools.

 2. Prerequisites
 Before starting, ensure you have Docker Desktop installed and running on your computer. If
you don't have it installed, follow these steps:

 2.1. Install Docker Desktop

 1. Download Docker Desktop from the official Docker website:
https://www.docker.com/products/docker-desktop.
2. Install Docker Desktop by following the installation instructions.
3. Launch Docker Desktop after installation and ensure it is running.

 3. Pulling Docker Images Using Docker Desktop

 3.1. Open Docker Desktop
 1. Launch Docker Desktop from your Start menu or desktop shortcut.

 3.2. Search and Pull the Required Docker Images

 1. Navigate to the Images Tab:
- Click on the 'Images' tab located in the left sidebar of Docker Desktop.

2. Search for Each crAPI Image:

- In the search bar at the top of the Images tab, type the name of the Docker image you
need for crAPI. Here are some examples:
- crapi-web

Page 7 of 50
 - crapi-identity
- crapi-community
- mongodb
- postgres

3. Pull the Image:

- After finding the image, click the 'Pull' button. Docker Desktop will start downloading the
image to your local system.

 3.3. Repeat for All Necessary Images

 1. Pull All Required Images:
- Repeat the search and pull process for each image needed by crAPI.

 4. Running Docker Containers Using Docker Desktop

 4.1. Run the Pulled Images
 1. Navigate to the Images Tab:
- In Docker Desktop, find the image you pulled in the Images tab.

2. Start the Container:

- Click the 'Run' button next to the image name to start a new container from the image.

3. Configure the Container (Optional):

- If necessary, you can click on 'Advanced Settings' to configure environment variables,
ports, and volumes before running the container.

4. Repeat for All Services:

- Start containers for all the images required by crAPI (crapi-web, crapi-identity, mongodb,
etc.).

 5. Accessing the crAPI Application

 1. Open Your Web Browser.
2. Navigate to http://localhost:8888.
3. Interact with crAPI:
- You should now see the crAPI application running. You can start interacting with the
application and working on the challenges.

 . Conclusion
 You have now successfully pulled and run the OWASP crAPI using Docker Desktop's graphical
interface. This method is ideal for users who prefer a visual interface over command-line
tools. Enjoy exploring and working on the security challenges provided by crAPI.

Page 8 of 50
Challenges:
BOLA Vulnerabilities

Vulnerability BOLA (Broken Object Level Authorization)

Severity High

Description Broken Object Level Authorization (BOLA) is a security vulnerability that occurs
when an application fails to enforce proper authorization checks for accessing
or manipulating objects (such as records, files, or other data entities). In a BOLA
vulnerability, an attacker can exploit weak or missing authorization mechanisms
to gain unauthorized access to objects that belong to other users or manipulate
data they should not have access to. BOLA is one of the most common
vulnerabilities in API-driven applications, where object identifiers (like IDs) are
passed in API requests without adequate authorization checks.

Impact Data Breach: Attackers can access sensitive data belonging to other users, such
as personal information, financial records, or proprietary information.

Page 9 of 50
 Data Manipulation: Attackers may alter or delete data belonging to other users,
leading to data integrity issues and potential loss of trust.

Account Takeover: In some cases, BOLA vulnerabilities can be leveraged to

perform actions on behalf of other users, leading to unauthorized transactions
or account takeovers.

Legal and Compliance Issues: Unauthorized access to sensitive data due to

BOLA vulnerabilities can result in regulatory penalties and damage to the
organization's reputation.

Remediation Implement Object-Level Authorization Checks: Ensure that every request to

access or modify an object is accompanied by an authorization check to verify
that the requesting user has the necessary permissions to perform the action
on that specific object.

Use Secure Object References: Avoid using easily guessable or sequential object
identifiers in APIs. Instead, use secure, random, or hashed identifiers that are
difficult for attackers to predict or manipulate.

Apply the Principle of Least Privilege: Restrict access to objects based on the
user's role and specific permissions. Ensure that users can only access the
objects they are explicitly authorized to access.

Audit and Log Access to Objects: Implement logging and monitoring to track
access to objects, especially sensitive ones. This helps detect and respond to
unauthorized access attempts.

Perform Regular Security Testing: Conduct regular penetration testing and code
reviews to identify and address BOLA vulnerabilities in your application.
Automated tools and manual testing can help uncover weaknesses in object-
level authorization.

Educate Developers: Ensure that developers understand the importance of

proper authorization checks and follow secure coding practices to prevent
BOLA vulnerabilities from being introduced into the codebase.

BOLA, or Broken Object-Level Authorization, is a type of security vulnerability that occurs when
an application fails to properly enforce access controls at the object or data level. This can lead to
unauthorized users gaining access to sensitive data or performing actions they should not be
allowed to perform within the application.

Challenge 1 - Access details of another user’s vehicle

To solve the challenge, you need to leak sensitive information about another user’s vehicle.

Page 10 of 50
Page 11 of 50
Upon signing up and logging into the account, I noticed an “Add Vehicle” option in the
dashboard. After successfully adding a vehicle, the dashboard displays detailed information
about the vehicle along with its location on a Google map. Curiously, I discovered a “Refresh
Location” option at the bottom of the page.

Clicking on this option, I intercepted the request using Burp Suite, revealing an API endpoint that
requires a vehicle ID, as shown below.

Page 12 of 50
The next step was to identify the vehicle IDs of other users. I navigated to the “Community” page
and found messages posted by various users. By inspecting the responses in Burp Suite, I
uncovered additional information, particularly the “vehicle id” attribute.

Page 13 of 50
With the vehicle ID in hand, I forwarded the request to the API endpoint responsible for
retrieving vehicle locations to Burp Suite’s repeater. Using the vehicle ID associated with another
user, I successfully gained access to the location details of their vehicle.

Challenge 2: Access mechanic reports of other users

While exploring the dashboard, I stumbled upon the “Contact Mechanic” page, which
presented me with a form to fill out. After completing the form, I couldn’t help but wonder what
lay beneath the surface.

Page 14 of 50
Upon inspecting the response using Burp Suite, I discovered a link that provided access to a
mechanic report. This link included a “report_id” parameter.

Taking advantage of this discovery, I intercepted the request containing the “report_id.” I decided
to test it out by attempting to access the report associated with “id=2.” To my surprise, I
successfully gained access to another user’s mechanic report.

Broken User Authentication

Vulnerability Broken User Authentication

Severity Critical

Description Broken User Authentication refers to security flaws in an application's

authentication process that allow attackers to compromise user accounts. This
can occur due to weak password policies, improper session management, lack
of multi-factor authentication (MFA), insecure password recovery mechanisms,
or vulnerabilities in the way user credentials are handled and stored. When
authentication is broken, attackers can gain unauthorized access to user
accounts, leading to data breaches, account takeover, and further exploitation
of the application.

Impact Account Takeover: Attackers can hijack user accounts, leading to unauthorized
access to sensitive information, financial transactions, or personal data.

Data Breach: Compromised user accounts can lead to the exposure of sensitive
information, affecting not just the account holder but potentially other users or
the entire system.

Reputation Damage: A breach due to broken authentication can severely

damage an organization's reputation and erode user trust.

Regulatory Consequences: Unauthorized access to personal data may lead to

legal penalties and regulatory fines, especially under data protection laws like

Page 15 of 50
 GDPR or CCPA.

Remediation Implement Strong Password Policies: Enforce the use of strong, complex
passwords that include a mix of letters, numbers, and special characters.
Implement password length requirements and prohibit commonly used
passwords.

Enable Multi-Factor Authentication (MFA): Require users to provide a second

form of verification (such as a code sent to a mobile device) in addition to their
password, greatly reducing the risk of account compromise.

Secure Password Storage: Store passwords using strong hashing algorithms

(e.g., bcrypt, Argon2) with a unique salt for each password. Avoid storing
passwords in plaintext.

Implement Secure Session Management: Use secure tokens (e.g., JWTs) for
session management and ensure tokens are invalidated upon logout. Set short
session timeouts and regenerate session tokens after login.

Monitor and Respond to Authentication Anomalies: Detect and respond to

suspicious login activities, such as multiple failed login attempts or logins from
unusual locations, by implementing monitoring and alerting mechanisms.

Secure Password Recovery Mechanisms: Ensure that password recovery

processes (e.g., email-based resets) are secure, requiring additional verification
steps to confirm the identity of the user.

Avoid User Enumeration: Prevent attackers from identifying valid usernames or

email addresses by providing generic error messages during login or
registration.

Regularly Test Authentication Mechanisms: Conduct regular security

assessments, including penetration testing and code reviews, to identify and fix
vulnerabilities in the authentication process.

Broken user authentication is a critical security issue when an application fails to properly
authenticate or authorize users, potentially allowing unauthorized individuals to access restricted
resources or perform actions they shouldn’t have access to.

Challenge 3 — Reset the password of a different user

I noticed a “Forgot Password” option on the login page. After providing my email on the “Forgot
Password” page, an OTP was promptly dispatched to my email.

Page 16 of 50
Page 17 of 50
Page 18 of 50
Page 19 of 50
I observed that this endpoint utilized version v3, prompting me to investigate version v2, hoping
it lacked the exact protection mechanism. To my surprise, v2 did indeed lack limitations on the
number of attempts.

I obtained the email addresses of other users from the community page. I proceeded to generate
OTPs for another user.

To carry out this task, I employed Burp Suite’s Intruder function, employing a sniper attack.

Once I had the Intruder setup in motion and initiated the attack, the response I received carried
the message “OTP verified.”

Excessive data exposure

Vulnerability Excessive data exposure

Severity High

Description Excessive Data Exposure occurs when an application inadvertently exposes

more data than is necessary or intended, often due to a lack of proper data
filtering or access control. This vulnerability is particularly common in APIs
where sensitive data is included in responses, even if the client doesn’t need it
or is not authorized to view it. The exposed data might include personal
information, financial records, or other sensitive details, leading to privacy
violations and security risks.

Impact Data Breach: Sensitive information, such as personal identifiers, financial data,
or confidential business information, may be exposed to unauthorized users,
leading to privacy breaches.

Page 20 of 50
 Legal and Compliance Risks: Exposure of sensitive data can lead to non-
compliance with regulations such as GDPR, CCPA, or HIPAA, resulting in legal
penalties and fines.

Reputation Damage: The unintentional exposure of sensitive data can erode

trust in the organization, damaging its reputation and relationships with
customers and partners.

Increased Attack Surface: Attackers can use the exposed data to craft more
targeted attacks, such as phishing or social engineering, or to exploit other
vulnerabilities in the system.

Remediation Implement Data Minimization: Follow the principle of data minimization by

ensuring that only the necessary data is exposed in API responses or
application outputs. Avoid including sensitive information unless it is explicitly
required by the client.

Use Data Filtering: Implement proper server-side data filtering and sanitization
to ensure that only authorized data is returned to the client. Avoid relying
solely on client-side filtering, as it can be bypassed by attackers.

Enforce Access Controls: Apply strict access control mechanisms to ensure that
users can only access the data they are authorized to view. Use role-based
access control (RBAC) or attribute-based access control (ABAC) to limit data
exposure based on user roles or attributes.

Conduct Data Audits: Regularly review and audit the data being exposed by
your APIs or application to ensure that it aligns with the principle of least
privilege. Identify and eliminate any instances of excessive data exposure.

Implement Response Filtering Middleware: In API-driven applications, use

middleware to inspect and filter out unnecessary data from responses before
they are sent to the client.

Educate Developers: Ensure that developers understand the risks associated

with excessive data exposure and are trained to implement secure data
handling practices.

Use Secure Coding Practices: Apply secure coding practices to prevent

inadvertent data exposure. For example, avoid using wildcard selectors (e.g.,
SELECT * in SQL queries) that may return more data than intended.

Regular Security Testing: Perform regular security assessments, including code

reviews, penetration testing, and automated scanning, to identify and address
excessive data exposure vulnerabilities.

Excessive data exposure is a critical security issue that occurs when sensitive information is
unintentionally or improperly disclosed to unauthorized individuals or systems. It can have
serious consequences for individuals and organizations, including data breaches, privacy
violations, and legal ramifications.

Page 21 of 50
 Challenge 4 — Find an API endpoint that leaks sensitive information of other users

While exploring the “Community” page, I made a striking discovery. Upon inspecting the
response, I found that it contained detailed information about another user.

Challenge 5 — Find an API endpoint that leaks an internal property of a video

In the process of uploading a video, I made an intriguing discovery. Upon receiving the response, I
noticed that it disclosed an internal property of the video.

Page 22 of 50
Rate Limiting
Vulnerability Rate Limiting

Severity Medium to High

Description Rate Limiting is a technique used to control the amount of incoming and outgoing
traffic to and from a server or API within a specific time frame. It is designed to prevent
abuse, such as denial-of-service attacks, brute-force login attempts, or API misuse, by
limiting the number of requests a user or client can make in a given period. Rate
limiting helps maintain the stability, performance, and security of the application by
ensuring that resources are not overwhelmed by excessive or malicious traffic.

Impact Denial of Service (DoS) Attacks: Without rate limiting, attackers can flood the server
with a massive number of requests, potentially overwhelming it and causing legitimate
users to experience downtime or degraded performance.

Brute-Force Attacks: Attackers can repeatedly attempt to guess passwords or API keys
through brute-force methods if there are no restrictions on the number of login
attempts or API calls.

Resource Exhaustion: Excessive requests can exhaust server resources, leading to slow
response times or unavailability of the service for other users.

Page 23 of 50
 API Abuse: Malicious users or bots can abuse the API by making an excessive number
of requests, leading to increased operational costs, data exposure, or unintended
behavior in the application.

Service Degradation: Legitimate users may experience degraded service quality or

increased latency due to a lack of rate limiting, as the server struggles to handle
excessive traffic.

Remediatio Set Request Limits: Define the maximum number of requests a user or IP address can
n make within a specified time frame (e.g., 100 requests per minute). These limits can be
applied globally or to specific endpoints, depending on the application's needs.

Use Throttling Mechanisms: Implement throttling to slow down or delay responses

when the rate limit is being approached, rather than immediately rejecting requests.
This can provide a smoother user experience while still protecting the server.

Implement Dynamic Rate Limiting: Use adaptive or dynamic rate limiting that adjusts
the limits based on factors such as user behavior, time of day, or the type of request.
This helps balance security and usability.

Return Meaningful Responses: When a user hits the rate limit, return a meaningful
error response (e.g., HTTP 429 Too Many Requests) that informs the user about the
limit and when they can try again.

Monitor and Log Traffic: Continuously monitor and log traffic patterns to detect and
respond to abnormal activity. This can help identify potential attacks or misuse and
adjust rate limiting policies accordingly.

Use API Gateways: Implement rate limiting at the API gateway level to centrally
manage and enforce rate limits across multiple services and endpoints.

Educate Users and Provide Documentation: Clearly communicate rate limits to users
through documentation, and provide guidelines on how to efficiently use the API within
the established limits.

Rate limiting is a technique used in computer systems to control the rate at which requests or actions
are allowed. It’s often implemented to prevent abuse, protect resources, and maintain system
stability. Rate limiting can be applied in various contexts, such as API rate limiting, login attempts, or
even in protecting against DDoS attacks.

Challenge 6 — Perform a layer 7 DoS using ‘contact mechanic’ feature

A Layer 7 Denial of Service (DoS) attack, often referred to as an application layer DoS attack, is a type
of cyberattack that specifically targets the application layer of the OSI model. In this type of attack,
the attacker aims to overwhelm a web server or application by sending a large volume of malicious
requests that are designed to consume server resources, exhaust server capacity, or exploit
vulnerabilities in the application.

Page 24 of 50
While exploring the application, I encountered the ‘Contact Mechanic’ feature, which allowed users
to fill out a form for assistance. Intrigued, I decided to investigate further.

 Upon examining the request, I noticed the parameter “repeat_request_if_failed” was set to
“false,” with “number_of_repeats” at a value of 1.

Page 25 of 50
However, what piqued my curiosity was the potential impact of changing these values. By modifying
“repeat_request_if_failed” to “true” and setting “number_of_repeats” to a whopping 10,000, I
initiated a request that overwhelmed the system.

The response I received clearly indicated a Layer 7 Denial-of-Service (DoS) condition with the
message: “Service unavailable. Seems like you caused a Layer 7 DoS :)”

Page 26 of 50
BROKEN FUNCTION LEVEL AUTHORIZATION (BFLA)
Vulnerability Broken Function Level Authorization(BFLA)

Severity High

Description Broken Function Level Authorization (BFLA) occurs when an application fails to properly
enforce authorization checks for different functions or actions within the application.
This means that users may be able to access or execute functions that they should not
have permission to, such as administrative functions, data management operations, or
other restricted actions. BFLA typically arises when access control mechanisms are
either missing, inconsistent, or improperly configured across various functions or
endpoints of the application.

Impact Privilege Escalation: Unauthorized users may gain access to higher-level functions,
leading to the execution of administrative or sensitive operations, potentially
compromising the entire system.

Data Breach: Attackers can access, modify, or delete data they are not authorized to
interact with, leading to data breaches and loss of data integrity.

Operational Disruption: Unauthorized access to critical functions can disrupt normal

operations, leading to denial of service, data corruption, or other significant issues.

Reputation Damage: Exploitation of BFLA vulnerabilities can lead to a loss of customer

trust and damage the reputation of the organization, especially if sensitive data is
compromised or critical functions are misused.

Remediatio Implement Consistent Authorization Checks: Ensure that all functions, especially those
n that perform sensitive or administrative actions, have consistent and robust
authorization checks. These checks should verify that the user has the necessary
permissions before allowing access to the function.

Use Role-Based Access Control (RBAC): Implement RBAC to restrict access to functions
based on the user’s role within the organization. Only users with the appropriate role
should have access to sensitive functions.

Apply the Principle of Least Privilege: Grant users the minimum level of access
required to perform their duties. This minimizes the risk of unauthorized access to
sensitive functions.

Centralize Access Control Logic: Centralize access control logic to ensure consistency
across the application. This reduces the risk of misconfigurations and ensures that all
functions are subject to the same authorization policies.

Conduct Security Reviews: Regularly review and audit your codebase and application
architecture to identify and address potential BFLA vulnerabilities. Ensure that
authorization checks are in place and functioning as expected.

Test for Authorization Flaws: Perform penetration testing and security assessments to

Page 27 of 50
 specifically test for broken function level authorization. Automated tools can help
identify missing authorization checks, but manual testing is often necessary to uncover
more subtle issues.

Educate Developers: Train developers on the importance of implementing proper

authorization checks and following secure coding practices. Ensure they understand
how to properly apply authorization controls across different levels of the application.

Broken Function Level Authorization (BFLA) is a security vulnerability that occurs when an application
or system does not properly enforce access controls at the function or feature level. In other words,
it allows users to perform actions or access features that they should not have permission to use.

Challenge 7 — Delete a video of another user

Step 1: Change Video Name

I began by using the “Change Video Name” option, allowing me to modify the name of the video.

Page 28 of 50
Page 29 of 50
Upon renaming the video, I noticed that the method used was PUT. This piqued my interest,
prompting me to explore which methods were allowed for this endpoint. To my surprise, I discovered
that the DELETE method was permitted.

Taking advantage of the DELETE method, I initiated a request with an empty request body. The server
responded with a message stating, “This is an admin function. Try to access the admin API.

Recognizing the need for admin privileges, I decided to manipulate the request further. By changing
the user to “admin” and sending the request, I successfully deleted the video.

However, the real challenge was to delete another user’s video. Upon examining the endpoint, I
noticed that it utilized a numerical value at the end. Suspecting this value to be a unique identifier, I
modified it to represent the target user and sent the request. The result? A successful deletion of
another user’s video.

Page 30 of 50
Mass Assignment

Vulnerability Mass Assignment

Severity High

Description Mass Assignment is a security vulnerability that occurs when an application

automatically binds user input to model attributes without proper filtering or
validation. In frameworks that support mass assignment, data from user input (such
as form submissions or API requests) can be directly mapped to object properties
or database fields. If not properly controlled, this can allow attackers to manipulate
data they shouldn't have access to, such as setting administrative privileges,
altering critical fields, or injecting harmful values into sensitive attributes.

Impact 1. Privilege Escalation: Attackers can manipulate properties like user roles or
access levels, potentially elevating their privileges within the application.

2. Data Integrity Issues: Unauthorized changes to critical data fields can

compromise the integrity of the application's data, leading to operational
issues or loss of trust.

3. Security Bypass: Sensitive fields that control access, status, or other critical
application logic can be altered, leading to a bypass of security controls.

4. Widespread Exploitation: If the vulnerability is present in an API or widely

used functionality, attackers can potentially automate exploitation,
affecting many users or systems at once.

Remediatio Implement Attribute Whitelisting: Explicitly specify which attributes can be mass-
n assigned. This is often referred to as "strong parameters" or "parameter
whitelisting." Only allow user input to affect attributes that are safe to modify.

Use Safe Object Binding: When binding user input to model objects, use methods
that require explicit mapping of input fields to model attributes, avoiding automatic
or blanket assignment.

Validate User Input: Implement strict input validation to ensure that user-supplied
data is safe, expected, and appropriate for the corresponding model attributes.

Control Sensitive Attributes: Mark sensitive attributes as protected or private

within your models, preventing them from being set or modified through mass
assignment.

Regularly Review and Test Code: Conduct regular code reviews and security testing
to identify and mitigate potential mass assignment vulnerabilities. This includes
reviewing model definitions and how they interact with user input.

Educate Developers: Ensure that developers understand the risks associated with
mass assignment and are trained to implement secure handling of user input and

Page 31 of 50
 model data.

Challenge 8 — Get an item for free

We initiated the challenge by exploring the ‘shop’ page, where we noticed an available balance of
$100 and two items: ‘Seat’ and ‘Wheel’. We placed an order and closely examined the request and
response from the workshop API.

Page 32 of 50
Past-orders page displayed a list of all orders for the user.

 Now intercepted the order detail request, revealing the allowed methods and the order’s
status.

Page 33 of 50
  We dared to change the request method from GET to PUT, leading to a valuable message in
the response. It appeared that the ‘status’ could have only three distinct values: 'delivered’,
‘return pending’ or ‘returned’.

Challenge 9 — Increase your balance by $1,000 or more

To increase our balance by $1,000 or more, we placed a new order. We adjusted the ‘quantity’ to 100
and changed the status to ‘returned’ using the previous endpoint. the application deducted $10 for
one seat, reducing the balance from $90 to $80. By manipulating the ‘quantity’ to ‘100’ and the
‘status’ t

o ‘returned’, we triggered a refund of $1,000, effectively adding it to our account.

Page 34 of 50
 Now change the quantity to -100 and click on send so that amount will be credited.

Page 35 of 50
Challenge 10 — Update internal video properties

We initiated the challenge by using the “Change Video Name” option, which allowed us to modify
the video’s name. While performing this action, we noticed that the method being used was
PUT.Upon renaming the video, the response provided valuable information, specifically the
“conversion_params,” which exposed internal video properties.

We used “conversion_params” to alter the video properties and received confirmation of success.

Page 36 of 50
Page 37 of 50
Server-Side Request Forgery (SSRF)
Vulnerability Server-Side Request Forgery (SSRF)

Severity High

Description Server-Side Request Forgery (SSRF) is a security vulnerability that occurs when an
attacker is able to make a server-side application send HTTP requests to an unintended
destination. In an SSRF attack, the attacker manipulates a server to make requests to
internal resources, third-party services, or other unintended targets. The server acts as
a proxy, allowing the attacker to bypass firewalls, access internal networks, or interact
with sensitive services that would otherwise be inaccessible from the outside.
SSRF often occurs when a web application accepts a user-provided URL or destination
as input and fetches data from that URL without proper validation or restriction.

Impact Internal Network Access: Attackers can exploit SSRF to gain unauthorized access to
internal network resources that are not exposed to the public internet. This can lead to
further attacks, such as lateral movement within the network.

Sensitive Data Exposure: SSRF can be used to access sensitive internal services, such as
metadata services on cloud platforms, which can expose credentials, secrets, or
configuration data.

Bypassing Security Controls: Attackers can leverage SSRF to bypass security controls
like firewalls, network segmentation, or access control lists (ACLs), potentially leading to
unauthorized access to critical systems.

Denial of Service (DoS): SSRF can be used to overload internal services by sending a
large number of requests or triggering resource-intensive operations, leading to a
denial of service.

Remote Code Execution (RCE): In some cases, SSRF can be chained with other
vulnerabilities to achieve remote code execution on the server or other internal
systems.

Remediatio Input Validation: Rigorously validate and sanitize all user inputs that could be used to
n construct URLs or network requests. Ensure that inputs are constrained to allow only
safe and expected destinations.

Use Whitelisting: Implement a whitelist of allowed domains or IP addresses that the

server can interact with. Reject requests to any resources not explicitly permitted.

Restrict Network Access: Limit the server's ability to make outbound requests to
internal or sensitive networks. Use network segmentation and firewall rules to prevent
unauthorized access to internal resources.

Disable Unnecessary Services: Turn off or restrict access to internal services that do not
need to be exposed. This reduces the attack surface available to SSRF attacks.

Use SSRF Protection Tools: Implement security tools or libraries specifically designed to

Page 38 of 50
 detect and prevent SSRF attacks. These can help identify and block malicious requests.

Monitor and Log Requests: Monitor server-side request activity and log any suspicious
or anomalous requests. This can help in detecting and responding to SSRF attacks in
real-time.

Educate Developers: Ensure that developers are aware of SSRF risks and are trained to
implement secure coding practices that prevent SSRF vulnerabilities from being
introduced into the codebase.

SSRF is a type of security vulnerability that occurs when an attacker can manipulate the requests
made by a web application to access resources on the server or other internal systems that they
should not have access to.

Challenge 11 — Make crAPI send an HTTP call to “www.google.com" and return the HTTP
response.

 We started by intercepting the request from the contact mechanic form in Burp Suite. Within
the response, we discovered a URL that our request was using.

Page 39 of 50
 We decided to modify the request URL. By substituting the URL, we successfully prompted
the server to make an HTTP call to “www.google.com."

Page 40 of 50
NoSQL Injection
Vulnerability No SQL Injection

Severity High

Description NoSQL Injection is a security vulnerability that occurs when user input is improperly
handled within NoSQL database queries. Unlike traditional SQL databases, NoSQL
databases (such as MongoDB, CouchDB, and others) use different query formats and
structures, but they can still be vulnerable to injection attacks if user inputs are not
properly validated or sanitized. Attackers exploit this vulnerability to inject malicious
code into NoSQL queries, potentially gaining unauthorized access to data, bypassing
authentication, or manipulating the database.

Impact Unauthorized Data Access: Attackers can retrieve sensitive information from the
database, including user credentials, personal information, or proprietary data.

Data Manipulation: Malicious users can modify, delete, or corrupt data, leading to data
integrity issues and disrupting business operations.

Authentication Bypass: In some cases, NoSQL Injection can be used to bypass

authentication mechanisms, allowing attackers to gain unauthorized access to the
application.

Denial of Service (DoS): Attackers may inject code that triggers resource-intensive
operations, leading to a denial of service by exhausting system resources.

Remediatio Input Validation: Rigorously validate and sanitize all user inputs to ensure they meet
n the expected format and type. Reject any input that does not conform to the
requirements.

Use Parameterized Queries: When constructing NoSQL queries, use parameterized

queries or query builders that automatically escape user input, preventing it from being
executed as code.

Secure Query Logic: Avoid directly embedding user input into query structures. Use
safe methods provided by the NoSQL database driver to handle user inputs securely.

Access Control: Implement strict access controls at the database level, ensuring that
application users have only the minimum permissions required to perform their
functions.

Error Handling: Do not expose detailed error messages to end users. Detailed errors
can give attackers clues about the database structure and potential vulnerabilities.

Security Testing: Regularly perform security assessments, including manual code

reviews and automated scanning tools, to detect and mitigate NoSQL Injection
vulnerabilities.

Logging and Monitoring: Implement logging and monitoring to detect and respond to

Page 41 of 50
 suspicious activity, such as unexpected query patterns or repeated injection attempts.

NoSQL Injection is a type of security vulnerability that occurs in applications that use NoSQL
databases, such as MongoDB, Cassandra, or Redis when user-supplied data is not properly sanitized
or validated before being used in database queries.

Challenge 12 — Find a way to get free coupons without knowing the coupon code.

Step 1: Intercepting the Validate-Coupon Request

We initiated the challenge by intercepting the validate-coupon request in Burp Suite.

Step 2: Employing a NoSQL Payload

We took inspiration from a collection of NoSQL injection payloads available on GitHub at

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection Specifically,
we used the payload { "$ne": 1 }, which proved effective.

Page 42 of 50
Page 43 of 50
SQL Injection
Vulnerability SQL Injection

Severity Critical

Description SQL Injection is a code injection technique that occurs when an application allows user
input to be included in SQL queries without proper validation or sanitization. Attackers
exploit this vulnerability by injecting malicious SQL code into input fields (such as forms,
URL parameters, or cookies) that interact with a database. This can lead to
unauthorized access to database content, data modification, or even complete
database control.

Impact 1. Data Breach: Attackers can retrieve sensitive information, including user
credentials, financial data, and personal information.

2. Data Manipulation: Attackers can modify or delete data, causing significant

disruption to business operations.

3. Complete System Compromise: In some cases, SQL Injection can be leveraged

to execute system commands or gain administrative access, leading to a full
compromise of the application or server.

4. Financial Loss and Legal Consequences: SQL Injection attacks can result in
significant financial losses, regulatory penalties, and damage to the
organization's reputation.

Remediatio Use Prepared Statements (Parameterized Queries): Ensure that SQL queries are
n parameterized, where user input is treated as data, not executable code. This prevents
injected code from being executed.

Input Validation: Validate and sanitize all user inputs to ensure they conform to
expected formats, such as numbers, dates, or specific strings. Reject any input that
does not meet the criteria.

Use ORM (Object-Relational Mapping): ORM frameworks can help mitigate SQL
Injection by abstracting database queries and automatically handling parameterization.

Database Permissions: Limit database user permissions to the minimum required for
the application to function. Avoid using database admin accounts for application
queries.

Error Handling: Avoid exposing detailed database error messages to users, as these can
provide valuable information for attackers attempting SQL Injection.

Security Testing: Regularly perform security testing, including automated tools and
manual code reviews, to identify and address potential SQL Injection vulnerabilities.

Web Application Firewall (WAF): Implement a WAF to detect and block SQL Injection
attempts before they reach the application.

Page 44 of 50
SQL Injection (SQLi) is a type of security vulnerability that occurs in web applications when user-
supplied data is not properly validated or sanitized before being included in SQL queries. This allows
malicious users to manipulate these queries to gain unauthorized access to a database or perform
unintended actions on the database.

Challenge 13 — Find a way to redeem a coupon that you have already claimed by modifying the
database

After completing Challenge 12 and obtaining a free coupon, we proceeded to use the coupon code.
We intercepted the request associated with coupon redemption.

Page 45 of 50
Page 46 of 50
 To manipulate the database and redeem the coupon, we turned to a repository of offensive
payloads available at [https://github.com/InfoSecWarrior/Offensive-Payloads/]. We used a
basic SQL injection payload: 0' or '0' = '0.The response we received was a success message
indicating that the coupon code had already been claimed by us.

 We attempted to identify the SQL version by using the payload 0'; select version() --+, which
revealed the SQL version in the response.

Page 47 of 50
Unauthenticated access

Vulnerability Unauthenticated access

Severity High

Description Unauthenticated access occurs when an application fails to properly enforce

authentication mechanisms, allowing unauthorized users to access resources,
functions, or data without providing valid credentials. This vulnerability typically arises
from misconfigurations, missing authentication checks, or improper handling of access
control within the application.

Impact The impact of unauthenticated access can be severe, depending on the resources or
data exposed. Attackers may gain access to sensitive information, perform
unauthorized actions, or exploit other vulnerabilities in the application. This can lead to
data breaches, financial loss, damage to reputation, and legal consequences for the
organization.

Remediatio Enforce Authentication: Ensure that all endpoints and resources require proper
n authentication before access is granted. Implement robust authentication mechanisms
such as multi-factor authentication (MFA) where applicable.

Access Control Validation: Regularly review and validate access control policies to
ensure that only authenticated users can access restricted resources.

Implement Secure Session Management: Use secure session tokens and enforce
session timeouts to prevent unauthorized access.

Conduct Regular Security Audits: Regularly audit the application to identify and rectify
any gaps in authentication and access control.

Apply the Principle of Least Privilege: Ensure that users only have access to the
resources necessary for their role, minimizing the potential impact of unauthorized
access.

Unauthenticated access refers to allowing users or clients to interact with a system or application
without requiring them to provide any form of authentication or identification. This means that users
can access certain resources or perform certain actions without needing to log in or provide
credentials.

Challenge 14 — Find an endpoint that does not perform authentication checks for a user.

 Intercepting the Order Details Request

Page 48 of 50
we decided to send a request to this endpoint without including a valid authentication token. The
response came back successful, providing us with the order details without requiring any form of
authentication.

Conclusion
To conclude, securing the crAPI (Completely Ridiculous API) application is crucial in preventing
potential security breaches that could compromise sensitive data, disrupt services, or lead to
unauthorized access. Ensuring robust authentication and authorization mechanisms, proper input
validation, and comprehensive logging and monitoring are vital steps in fortifying the API.
Additionally, implementing best practices, such as rate limiting, encryption, and regular security
assessments, can further enhance the overall security posture of the application. By adhering to

Page 49 of 50
these principles, the crAPI application can mitigate risks and provide a safer and more reliable
experience for its use

Page 50 of 50