APIs can be used to facilitate cyber attacks because APIs are widely used to convert sensitive information. Vulnerabilities such as weak authentication, lack of encryption, logical flaws, and insecure endpoints make the API vulnerable to attacks.
Some of the major attacks that usually occur due to a lack of security during the implementation of APIs are:
Man in the middle (MITM)
In order to obtain sensitive information, an intruder intercepts traffic between communicating parties by forwarding and intercepting communications involving API exchanges.
API injections (XSS and SQLi)
In a snooping attack, malware is added to vulnerable software to host an attack, such as cross-site scripting (XSS) and SQL injection (SQLi).
An author can inject a malicious script into a vulnerable API, that is, one that is unable to perform proper filter input and exit (FIEO) to launch an XSS attack on end-user browsers. In addition, malicious code is added to the API message, for example, commands that delete objects, records from the database.
Distributed Denial of Service (DDoS)
In a distributed denial of service (DDoS) attack, multiple systems are flooded with the bandwidth of a targeted system, usually web servers. A DDoS attack against an API attempts to overload its memory and capacity by filling it with simultaneous connections or sending / requesting large amounts of information to each request. The DDoS attack on the FCC website in early 2017 used commercial cloud services to provide a huge number of API requests to the commenting system. This consumed the available machine resources and supplanted the commentators, which eventually caused the website to crash.
DNS capture
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 are on the Internet and the website you want to access redirects you to a malicious site full of unwanted pop-ups and advertisements. The primary motive is to generate income.
DNS capture can also be used for phishing. In phishing, victims are targeted and attackers try to trick them into revealing sensitive information, such as their payment information. The most common way we see phishing is to send an email as bait that directs users to a website that appears to be a legitimate payment processing site and steals their information from there.
How can we secure our Quick Heal API
HTTPS over HTTP
TLS (Transport Layer Security) is a standard that keeps your Internet connection private and verifies that data sent between two systems is encrypted and unmodified. A site is said to be TLS-protected if the URL starts with “HTTPS” (Hyper Text Transfer Protocol Secure).
TLS in API-based interaction is essential. Transport layer encryption is one of the must-protect APIs. In the absence of TLS, the risk of Man-In-The-Middle attacks is still very high. We use both TLSs in our APIs, especially when published with APIs. We definitely use HTTPS over HTTP.
Authentication
To determine the identity of the end user (caller) in the API, basic authentication can be implemented using the TLS protocol. However, OAuth 2 and OpenID Connect are more secure options.
Never reveal information about URLs
Never reveal sensitive or vulnerable information in URLs
Confirmation of input parameters
Confirm the request parameters in the first step before it reaches the actual service processing business logic. We will put strong revisions and reject the request immediately if the verification fails.
Encryption
The use of strong encryption for sensitive and private data while converting through APIs is highly recommended. We use a strong and light encryption algorithm – AES256
AES256
The Advanced Encryption Standard (AES) is the first and only publicly available encryption approved by the U.S. National Security Agency (NSA) to protect classified information.
To date, very few attacks have been reported against 256 AES applications. Most of them were side channel attacks (the attack was done to execute the secret code in the system and not in the cryptography itself). It is believed that the design and strength of the key length protects the AES algorithm and the 256-bit key length is ideal for top secret information. No one wants to compromise on security, and AES-256 is one of the most secure encryption methods on the market today.
Key exchange algorithms
Use strong key exchange algorithms to exchange authentication or encryption keys. This should be accepted due to hard coded or static secrecy.
In secret key exchange, we use the strongest public key exchange method called Diffie Hellman Secured key-exchange.
Diffie Hellman Secure Key Exchange:
The Diffie-Hellman key exchange is complicated. It uses very large numbers and a lot of math. The Diffie-Hellman key exchange is based on one-way functions as the basis for security. These calculations are simple and one-way, but very difficult to calculate in the opposite way.
Some of Diffie-Hellman’s benefits:
- The sender and recipient do not need to know each other in advance
- Once the keys have been exchanged, data transfer can be performed securely over an unsecured channel
- Sharing a secret key is secure
Identity based authentication
The advantage of token-based authentication is that it eliminates the possibility of weak credentials. ID is a highly protected information, which is used to transmit sensitive data between the two sides in a compact and independent manner. Logins are often used to validate authentication processes, whether it is a website or an application.
We use JWT Token-based communication, which consists of:
- A header that specifies the type of ID and algorithm used
- A payload that contains user information and other metadata
- Signature to verify the identity of the sender and the authenticity of the message
URLs
URLs do not reveal any sensitive information because we avoid using query parameters and do not reveal any information through URLs.
Confirmation of input parameters
We have a strong validation of the input parameters at an early stage before implementing the business logic, and we reject any possible erroneous requests.
Safety vs. performance
Performance is a feature and safety is essential nowadays, so it is very important to achieve both without compromising on each other. To meet these safety requirements, a light implementation strategy can be chosen with high safety measures.
Author: Prafulla Prakash Ranadive
