Similar to the security testing of the web application, penetration testing for APIs in the recent times has formed a different class in itself. Whether it’s visible or not Application Programming Interface (APIs) are a crucial part of every aspect of IT and DevOps. However because APIs do not have UI unlike web applications security testing relating to APIs becomes quite complex and also because of the protocols and formats which it uses (like JSON, OPEN, XML etc.).This lack of security concern relating to APIs has rendered a new class of vulnerability in the latest OWASP top 10 by the name of ‘Underprotected APIs’.
Risks associated with APIs:
- Security of APIs developed relies on the developer
Along with the API provider, it is also the responsibility of the developer consumer to secure the API, as it is the developer who is requesting the usage from the API provider and further customizes it according to their need. Different aspects of the API like physical access, authentication exchanges etc. should be secured up to a certain extent by the developer consumer itself. But, however going with the existing norms, it is always said to implement security at the lowest possible level, thereby making the API provider responsible for securing it primarily. It takes a lot of responsibilities and a variety of solutions to implement and put the security in a proper and prompt manner. Properly handling authentication and authorization along with federation and delegation, which is a huge issue in terms of security as exposure of administrator or sysop credential can lead to massive security breaches. Unable to verify delegation and Federation routines, improper session handlings can further lead to replay attacks and session capturing.
The end user and the API developer consumers cannot help providing secured solution to any of these above problems. Using different protocols like SSL, SSH, HTTPS is helpful, but all of it relies on the base, which solely depends on the API host designing the system first to utilize these protocols. So having said these above problem relating to the security implementation, it is always suggested to implement security when it is within the scope of the API provider.
- Improper coding
Starting at the early development phase of APIs, Improper coding might prove to be quite expensive from a security perspective. Irrespective of the language and technology used to develop the API memory overflow prevention, poor error handling techniques, value checking, and more can lead not only to major security flaws but also hampers the usefulness and the functionality for which it has been developed for. The following code snippet below shows that although the API is functional and useful, security flaws still persist in it and how.
The above-given API snippet is written in python that uploads images to the specific root of a known server. The above code works completely fine if we ignore the many security issues in it. For example, there is no type checking implemented in the, thus paving way for anyone to upload any kind of file thereby executing the code to automatically generate URL to run the application natively on the server. Furthermore, the uploaded file’s path is mentioned as the service directory root, thereby giving the user a broader and much more access to the server.
- Misunderstanding the API ecosystem
As the architecture of APIs is evolving, new and more expensive methodologies are emerging for development and management of these APIs, at the same time new security issues are also growing with the evolving API lifecycle. Unfortunately, many developers are completely oblivious of the security flaws that are being unintentionally and unconsciously being adopted with every development evolving in the field of API.
For example, the breakthrough in the field of cloud computing, especially in terms of the evolution of Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service, has paved way for computing, analyzing and storing this huge amount of data off-site. This has thus decentralized the servers and local resources which once use to utilize the APIs locally. Although this being a good thing it also has some negative impact thereby making it vulnerable. For example, the same physical space being shared by the server and that of a virtual API server could risk the cryptographic keys to hijacking. Even if we tend to ignore those virtual attacks, there are still security issues related to physical threats, this is because a cloud server is not local to the API provider/Developer, thus leaving hardware hosting secure password hashes or user account files vulnerable to malicious use and environmental damage.
- Trusting the API Consumer With Too Much Control
One of the largest security risk involving an API is with the number of the end user accessing and using it. Irrespective of the type of API, syntax, and language or the development approach, the security of an API is guaranteed until it’s used.
As long the new API does not receive any request it is considered to be secure. However, with the subsequent request that keeps coming in thereafter, the API renders itself wide open to end users for different kinds of manipulation. For example, the developer often does not enforce any password complexity and usage, and sometimes also allowing the same session ID tokens for multiple usages, which is a great security issue.
That’s not to say that every user must be treated like a Black Hat hacker- as most of the users will always use the service as it was intended for, but having said that it still leaves a large number of unknown users who would try to access the API illicitly thereby trying to break the system and making it vulnerable.
So, the API provider (developer) must always make sure to implement session length and concurrent connection limitations, enforcement of strong password complexity and length.
Authored By - Sayan Upadhyay
TCS Cyber Security Practice