Scanning APIs
Last updated
Last updated
Once you have discovered an API and used it as it was intended, you can proceed to perform a baseline vulnerability scan. A good reason to perform your testing in this order is to avoid having any of your scans set off a security control like a WAF that results in your traffic being blocked. Ideally, a vulnerability scan will help you find weaknesses that you can then test, confirm, and exploit. Realistically, vulnerability scans are rarely 100% accurate and rarely if ever, identify all of the issues present. So, we will not use vulnerability scans to determine all of the weaknesses an app has, but instead, we will use the scan results to help guide and focus our testing.
When vulnerability scans are applied generically to web APIs the most common outcome is to receive false-negative results. False-negative results take place when vulnerability scans do not detect or report existing problems. For most organizations, this can result in a false sense of security because the scans came back with no evidence of any present weaknesses. The current state of many free and paid vulnerability scanners is that they were not designed for web APIs and often do not detect many of the vulnerabilities listed on the OWASP API Security Top 10. These vulnerability scanners, however, do a decent job at detecting . Security misconfiguration includes missing system patches, unnecessary features enabled, lack of secure transit encryption, weak security headers, verbose error messages, and Cross-Origin Resource Sharing (CORS) policy misconfigurations. In this module, our focus will be on configuring OWASP ZAP to thoroughly discover API security misconfigurations and to get the most out of a vulnerability scanner.
First, if you'd like to see how a generic scan can result in false-negative results, you can experience this for yourself. You can do this by scanning crAPI with Nikto, a web application vulnerability scanner. Open a terminal and run:
$nikto -h
If you run this scan then you should notice a couple of things. The Nikto scan discloses that the web app server is running the OpenResty platform with the version. In addition, X-Frame-Options and X-XSS-Protection headers are missing or misconfigured. Besides these findings, the results are missing the gambit of API-related vulnerabilities that crAPI contains. Keep in mind that the crAPI application was designed with all of the OWASP API Security Top 10 vulnerabilities.
Like Nikto, a generic automated OWASP ZAP scan will run into the same problems with false-negative findings. However, you can configure a ZAP scan to better work with web APIs. The first thing that we will do is to run an unauthenticated scan of the attack surface. We can plug in the target URL, but to improve these results and to make sure we hit everything, we can import the target's API specification file.
You can do this by selecting import and choosing the relevant specification file. For crAPI, select the specs.yml file that we made when reverse engineering crAPI and make sure to add the URL that you are expecting (http://crapi.apisec.ai or http://127.0.0.1:8888).
After adding the file path and target URL select import. Now you can see the Sites window filled with the target's endpoints and API requests.
The next step that you can take to improve the scan results is to perform authenticated scanning. The easiest way to perform authenticated scanning is to use the Manual Explore option.
Set the URL to your target, make sure the HUD is enabled, and choose "Launch Browser".
Once you choose to manually explore, you should see the HUD launch in a browser. Here you can select "Continue to your target". Similar, to the work we did during the "Reverse Engineering APIs" module, we will go through and use the web application as an end-user.
Perform all of those actions again. Sign up for another account, sign in, and use the various features. Make sure to use the HUD to perform certain actions. At the top left of the HUD, you can add your target to the scope of testing. Once you have authenticated to the app and performed a baseline set of actions you can perform an active scan.
On the right-hand side of the HUD, you can set the Attack Mode to On. This will begin scanning and performing authenticated testing of the target. Depending on the scale of the web application that you are targeting, this scan could take a while.
As you can see above, there are many more interesting findings than the initial generic scan that was run. From here you should investigate the results. Work through them and determine which are actual findings and which are false positives. One important thing to note is that crAPI is vulnerable to all of the OWASP API Security Top 10. Based on the current findings from scanning we can see that Security Misconfigurations and Injection vulnerabilities may be present. Even with authenticated scanning, we are missing many of the other vulnerabilities present in the app, which is why we will need to build out additional testing techniques in upcoming modules. Next, we will focus our testing efforts on the top two OWASP API Security Top 10 topics, authentication, and authorization.
You can right-click on the root, in this instance and choose to do an active scan. Once this scan completes you can find the results under the Alerts tab. Here you will typically find security misconfiguration affecting the target host.
