By Sairam Bollapragada & Sandeep Mehta
Technology will keep evolving and the existing platforms will keep transforming to make our solutioning richer with far more reaching impacts. API is the evolving technology glue which is promising strategic and much higher complex communications between the applications with many of the technologists vouching for them.
Just to strengthen the case and context here, Ovum Survey mentions that 30% of APIs are designed without the inputs from the infosec teams, 27% proceed with the development without security teams weighing the same, while 53% of IT/security professionals feel security teams should be responsible and 47% feel it should be developers. Of the API platforms used by companies (borrowed or in-house developer), only 22% had protections from 4 critical attack parameters – developer errors, web/mobile API hijack, automated scraping or malicious usage). 45% of the API Management platforms are infested by the rate limiting features. The list and arguments go on.
What are the threats to an API Platform
There are some jot-it-down parameters which should be hard-looked at whenever an API based solution design becomes a suspect. Let us look at them and ponder on detections or workarounds.
- Unprotected APIs: API’s should have prioritized insulation built around them. REST, SOAP, make access strictly controlled as back-end systems lack access control, management and monitoring. Exposed APIs must be dynamically scanned to ensure system exposures to unprotected assets via APIs are identified whenever there are requests made for access through the API layers.
- Hack-in Attempts: The attackers have high sustenance to break into the systems with spectrum of persisting techniques. Effective usage of rate-limiting services via API gateways to choke access requests and detect break-in patterns will help, upfront security testing and policy designs to block out users with patterns of malicious failed break-in attempts will be good strategy.
- Injections: High Impact attacking techniques like the SQL injections can become a most serious security failure with all your information compromised. One of them could be for output data written back to the API caller, is the source of data authentic and how is the encryption taking place? What is the extent of the data user control? Etc. This being a very vulnerable part, tools like SQP Map for testing the SQL injection, Burp Site for the same or even cross-site scripting are useful to prevent such threats.
- Strong Authentication!: APIs are designed to be exposed for external usage and hence every caller should be authenticated. The authentication cycle must be completely audited and checked from request initiation to termination using approved authentication standards. Application level testing to ascertain weakness of API approved authentication protocols would greatly assure validation of calling applications token.
- Session depravity: Not knowing who is the caller of API when the tokens are corrupted or cannot be authenticated will deem it impossible for API servers to differentiate between well-intended and ill-intended access. Tokens when tampered or replayed with altered privileges can create such a scenarios. Token-protection schemes like hashing and ensuring tokens are fresh using verified timestamp will help. A test suite developed to check token tampering is identified/tracked, or only accepted from authorized sources is mandated.
- TLS/SSL Protections: TLS/SSL Protection makes sure that data transferred between users/sites or between two systems becomes impossible to read. It uses encryption algorithms to scramble data in transit.
- Trusted V/s Trustworthy: A trusted computer system is a system that is trusted to perform security- or safety-critical operations, a trustworthy system is a system which has already been trusted and secured using encryption methodologies.
- API Right Usage: An API should be used for what it is designed for. Many times the implementation on the API platform exceeds the functionality available on the platform. This exposes the whole platform to new set of risks. The limitations of an API platform have to be strongly kept into consideration whenever it is being evaluated for any solution. Also one fact to be kept in mind is that the API should peacefully Coexist
- Poor Code: Poor Code on an API exposes the platform to lot of vulnerability, examples of Poor Coding on API are not implementing certificate based authentication and not restricting IP addresses to filter only from known sources. This will expose the API platform to all external IP’s and anyone with basic skills can access the API and perform their operations.
Finally, whenever an API is being designed or being evaluated for usage, the base security parameters have to be sufficiently considered and evaluated. The evaluation or design of the product should always keep enough room to extend security features as and when required. There should also be enough facilities to implement remedial measures or alerts which will alert the users whenever there is any security threat or breach of the API.