An API Security Testing Checklist… with a twist

I recently stumbled upon a GitHub repo by Shieldify that contained an API security checklist of the most important countermeasures to consider when designing, testing, and releasing an application programming interface. While it’s not the most comprehensive REST API security testing checklist out there, it does a pretty good job of covering many of the important things that the blue team needs to think about.

I thought it would be fun to use that as a base, rewrite some of it and build a starter checklist for developers, testers, and hackers who are responsible for conducting offensive operations to test and validate such controls against their APIs. Think of it as a red team’s API security checkup.

This is in no way a comprehensive or complete list. However, if you aren’t at least doing this… having a more complete list won’t matter anyways for API users.

More importantly, the goal of this article is to help you start to learn about how to look more offensively at web API security testing. As such, I am going to introduce you to the concept of common attack pattern enumeration.

Where possible, I will map each checklist item Shieldify lists against MITRE’s Common Attack Pattern Enumeration and Classification (CAPEC) and create a matching “security testing check” for API testing. You can use that to understand how to attack different parts of the API calls and cross reference that against corresponding CWEs in an effort to communicate any findings you come across to the security triage team.

I encourage you to look at the CAPEC IDs I provide in more detail, especially if you are new to this. The structure provides a ton of useful guidance on the relationship of common attack patterns, how execution flow works to exploit potential vulnerabilities, and what the consequences are if you are successful. It also defines what skill level is needed to conduct the attack, what resources are needed, and what indicators you may trigger because of the execution.

In other words, you can start thinking about how to approach the API target, how to attack it, and how to leave little to no trace.

Enjoy!

Authentication

• Check to see if Basic Auth is in use. If so, maybe you can abuse it. (CAPEC-114)
• Check if the login process has rate-limiting enabled. If so, test to determine max retry logic to tune before attempting any sort of password brute forcing attack. (CAPEC-49)
• Check if cookies, tokens, and/or session data are stored locally in a way that can be manipulated and abused to alter behavior. (CAPEC-39)

JWT (JSON Web Tokens)

• Check to see if you can crack the JWT signing key, allowing you to mint your own auth tokens. Check out my article on using cloud-based GPUs to help with this. (CAPEC-633)
• Check to see if you can manipulate the signing algorithm in the header. (CAPEC-115)
• Check to see how long a token is valid (TTL/RTTL) to understand how long you can abuse a captured or forged token. If the time to live is long enough, you may be able to leverage that in session replay. (CAPEC-60)
• Decode the JWT body to see if the token holds sensitive data in the payload.

Access

• See if SSL/TLS is misconfigured allowing for abuse of the communication layer. (CAPEC-217)
• Check if the HSTS header is present. If not, you may be able to abuse it with SSL stripping or downgrading. (CAPEC-220)
• Check to see if you have access to directory listings and can manipulate path traversal. (CAPEC-126 / CAPEC-127).
• Check to see if the API uses IP whitelisting to provide access. If so, see if you can manipulate the process with the use of forwarding headers like X-Forwarded-For, X-Forwarded-Host, Forwarded, etc. through Adversary in the Middle (AiTM) techniques. (CAPEC-94)

Authorization

OAuth

• Check if you can manipulate the redirect_uri parameter on the client side to force the server to redirect to an attacker-controlled resource. (CAPEC-194)
• Check to see if the OAuth endpoint allows for a response_type of token. See this OWASP testing guidance on why testing for implicit flow vs. code flow is important. (CAPEC-22)
• Check to see if the state parameter is used to prevent CSRF on the authorization process. (CAPEC-62)
• Check to see if endpoints properly honor scope parameters. (CAPEC-122)

Input

• Check each endpoint to determine which HTTP methods are allowed (GET/POST/PUT/PATCH/DELETE) and how the endpoint responds to each request. Is there a possible privilege escalation? (CAPEC-58)
• Check if the Content-Type header can be changed (e.g., from application/xml to application/json, etc) allowing for new input validation test paths. (CAPEC-278)
• Check if the Content-Type header can be changed on a POST (e.g., application/x-www-form-urlencoded, multipart/form-data, application/json, etc.) allowing for additional data to be manipulated. (CAPEC-278)
• Check for input validation on all data fields and/or properties being sent to the server. (CAPEC-153)
• Check for sensitive data (credentials, Passwords, security tokens, API keys, etc) in the URL. (CWE-598 – There isn’t a clear CAPEC for this)
• Check for HTTP parameter pollution (HPP) by adding the same parameter twice with different values in a request and seeing how it responds. (CAPEC-460)
• If an API Gateway is in use for caching and rate limiting, check to see if you can detect the original API endpoint resource and access it directly, bypassing the gateway. This is a common misconfiguration for microservices and serverless functions that leverage API gateways. (CAPEC-554)

Processing

• Map out which API endpoints are properly protected against broken object level authorization (BOLA). I’ve written how to use extensions like Autorize to automate this. (CAPEC-94)
• Check to see if any IDs are predictable or auto-incrementing.
• If the API is parsing XML data, see if entity parsing is possible to allow for XXE (XML external entity) attacks. (CAPEC-201)
• If the API processes XML or YAML data, see if entity expansion is enabled to allow for resource starvation attacks like Billion Laughs or XML bombs. (CAPEC-197)
• Find any locations where file uploads are allowed and see if that can be abused. (CAPEC-17)
• Look for debug interfaces related to the language/framework/platform that can be abused. (CAPEC-121)
• Attempt to manipulate input buffers if the API is not run with NX (Non-executable) stack protection enabled. (CAPEC-123)

Conclusion

OK, I have to fess up. I didn’t map ALL of Shieldify’s recommendations into this checklist. Once it started strolling into CI & CD pipeline protections and monitoring, it was beyond the scope of the exercise here. But I do hope you can see the process I just went through.

Any time you find prescriptive guidance on how to harden an API, think about how a developer would approach that task. Chances are, you can turn the table and instead convert that into a test to see if it was ever done. The use of CAPEC is interesting because you can work backward or forwards… mapping CWE to CAPEC and vice versa to come up with test cases and apply an attack plan.

Now think about how you can build out a more complete API security test plan to include the likes of the OWASP Web Security Testing Guide and/or the OWASP Application Security Verification Standard (ASVS) guidance. Combining those testing recommendations with CAPEC will allow you to get plenty of attack patterns into your test plan and attempt to exploit known potential weaknesses in the system earlier in the process.

If you ever want to explore things like CAPEC in more detail, I highly suggest you check out the Domains of Attack viewer. Even without guidance given to the blue team, you can explore what you might be able to do on the red team. It may even give you ideas of ways to approach a target you have never thought about before.

Give it a try. Have fun with it!

Want more interesting resources on hacking APIs? Make sure you download my free ebook on The Ultimate Guide to API Hacking Resources.