Alissa Knight is a recovering hacker of 20 years, and is one of the leading IoT/connected device hackers in the industry today, so when it comes to hacking APIs she’s seen a lot. If you want to test and secure your APIs what should you do?
Her advice: Go fuzz yourself!
Alissa and Detectify bring you new research on the efficacy of fuzzing as part of the web penetration testing toolkit and especially of APIs. Knight’s full research report provides technical evidence and a detailed walkthrough of how fuzzing of APIs was conducted. Some of the tools used include OpenAPI, Kiterunner and RESTler. The results are available in this downloadable whitepaper.
Here are some highlights from the whitepaper:
The general approach to penetration testing and vulnerability assessments should include testing APIs, and it typically checks for the OWASP API Security Top 10. There’s a number of tools to choose from that run both static and dynamic testing analysis, but when the penetration tester doesn’t include fuzzing in her methodology, this can leave a number of critical vulnerabilities undetected.
This paper was written for red team members who want to learn how to properly perform comprehensive penetration testing of their APIs by incorporating fuzzing into their tactics and techniques used in testing.
- Omitting fuzzing from your penetration testing of APIs leaves vulnerabilities undetected that other tactics and techniques won’t find
- Fuzz testing of APIs is setting the value of API operation parameters to a value that the developer didn’t expect to receive
- Because APIs process untrusted inputs, fuzzing is fundamental to the penetration testing process, often finding vulnerabilities missed by static program analysis and manual code inspection.
- Content discovery is the identification of unlinked files and folders in a web application. Specifically when targeting APIs, it is an effective tool when attempting to discover undocumented API endpoints.
- API documentation is different from API specifications, such as OpenAPI (formerly Swagger). API documentation provides a reference manual for both developers and non-developers in how the API behaves and what the expected inputs and responses are in plain English.
- API specification files such as OpenAPI is a format for describing an API, defining all of its available endpoints (such as /R4/patients) and operations (such as PUT), supported authentication methods, contact information, and more. Currently at version 3, OpenAPI files are clear text and written in specific languages, such as YAML or JSON.
- HTTP verbs (methods) specifies a specific action for the API endpoint to perform, such as
POST(the most commonly used verbs), and for REST APIs,
DELETE. Each verb corresponds to a particular action and expected response code, such as 200 (OK), meaning the action was performed successfully; 401 (Unauthorized), or 404 (Not Found), meaning the file or resources doesn’t exist. Other response codes exist, but these are the most common.
- Content discovery in APIs, specifically to the end of discovering API endpoints requires patience. It wasn’t until about two hours into the scanning effort and attempting different base URLs before I was able to get something other than a HTTP 403 or 404 error code response from the EHR systems I was targeting in my vulnerability research campaign. When I finally did, it was a HTTP 200 and HTTP 415 response to a
POSTto an endpoint that I sent to Burp and continued to manipulate within Burp Repeater.
Get your copy of Go Fuzz Yourself: How to Find More Vulnerabilities in APIs Through Fuzzing by Alissa Knight.
How can Detectify help?
Detectify is building web app security solutions that are automated and crowd-based. By collaborating with ethical hackers, business critical security research is put into the hands of those who need it most to bring safer web apps to market. Curious to see what we will find in your live web apps? Start a free 2-week trial today.