Luke Stephens is a father, husband, hacker, pen tester, and full-time Application Security Engineer and Quality Assurance Training Manager at Bugcrowd
APIs are the interface between an organization’s most sensitive data and the end-user. And they’re everywhere. The last decade has seen a dramatic shift from traditional server-side web applications to Single Page Applications (SPAs) with API backends, meaning API security should now be a concern for most organizations with web presence. In fact, Gartner predicts that by 2021, 90% of web-enabled applications will have more surface area for attack in the form of exposed APIs rather than the UI, up from 40% in 2019. Unfortunately, increasing scope and complexity also makes securing these assets harder than ever.
Organizations now offer APIs as a service for developers to hook into their datasets for more streamlined access. New user personas have evolved different use cases for accessing and handling sensitive data, resulting in custom logic that must also fit within the access permissions required by the organization for data privacy and handling.
These changes open up new opportunities for attack. In this blog I’ll outline a common scenario that shows how automated security checks can miss critical unauthorized data-access vulnerabilities in just 3 steps.
Let’s say that you have an API endpoint to manage users of an application.
/api/users/123
If you access the above endpoint, the details of the user with an ID of 123 will be returned. If you are accessing the endpoint as an unauthenticated user, only names and profile pictures should be returned. If you are a normal user of the application, user’s biographies and recent posts should also be returned. If you are a site administrator, the user’s home addresses and emails should also be returned.
But what if a mistake was made during API development? What if a developer didn’t apply the correct user restrictions to the `/api/users/123` endpoint? An unauthenticated user could then access the home addresses of every user. We see this frequently, so it’s easy to imagine how this could go unnoticed in most development shops– even ones that have great automated security practices built into their deployment pipeline. Let’s take a look at how this issue might make it through that process:
- All automated QA tests passed because the endpoint returned all of the necessary data without errors (the test did not know to check that additional details were also returned).
- Automated static analysis scans were built into the deployment pipeline, but they have no understanding of the custom user roles and permissions that are required/expected for this application. They simply tested for 500 different types of vulnerabilities and found that none of them worked.
- Burp Suite was used to run an active scan of every endpoint in the API prior to release. As it is just another automated scan, it has no human intelligence or context about the permissions that should be associated with each user role, so it also returns no vulnerabilities.
Bugcrowd has seen submissions against API targets double in the last year, with this particular type of vulnerability being one of the most common. Most scanners aren’t capable of rooting out this type of event, weighing it against contextual information, business impact, and suspected motivation to positively identify, prioritize, and escalate. The human element is an essential part of improving the security posture of any organisation, and API endpoints are no exception. That’s why everything we do at Bugcrowd helps organizations quickly scale and deploy human intelligence for all of their security testing needs. For more information on Bugcrowd API Pen Test, or to learn about any of our security testing solutions, visit our website, or start building your program today!
