We review APIcheck, an open-source tool by OWASP that helps scan an API for critical vulnerabilities
Having the ability to run checks on an API is vital. Providing adequate functionality and security requires testing the API and ensuring that it matches specifications. A great user experience depends on predictable and consistent developer experience, which is only attainable through standardization of the underlying codebase. At every level, having a toolset to ensure consistency is vital.
Enter APICheck, a tool recently open-sourced by OWASP. In our space, OWASP is most well-known for its discussion of API vulnerabilities, and as such, they are a prime candidate for the creation of a product to scan for those vulnerabilities. Below, we’re going to look at their answer to the consistency question, APICheck, and give a general impression of using it.
What is APICheck?
APICheck is an environment built to “create execution chains” for the purposes of testing. In the context of APIs, the concept of an execution chain is often taken for granted, but there’s some value in discussing why an execution chain is important. API calls have a defined start and a defined end — it is this process of making a request, transforming the resultant information, and then receiving an output that forms an execution chain.
These chains, however, don’t happen in isolation. Often, errors in specific execution chains reflect errors within the API itself (or, at the very least, suggest a mistake that is systemic to either the API or its environment). For that reason, isolating execution chains and then testing those chains repeatedly can result in actionable feedback.
This is the main benefit of something like APICheck — being able to use powerful tooling to test the same areas repeatedly produces reliable data that can be tested, retested, and verified.
APICheck DevSecOps Tools
To understand the specific use cases of APICheck as part of a security flow, we should look at the toolset on offer to see how the execution chains are created and interacted with. Some of this information is pulled from the official documentation, which offers specific implementation guides and example results.
Replay HTTP Requests
This function is a mechanism by which previous requests can be repeated in a controlled manner. In essence, the request read from
stdin is sent once more, with new responses captured; the old responses are stored for further processing. Request replaying is an obvious but powerful tool, allowing developers to repeat requests in a controlled manner to test specific functionality, error reporting, interactions, etc.
As an example flow for this kind of function, consider repeating a failed execution chain in an unstable environment. Let’s assume you’re making an API call, but it is unclear whether the network is causing repeated failures or if there is an error in the API itself. You could make requests regularly, but given the variety of interfaces and variables introduced during a typical execution chain flow, we need a better solution.
With HTTP replay, you can simply replay the same function in the same way through the same flows to get a predictable result. If you keep seeing failure regardless of when you replay the function, the odds are the function itself is the problem. If you see intermittent success on the other hand, and the only variable is the network itself, you can start to understand where in the chain the execution has broken.
Not all execution chains are trustworthy — there are many times when you may want to test a function but don’t want to directly connect to the end of that chain. Within the documentation is a rather good example of such a use case:
“Every day we visit a lot of sites on the Internet. Each of these sites have a lot of resources and do a lot of connections to external servers, but… how can we check for connections for suspicious sites? And how can we script some actions?
You can install an Antivirus. You can use some additional software that try to ”protect“ you against this type of sites but you can’t launch any custom action (or shell script!) when you detect them. Why not use APICheck for that?”
This tool allows for the testing of calls by routing through a remote proxy. In doing so, you can create a layer of isolation that insulates the testing systems from the resource being tested. This makes sense for any potentially malicious resource, but it also helps to test specific concerns regarding geo-limited or isolated data streams. In other words, you can find out if the problem is the resource, or if the problem is you.
It should be noted that APICheck is not simply limited to remote proxy functions, either. There are times where a local proxy is most appropriate, especially when you are trying to test local devices, functions, and codebases that you already control but are nonetheless external to your core API. For this, APICheck also provides an option, allowing for quick, easy testing through a man-in-the-middle proxy.
Sensitive Data Detector
When looking at the whole API experience, APIs are built largely on open sharing of information. That being said, there are some legitimate cases in which data should not be shared, whether it be business logic, internal IPs, or just information that is in some way privileged. Worryingly, it is not uncommon for this data to be exposed in some way. APICheck has a tool to check for this data and ensure that sensitive data is not exposed improperly.
The method by which APICheck does this is rules-based, depending on a simple YAML file to set requirements for data in the execution flow. This is especially useful if you’re not entirely sure what element of the flow is leaky. With overly complex APIs, it is entirely possible that the source of sensitive data exposure is not at the top-level interaction, but instead buried in some additional subcalls being run on other data stores. With this rule-based method, you can start to narrow down where this exposure is as you narrow down function by function.
This is a great way of testing excessive data exposure, one of the top 10 vulnerabilities noted by OWASP. Not all data exposure is going to display obviously in the return data — having an automated system to test based upon a set of pre-formed rules can go a long way to managing this type of risk.
This set of functions are best used for checking security arising from both code and practical implementation. It should be noted that the solutions are great ways to test for some common errors flagged by OWASP, including broken function-level authorization, issues with resourcing and rate-limiting, and broken user authentication.
JWT Token Validator
The JWT token validator is exactly what it sounds like — a tool to validate JWT tokens and their issuance against a set of practices and standards. It performs this by accepting either an argument or a Request/Response object from
stdinput. Once the value is in the system, it’s run against a set of checks to verify that the header and standard claims fields are complete, valid, and properly configured. Additionally, the validator will check signature verification, ensuring that the JWT is usable for form and purpose.
A linter is a tool that allows a developer to look at creations in a specific language to look for bad code. With this in mind, APICheck has developed an OpenAPI v2 and v3 linter to help add this tool to the APICheck toolkit. The tool is a simple input and output interaction — it accepts the OpenAPI input as an argument (or reads the input through
stdinput) and outputs either the same definition (if no errors are discovered) or a list of errors.
OpenAPI v3 Checker
APICheck also provides a tool to check the endpoints in an OpenAPI v3 specification against a set of security and semantic rulesets. Broadly based on stoplight/spectral, this is better seen as a “best practices” tool, ensuring that the input adheres to a set of expectations, standards, and requirements.
APICheck from cURL (acurl)
APICheck also provides some basic functionality to commit an APICheck function from cURL. APICheck has made this tool as simple as possible by keeping the form and function identical to cURL. In essence, this tool simply issues a curl request in the command line. From here, the tool translates the binary curl into a
reqres object for further manipulation.
A General Impression
There’s nothing truly groundbreaking about APICheck in theory — these are all relatively common-sense tools that any developer or tester would appreciate. The true value of APICheck comes from two core attributes which make it a strong contender for usage.
First, everything is cleanly combined, and the user experience has clearly been made with simplicity in mind. This might seem like a minor facet of any system, but simplicity is incredibly important in testing and error checking. Any additional complexity in such a system necessarily introduces complexity to the overall error-driving system, and as such, can lead to confusion or ignorance of long-term issues. Having a simple way to repeatedly prove that something is creating an error is very beneficial.
Secondly, the fact that APICheck exists as a singular combined entity means that it can be used as a singular instance. Too many systems like this exist in a multitude of modules, plug-ins, or add-ons, and this can create confusion and reduce overall effectiveness. Having a clean, single package through which a good share of testing can be accomplished is of major benefit to almost any development group.
Ultimately, any resource that helps API developers streamline error-checking and reduce common issues is a good one in our book. APICheck is pretty straightforward in its application and function, and serves this purpose well. Users will find that the straightforward implementations are simple to use, and provide an adequate amount of data and transformability to ensure that checks are thorough.
What do you think of our overview? Have you used APICheck? Are there other similar tools you might recommend? Let us know below!
Source: Nordic APIs