An API (Application Programming Interface) can be defined as a set of instructions, written in code, that allows for communication between software over the internet. APIs have become a key component of the overall DevOps process, allowing not only the seamless integration and communication between software and servers over the internet, but also improving the overall DevOps process and allowing for more complex software to be built with relative ease. The successes recorded by using APIs have seen its usage and popularity skyrocket, especially over the past 12 months.
Yesterday’s API Attacks vs. today’s API Attacks
Due to their ever-growing popularity, APIs have become a key focus for cyber-attacks. In the past 12 months alone, API attack traffic grew by 681%, with 95% of companies reporting an API security incident following a research report.
An API attack can be described as abuse or illegitimate usage or attempted usage of an API for malicious intent, usually to gain illegal access to a server to exfiltrate data, or to cause service disruption.
In the past, API attacks mostly relied on targeting known vulnerabilities, such as a SQL injection attacks, and the XSS attack. Today, API attacks are far more sophisticated – bad actors poke and prod to learn the business logic gaps in a company’s APIs and target those gaps.
How do yesterday’s API Attacks work?
Since APIs serve as a gateway for communication between software over the internet, they often store sensitive information regarding implementation methods and their structure. When an attacker gains access to this information, it can be used to launch cyberattacks, particularly ones that exploit known API vulnerabilities or improperly configured APIs. Thus, API attacks work when there is an abuse of a vulnerability with an API, leading to unauthorized access or data leak.
Want More Tech News? Subscribe to ComputingEdge Newsletter Today!
Types of known API vulnerabilities and how to protect against them
- SQL Injection Attack – An SQL injection attack uses specially crafted malicious SQL code inserted into input fields through the SQL database to potentially gain access to information that was not intended to be displayed. Applications with poorly developed code are more prone to SQL attacks.
Input validation should be implemented. Input validation ensures that user input matches the expected parameters. These guard against both SQLi and XSS attacks.
Other Types of Attacks on APIs
Today, most attacks exist with the intent to gain unauthorized access to servers by exploiting API vulnerabilities subsequently leading to service disruption or data theft. Some of the most common attacks against APIs are:
A distributed denial-of-service (DDoS) attack on an API occurs when an attacker floods the API’s memory by requesting several thousand connections simultaneously. The intent is to overwhelm the memory and lead to a disruption of service by making available resources inaccessible. While DDoS attacks do not lead to information disclosure, they are intended to frustrate instead.
Recommendation – All inbound traffic should be monitored, filtered, and verified. Rate limiting should also be implemented.
Man in the Middle Attack (MiTM)
A Man in the Middle Attack occurs when an attacker sneakily intercepts, relays, and/or modifies requests or communication between two clients. In the case of APIs, an attacker can intercept communication between a session token issuing API and an HTTP header and a user. This can grant the attacker access to a user account, potentially leading to data and personal information theft.
Recommendation – All network communications should be encrypted using TLS. TLS ensures that the connection remains private, with each connection having a uniquely generated encryption key.
Improper Asset Management
This type of API attack occurs when there is more than one way to access an application database environment. Usually, during the production state of applications, several API endpoints are connected to the production environment; when these endpoints are forgotten and not deleted, it allows for an opportunity for an attacker to use them to make API requests and potentially gain access to sensitive data.
Recommendation – All APIs used during the production stage should be properly documented so redundant ones are deleted to prevent unauthorized access.
Poorly encrypted communications
Transport Layer Security (TLS) offers the most basic form of encryption for data transmission over the internet. This ensures that transmitted data cannot be read in plain text, thus adding a layer of security when transmitting sensitive data. Poorly encrypted traffic can lead to MiTM API attacks.
Recommendation – TLS should be used across networks, so network traffic is encrypted, thus making it impossible for data to be read by attackers in the case of a MiTM attack.
Excessive Data Exposure
Sensitive data are regularly processed and transferred by web applications using APIs. Data exposure thus can occur, usually when an API does not filter the responses before it reaches the client. Data exposure can lead to unauthorized access to information such as credit card information, session tokens, passwords, private health information, and much more.
Recommendation – All APIs calls and responses should be filtered and verified so that only authorized requests and responses are allowed to pass through.
Broken User Authentication
API authentication is a core service that identifies and authorizes clients to access applications. Broken user authentication occurs when there is a weakness in both the session and credential management. This can lead to the authentication token being stolen, further enabling attackers to use them to brute force a web application or gain unauthorized access.
Recommendation – API Developers should ensure the right standards are met when building APIs, and API keys should be avoided for user authentication. Multi-factor authentication should also be implemented.
Broken Object Level Authorization
A Broken Object Level Authorization is a type of insecure direct object reference. It occurs when object-level permissions are not set properly, leading to the unauthorized access of resources using a user input functionality.
Recommendation – User authorization should be appropriately managed, particularly for logged-in users throughout the authentication process.
Mass assignment occurs when a user can overwrite server-side variables by utilizing specially crafted requests to include parameters that adversely affect application functionality. Mass assignment can happen when a request body is parsed as an object or exploiting certain framework-level autobinding features such as Spring and .NET.
Recommendation – Autobinding functions should not be used when developing APIs. Also, limit the properties that are modifiable by clients. This prevents parsing of request body’s as objects.
Parameter tampering happens when an attacker manipulates the parameters (usually stored in cookies, hidden form fields, or URL Query Strings) exchanged between server and client to modify or steal application data.
Recommendation – Web application firewalls can guard against parameter tampering. Whitelisting the format for the application’s inputs and encrypting the session cookies also helps guard against parameter tampering.
As APIs continue to be widely adopted by organizations and individuals for software development and integration, there is a need to understand the risks associated with using APIs. These risks majorly are in-line with the vulnerabilities associated with APIs. While it is near impossible to completely protect an API against all forms of attacks possible, understanding the well-known and frequent attacks against APIs not only helps broaden your understanding of them but also allows organizations to make the right decisions when mitigating them.
About the Writer
Musa is a certified Cybersecurity Analyst and Technical writer. He has experience working as a Security Operations Center (SOC) Analyst and Cyber Threat Intelligence Analyst (CTI) with a history of writing relevant cybersecurity content for organizations and spreading best security practices. He is a regular writer at Bora.
His other interests are Aviation, History, DevOps with Web3 and DevSecOps. In his free time, he enjoys burying himself in a book, watching anime, aviation documentaries and sports, and playing video games.
Disclaimer: The author is completely responsible for the content of this article. The opinions expressed are their own and do not represent IEEE’s position nor that of the Computer Society nor its Leadership.