An Application Programming Interface (API) is a way that allows applications to communicate with one another. It provides a way for developers to build software applications while enabling the extraction and sharing of data in an accessible manner.
APIs can be used to facilitate cyberattacks as APIs are widely used for transforming information that might be sensitive. Vulnerabilities like weak authentication, lack of encryption, logical flaws, and insecure endpoints make APIs vulnerable to attacks.
Some of the major attacks that usually happen due to lack of security measures while implementing APIs are:
In order to obtain sensitive information, an intruder intercepts the traffic between communicating parties by relaying and intercepting the communication that includes API exchanges.
API injections (XSS and SQLi)
In a code injection attack, malicious code is inserted into a vulnerable software program to stage an attack such as cross-site scripting (XSS) and SQL injection (SQLi).
A perpetrator can inject a malicious script into a vulnerable API, i.e., one that fails to perform proper filter input and escape output (FIEO) to launch an XSS attack targeting end-users’ browsers. In addition, malicious code is inserted into an API message, e.g., commands that delete objects, records from a database.
Distributed denial of service (DDoS)
In a distributed denial-of-service (DDoS) attack, multiple systems flood the bandwidth of a targeted system, usually web servers. A DDoS attack on an API attempts to overwhelm its memory and capacity by flooding it with concurrent connections, or by sending/requesting large amounts of information in each request. A DDoS attack on the FCC website in early 2017 used commercial cloud services to issue a massive amount of API requests to a commenting system. This consumed available machine resources and crowded out human commenters, eventually causing the website to crash.
Domain Name Server (DNS) hijacking also known as DNS redirection is a type of attack in which DNS queries are unexpectedly redirected to malicious sites.
One example of DNS Hijacking is when you’re on the Internet and a website you want to access redirects you to a malicious one filled with unwanted pop-ups and ads. The primary motive behind this is generating revenue.
DNS hijacking can also be used for phishing. In phishing, victims are targeted and attackers attempt to trick them into revealing sensitive information like their payment credentials. The most common scenario we see in phishing is sending an email as a bait directing users to a website that appears to be a legitimate payment processing website and from there steal their information.
How are we at Quick Heal securing our APIs
HTTPS over HTTP
The Transport Layer Security (TLS) is a standard that keeps an Internet connection private and checks that the data sent between two systems is encrypted and unmodified. A website is said to be protected with TLS if the URL begins with “HTTPS” (Hyper Text Transfer Protocol Secure).
TLS in an API based interaction is essential. Transport layer encryption is one of the ‘must-to-have’ to secure APIs. If there is no TLS, the risk of the ‘Man-In-The-Middle’ attacks remains very high. We use both TLS in our APIs, especially when going public with APIs. We strictly use HTTPS over HTTP.
To determine the identity of an end-user (caller) in an API, basic authentication can be implemented using the TLS protocol. However, OAuth 2 and OpenID Connect are more secure alternatives.
Never expose information on URLs
Never expose any sensitive or vulnerable information in the URLs
Input Parameter Validation
Validate request parameters on the very first step, before it reaches to actual service processing business logic. We put strong validation checks and reject the request immediately if validation fails.
The use of strong encryption for sensitive and private information while transforming over APIs is highly recommended. We use strong and lightweight encryption algorithm – AES256
The Advanced Encryption Standard (AES) is the first and only publicly accessible cipher approved by the US National Security Agency (NSA) for protecting top-secret information.
To date, there are very few attacks reported against 256 AES implementation. Most of them were side-channel attacks (the attack was done on the implementation of the cipher on the system and not on the underlying cipher itself). It is believed that the design and strength of the key length protect the AES algorithm and a 256-bit key length is ideal for top-secret information. When it comes to data security no one wants to compromise, and AES-256 is one of the most secure methods of data encryption available in the market today.
Key Exchange Algorithms
Use Strong Key Exchange Algorithms to exchange the Authentication or Encryption keys. This should be adopted over hardcoded or static secret.
For secret key exchange, we use the strongest Public Key Exchange method which is called Diffie Hellman Secured key-exchange.
Diffie Hellman Secured key-exchange:
The Diffie-Hellman key exchange is complex. It uses very large numbers and a lot of math. The Diffie-Hellman key exchange relies on one-way functions as the basis for its security. These calculations are simple and one-way, but very difficult to calculate in a reverse manner.
Some advantages of Diffie-Hellman:
- The sender and receiver do not need any prior knowledge of each other
- Once the keys are exchanged the communication of data can be done through an insecure channel securely
- The sharing of the secret key is safe
The advantage of token-based authentication is that it removes the chances of weak login credentials. A token is a highly-secured piece of data used to transmit sensitive information between two parties in a compact and self-contained manner. Tokens are often used to strengthen authentication processes, be it within a website or application.
We use JWT Token based communication that consists of:
- A header that defines the type of token and algorithm used
- A payload that contains information about the user and other metadata
- A signature that verifies the identity of the sender and the authenticity of the message
URLs do not expose any sensitive information as we avoid using query parameters and no information is exposed via URLs.
Input Parameter Validation
We have strong input parameter validation at the very initial stage before business logic gets executed and we reject all the potential invalid requests.
Security Vs Performance
Performance is a feature and security is an essence nowadays, so it is very important to achieve both without compromising the other. To cater to these security requirements without compromising performance one can choose a lightweight implementation strategy with high-security measures.
Co-authored by Prafulla Prakash Ranadive