As the modern web becomes ever more complex, the number of web vulnerabilities, and their complexities, have only intensified the need for developers to have a toolset designed for education and understanding. OWASP has created a tool to fill this need called crAPI. crAPI is a great way to help your security teams test the top ten most critical API security risks as identified by OWASP. Below, we’ll explore the tool and see what it accomplishes.

What is crAPI?

crAPI, the “Completely Ridiculous API,” is an open-source tool developed by the OWASP, or Open Web Application Security Project. The project intends to create a purposefully vulnerable application to help developers learn about common vulnerabilities and see them in action. cRAPI focuses on real-life vulnerabilities documented in major APIs and systems, and specifically tests a set of issues identified as part of the OWASP Top Ten.

Reviewing The OWASP Top Ten

Before we get into how to use crAPI, the OWASP Top Ten bears some discussion. This document serves as a foundational element of the OWASP approach towards education around common vulnerabilities, representing a common set of web application risks. While crAPI creates an area of exposure representative of multiple domains, the issues at hand roughly fall into these categories.

• Broken Access Control: This area is concerned with issues around access control. Broken access control can take the form of both broken rules and circumvention of those rules due to their intrinsic relations, and covers attacks in which the vector in question is an escalation rather than a direct attack.
• Cryptographic Failures: This element is concerned specifically with issues around cryptographic failures, such as failures in data encryption at rest or in transit. Vulnerabilities that fall into this domain can take a wide variety of forms, both in terms of improper implementation and untrustworthy vendors.
• Injection: Simply put, injection is the insertion of code into a place where it’s not meant to be. In common usage, this can cause an escalation of privileges, the running of arbitrary code, a bypass of cryptographic standards, and worse.
• Insecure Design: This type of vulnerability is more encompassing as it’s not typically the result of a particular vulnerability. Instead, it results from many choices made in the process of building out a system. Insecure design can result in various additional failures across the types represented in the OWASP Top Ten.
• Security Misconfiguration: As the development space has moved to highly agile and customizable implementations, the rise in issues around misconfiguration has become marked. This category similarly represents a wide range of issues, including simple misconfiguration to more complex webs of misconfigured services.
• Vulnerable and Outdated Components: Previously called “Using Components with Known Vulnerabilities,” this kind of vulnerability results from a service using components with known issues, especially if they are obsolete or otherwise outdated.
• Identification and Authentication Failures: These types of failures include issues in which users are identified and authenticated incorrectly, typically leading to privilege escalation or impersonation issues.
• Software and Data Integrity Failures: This issue has to do with integrity. In short, things like data flows or versioning are leveraged as a vector due to the assumptions of trust that fall in this category, including common update hijacking, credentialing, and other such issues.
• Security Logging and Monitoring Failures: Attacks in this domain have a great deal of impact across the organization. Failure to properly log or monitor can result in a wide range of issues, and reduced visibility makes attacks more likely to succeed without grabbing attention.
• Server-Side Request Forgery: This type of attack is when a vulnerability is used to force a server-side application to make a request to an arbitrary location. This request can take multiple forms, such as forcing a server-side application to connect to a fake authentication server or even escalating an attack made elsewhere in the system.

Installing crAPI

Now that we understand the OWASP Top Ten let’s dive into using crAPI. When it comes to installing the tool, OWASP presents several options. The first and easiest is simply using the prebuilt images provided by OWASP. To do this, a Docker instance can be created using the following code snippets.

For a Linux machine:

curl -o docker-compose.yml https://raw.githubusercontent.com/OWASP/crAPI/main/deploy/docker/docker-compose.yml

docker-compose pull

docker-compose -f docker-compose.yml --compatibility up -d

For a Windows machine:

curl.exe -o docker-compose.yml https://raw.githubusercontent.com/OWASP/crAPI/main/deploy/docker/docker-compose.yml

docker-compose pull

docker-compose -f docker-compose.yml --compatibility up -d

You can also pull the development version specifically by calling the versions as follows.

For a Linux machine:

VERSION=develop docker-compose pull 

VERSION=develop docker-compose -f docker-compose.yml --compatibility up -d

For a Windows machine:

setx VERSION develop && docker-compose pull

setx VERSION develop && docker-compose -f docker-compose.yml --compatibility up -d

OWASP also provides an option to use crAPI within a virtual machine. To use this method, the user must have Vagrant and a virtualization software solution. In such a case, the following steps can be used per the documentation:

Clone crAPI repository
$ git clone [REPOSITORY-URL]
Start crAPI Virtual Machine
$ cd deploy/vagrant && vagrant up
Visit http://192.168.33.20

Using crAPI

crAPI presents two different options for its use. First, you can try and attack crAPI using a set of challenges. OWASP has created a set of challenges that be found as part of its official documentation. While these challenges represent a wide range of topics, two secret challenges are undocumented and are not referenced in any internal documentation.

This first approach is helpful for developers trying to see examples of specific issues in live code. Since the vulnerabilities included in crAPI (and by extension the OWASP Top Ten) can take a wide variety of practical forms, it can often be difficult to conceptualize what such an exposure would look like in practice. These challenges are great, as they both suggest a practical example of the attack (for instance, one challenge is to force the API to give the attacker a free item) and force the user to discover the modality and methodology of such an attack.

The second approach crAPI allows is to treat the API as a “black box test.” In this style of testing, the user tries to break the API without guidance as to how the system is already broken and how those vulnerabilities work. This approach demonstrates the interconnection of vulnerabilities. Much of what makes crAPI a practical test subject is the interplay between vulnerabilities and their resulting issues, and this is something that can be lost when using crAPI in its first manner.

Too often, vulnerability simulators are simplistic, offering only a small set of common problems that are obvious and easy to execute. crAPI, on the other hand, represents a more complex web of vulnerabilities. Every vulnerability in the crAPI system takes some creative effort to trigger, and the complexity of the interactive vulnerabilities forces users to understand just how quickly such complex systems can get out of hand when even a single component is vulnerable.

Conclusion

crAPI represents an evolution of simple vulnerability modeling. It presents a complex set of vulnerabilities whose exposure exists at the intersection of the moving parts. In this way, crAPI serves a wonderful function and fills a gap in the usual modeling and experiment approach. crAPI is not the only tool a novice developer should consult to understand common API vulnerabilities, but it serves as a very strong introduction.

What is your opinion of crAPI? Do tools like this serve a practical purpose, or are they just good thought exercises? Let us know in the comments below!