The What, Why, and How of API Penetration Testing
For any entity, it is essential to penetration test the API to safeguard against attacks and exposure of critical applications as well as confidential and sensitive data.
Join the DZone community and get the full member experience.Join For Free
I have come to realize and appreciate when having conversations about API Penetration Testing with colleagues and other professionals that not all understand what API is. Yes, sure it means an Application Programming Interface, and it is a software component that enables different systems/applications to interact with each other, but there is a bit more to its story...
- The most common description for API is that it acts like a messenger to send a request from an entity (a person or an application) to another application and get a response.
- The API is a system in itself; it is a toolset consisting of codes and commands that can be used across multiple applications, can be reused, and go a long way in making the lives of developers easy and productive, as they do not need to create code from scratch.
- As a system/application user, we do not need to know what the API is made of. We simply make a request of the application, wait for the API and underlying application code to do their thing, and get a response.
If we had to draw a parallel with everyday life, let’s consider the post office. The postal system is a robust system in itself; made up of rules, codes, and policies, etc. that enable to function repeatedly for all mailing purposes.
A person posts a package to be sent to another, and the recipient could be in the next block, or a different city, state, country, or continent. In any case, the postal system (API) can deliver the package (request) from one entity to another and deliver back a response.
What is API Penetration Testing?
On a high level, functions and methods within the API are tested to determine:
- If and how they could be abused,
- Whether authorization and authentication could be bypassed,
- Whether any form of malicious data entry — SQL injection, cross-site scripting, etc. — does get a response with the result of data being displayed.
API penetration testing applies to both SOAP and REST APIs.
Why do API Penetration Testing?
Loopholes and gaps in an API would not only allow attackers to exploit the API but any and every application which is associated with the API. Hackers can bypass the API and get access to all data within the underlying application, the application logic, and other internal infrastructure.
All businesses and customers using the API would be vulnerable to cyber-attacks due to the API not being robust and secure.
It opens the gate to data breaches, system and/or network takeover, stealing data for ransom, performance issues, defamation, and other information security hazards. It’s for this reason that exploitation of APIs has become very lucrative to hackers.
Closer to home, there was also an API breach against an Australian property valuation and consultancy firm resulting in the exposure of home loan details of their customers and consequently, serious damage to the firm’s reputation and loss of business.
For any entity, either developing an API or using an available API, it is absolutely essential to penetration test the API to safeguard against possible attacks and exposure of their critical applications as well as confidential and sensitive data.
How to do Effective API Penetration Testing?
Let’s discuss how API penetration testing can be effectively carried out.
Before starting the testing activity, preparation is required. The tester needs to collect as much information available on the target API that is to be tested. Information required includes, but is not limited to:
- IP addresses.
- Definitions of the endpoints and all related details.
- Authentication credentials.
- Examples of calls and valid responses.
- A detailed list of test cases.
- All available documentation.
It usually is the onus of the tester to collate all preparatory details, however, companies can help reduce the time involved by keeping this information ready and documented. This is a good read for companies that require the API penetration testing to be done, on how they can be prepared with presenting the necessary and supporting information to the penetration tester.
If thorough, all it will take is for the tester to review and ask for any additional details and delve straight into the testing.
On acquiring the required details and documentation, the penetration tester begins the enumeration task of the target API on both application and network layers. This involves identifying and noting down the usernames, machine names, network resources, and services of the application. This process helps to understand which weaknesses or loopholes may be present in the API.
These are the top 10 API security vulnerabilities identified by the OWASP project. The tester also performs automated scanning and evaluation of the outcomes in this phase.
Aha…this is the fun part! The tester now starts exploiting the vulnerabilities discovered earlier. The aim is to deduce to what degree the tester can penetrate through the loophole and what extent of damage is possible assuming a hacker is able to do the same. A risk rating gets associated with each vulnerability. There are several ways to test the top API security vulnerabilities. A few of these are listed below:
- Fuzz testing — This is a black box software testing method to find loopholes by applying malicious data injection.
- Command injection — Method to test if the web application provides information to an HTTP request originating from other commands like a database command, system call or call to an external service.
- Authorization on all endpoints — Testing that the API authorizes every request before processing and providing a response.
- Authentication on all endpoints — This test goes hand in hand with authorization. Test authorization with and without authentication and test the privileges of all user roles.
- Parameter tampering — Check for hidden and fixed fields and manipulate them to test if the server still correctly validates them.
A well-structured, detailed, informative, and meaningful test report is a mark of a great tester! After the completion of the penetration testing activity, the tester will report on the vulnerabilities identified, levels of penetration, and risk rating. Findings are detailed, and recommendations are provided as to how the company can plug the vulnerabilities.
Such a report becomes a critical tool at the strategic level for business leaders to make informed decisions regarding the roadmap of their applications and systems.
It cannot be reiterated enough that fixes also need to be tested. A company may implement some or all the recommendations provided in the testing report, however, simply that is not enough to say objective achieved! Their effectiveness in resolving the vulnerabilities should be evaluated.
Retesting should ideally be performed by the same API penetration testing partner who performed the original activity as they are now familiar with the application, can appropriately attest to the effectiveness of the resolution, and ensure that no other security loophole has been exposed in the process.
Finally, like all other types of testing, penetration testing is not a one-time activity. There is no limit to how threats and cyber-attacks are developing today. Any business should budget for security testing, undertake it as a periodical activity, and also when rolling out new or enhanced applications.
To sum up, APIs are a part of our everyday lives whether we realize it or not. They have made technological advancement within the Cloud, IoT, web, and mobile applications possible. An individual engages with APIs in almost everything they do on their mobile and computer.
With the amount of private, confidential, and sensitive information that gets exchanged via applications, it is extremely critical that rigorous penetration testing of APIs should be carried out.
Published at DZone with permission of Cyril James. See the original article here.
Opinions expressed by DZone contributors are their own.