An Application Programming Interface can be thought of as a widget in the larger machinery of a modern web application. This widget could return data to an interior part of the machinery, or it could deliver information to someone making a request in their browser. APIs came along with the development of an asynchronous, or RESTY way of web development. In the olden days, web pages were wholly replaced with each mouse click.
The modern internet serves elements of a page as needed, and APIs are a critical part of delivering this information, whether to the browser or behind the scenes to middleware or backend services. API testing ensures that these endpoints don’t disclose data they shouldn’t or perform unexpected actions. The ‘hack’ of Parler in 2021, where even data that users believed they had deleted, was obtained through enumeration of an insecure API.
A vulnerability in an API can be just as grave as a vulnerability found in any other system and can have the same potential, depending on the circumstances, to be company-ending. In short, API testing verifies that no widget has gone rogue.
The engagement will start with a conversation about the client’s infrastructure and software stack. RedTeam will also request any documentation that exists about the APIs. Malicious actors are able to determine these details with enough time and energy, but we ask because the more of this information you are able to provide, the better value we are able to give you. A malicious actor must dedicate time to answering questions like, “What is the tech stack in use?” before answering questions like, “How could a failure of this system serve (my) malicious ends?”
When you are engaging a company to test the security of your systems, it is usually not a good use of limited resources for the tester to dedicate time to replicating information that is easily shared. Having said this, the tester keeps in mind one of the lessons of the Equifax hack: the more complex the system, the harder it is to keep a complete picture of every element in play. Still, having this discussion at the outset gives the tester a chance to ask the client about any unexpected finds, first and foremost to verify whether or not they are in scope.
This conversation is also where we discuss if there are any special circumstances we should be aware of. Testing in a production environment is a common example. The answers to these questions influence the choices a tester will make during testing.
Following this conversation, testing will begin according to a date that will work for everyone’s schedule.
With API Pen Testing, the tester will often begin with manual testing, executing the API with expected and unexpected data. They will move on to automated means when they have a sufficient understanding of how the APIs work, and likely do some further research as well, given that new vulnerabilities are found all the time. From here, if a suspected vulnerability is found, either through manual or automated means, the tester will work on exploiting it.
Evidence is then gathered and the process of exploitation is documented so that when the report is delivered, the client can see how the vulnerability would impact the business, including detail on the impacts on the Confidentiality, Availability, and Integrity of the systems. Following the delivery of the report, RedTeam is available to answer any questions you may have about how findings were exploited and options for remediation strategies.