API Penetration Testing: What you should know
It’s All About APIs
Software delivery is all about APIs; organizations are increasing the use of APIs in applications and services. Without proper testing and security practices, threat actors can easily take down a service or access critical data.
Thank you for reading this post, don't forget to subscribe!Because APIs can be accessed in multiple ways, their vulnerabilities may be exploited without the company ever realizing the breach has happened (e.g., hiding within normal traffic flows).
Don’t Let the Unreachable “Best” Defeat the Actual “Good”
Securing APIs requires a layered approach (traditionally called “defense-in-depth” approach). One part of this defense is penetration testing.
Is it the best approach? No. And it’s not a cheap or all-encompassing approach. But is it important? Vitally so.
While there’s no one-control-to-rule-them-all, don’t let the seeming complexity detract from what can actually be done to secure your internet presence.
What about the “Shift-Left” idea?
As a Postman article puts it, “Shifting left is especially crucial to the API lifecycle because APIs are usually produced and consumed by different teams.”
But to tame attempts to make “especially crucial” equate to “the sole factor”: “Standard pre-production testing can find some gaps in API security best practices, but they won’t uncover vulnerabilities rooted in API business logic gaps.”
It’s the Same, Just Different
The API penetration testing process is not quite the same as web application pentesting. APIs present more attack vectors, and they’re at an increased risk of abuse due to their ease of discovery, access from multiple endpoints, constant changes (or lack of updating), and neglect in inventorying.
There are several similarities, though.
Common Ground
Some common elements:
- Methodology
- Pentesters have guided processes that they follow. If you’re scoping out testers, ask what their methodology is.
- Permission, Planning, and Scoping
- Always give and get permission and the specifics before proceeding. Is it a blackbox, whitebox, or gray box testing? What specific resources are to be tested? When and for how long can testing occur? Who’s the contact person? What’s the due date? What occurrences are in and out of scope – e.g., “Can I DoS the app?” or “May I log in with the credentials I find, or just report them?”
- And double-check endpoints before testing. Sometimes people write things incorrectly, and an IP that’s one number off may be a completely different org, and that spells trouble!
- Recon and Enumeration
- Find out all that can be found out about the target resources before actively testing. The more the tester knows, the better the results.
Where is API pentesting different?
There are some aspects that make API pentesting distinct from web app testing.
After recon, read any available documentation. This is similar to web server testing, but API documentation is often more precise and tells how the API is designed and gives specific guidance. NOTE: this is an inherent aspect of many APIs that makes them both beneficial to a company and valuable targets – everyone knows how they work.
Check for WAFs. These will introduce an extra layer of protection for APIs and can throw off a tester. But these can be circumvented because WAFs check for problems in requests, and API attacks won’t always have malformed requests. They’ll appear legitimate because the actual purpose of the testing is to work with the API context for a low-and-slow, not brute force, exploit.
Discover (if not disclosed in initial meetings): How are the APIs authenticated? What is the architecture? Is there rate limiting? [[pen testing aimed at APIs will do a lot more – will look for business logic flaws and use the OWASP API Top 10 list of attack types to try to run these styles of attack]]
Attackers and Defenders
For those who play a defensive role in their organizations, checklists are our friends. Use them to help identify vulnerabilities and take the appropriate steps to patch them. Checklists are also great for tracking the progress of patches being applied and making sure that every resource is updated with the latest versions of software.
But attackers are opportunistic and don’t use checklists; they’re looking to break in by taking apart. In other words, “Defenders think in lists. Attackers think in graphs.” They want to get in and get out fast with as little risk as possible – not perform a thorough audit of everything on the network. Attackers are looking for nodes with their connections and dependencies (think neo4j).
Pentesters, and defenders trying to make life harder for criminals for pentesters, need to approach APIs the same way: what are the connections? Please don’t misunderstand: when performing corporate testing, checklists are necessary. There are so many aspects (e.g., regulatory compliance, adherence to security standards) that something will be missed without a checklist. But the end goal is not compliance or filling checkboxes; the goal is reasonably securing APIs against abuse (whether intentional or not).
Here’s an example – an API pentesting mindmap – of an approach that combines stages, tools, specific items, and general guidance of numerous concepts to help one through a pentest.
What are some common API vulnerabilities?
OWASP maintains the famous API Top Ten list. While there are certainly more than 10, starting with securing and testing against the first few will help testers and defenders. Because the OWASP page has both explanations, sample scenarios, and prevention techniques, I won’t repeat those here. But I will give an overview of the top three.
- Broken Object Level Authorization
- Unauthorized data access to objects can lead to account takeover. Accounts should only have access to view account information that they need to see.
- Broken User Authentication
- If controls such as rate limiting and blocking excessive login attempts are not implemented, an attacker could try 999,999 times to get the right SMS code until access is granted.
- Excessive Data Exposure
- When looking at an API response, is only the necessary information provided? Seeing too much information leads to seeing sensitive information.
Presentation of Findings
There needs to be a report that can be understood by management, and it must address the relevant findings. Each org is different, and each set of findings will be different. Example: because of some open resources such as Venmo’s transactions, testing findings may reveal that private information is visible to the public, but the company accepts the risk because it’s how the API is designed.
All the best on your road to securing your APIs!
