Securing APIs from Injection Attacks: Mitigating OWASP API Security Risks

Have you heard about the 500 million account breach of Yahoo that happened in 2012? Although it's almost a decade old news, it is considered one of the largest breaches in history. Through an SQL injection attack on Yahoo, approximately 450,000 usernames and passwords were compromised.

An injection attack is an older yet significant threat that continues to pose a risk to web applications. This attack poses a threat to the organization as well as the users as the information gained by the attackers can be misused in many ways, increasing the need for robust API security.

What is Injection Attack?

API injection attacks occur when an attacker attempts to introduce malicious input or data. This input could be a command or a database query. The server processes the request, and if successful, it can affect the program's execution and potentially lead to data manipulation.

This kind of attack frequently happens as a result of inadequate input validation. When developers or app creators fail to implement proper input validation or handle queries inappropriately, it creates an open surface for attackers. As a result, malicious scripts or data introduced by an attacker may be executed if the input is not validated or sanitized.

Improper special character handling can also exploit API security. This will cause unauthorized access to the server, data manipulation, server crashes, and other similar issues. It can affect the overall business, so most websites consider this as a primary attack and adopt various preventive methods to safeguard against it.

There are various types of API injection attacks, and each one has a different attack strategy and method of execution. Let's discuss a few major injection attacks for better understanding.

What are the common Injection attacks?

According to the severity of the attack and occurrence, here are a few major API injection attacks as follows :

• SQL injection:
  • Occurrence: Very Common
  • Severity: High
  • Description: SQL (Structured Query Language) is frequently used by web applications to do query operations. However, failure to implement adequate input validation creates a vulnerability for upcoming API injection attacks. Malicious scripts can be provided using web page forms, resulting in the execution of unauthorized queries in the backend. As a result of such attacks, the database may be destroyed, unauthorized users may gain access, there may be a denial of service, data may be stolen, or all of these things may happen.
  • Example: We declared one variable named ' client '. The variable receives the name of a customer through the input form and then it executes a deletion query 'DELETE FROM Client WHERE Name =?'. This query deletes the customer from the record. Suppose the attacker changes the end part to ' FROM Client WHERE Name='client or 1=1' then it potentially removes the whole database of clients rather than a single client record as the attacker passes "random or 1=1".
• Command Injection :
  • Occurrence: Moderate
  • Severity: High
  • Description: SQL injection uses SQL queries to employ injection attacks similarly. In code injection, the code snippet is passed through the input field. If the backend executes the input field as a command or code then the system gets compromised due to malicious code.
  • Example: Let's understand this with one example. Suppose you have a PHP script called readfile.php with the following code: $file = $_GET['file']; $data = file_get_contents($file); echo $data; This script uses the file_get_contents() function to read the contents of a file after receiving the file name from the user using the $_GET['file'] variable. After that, the user's browser receives an echo of the file's content. Attackers might use this code to read arbitrary files from the server's filesystem. If the user passes the http:/demo.example.com/readfile.php?file=/etc/passwd code. In this case, the attacker has manipulated the file parameter to read the contents of the /etc/passwd file, which is a sensitive system file containing user account information.
• Cross-Site Scripting :
  • Occurrence: Very Common
  • Severity: Medium to High
  • Description: When the user visits any website, the website content is loaded in the browser. If a user visits any malicious website accidentally then it will run a malicious script on the victim's browser. Attacks of this type are known as XSS attacks (cross-site scripting attacks). This helps him to gain access to session storage, local storage, cookies, and any other sensitive information stored on the victim's browser without being known to the victim. The attack can be permanent or temporary. It can cause session hijacking, the attacker can steal cookies and sensitive information which can put API security at risk and help an attacker to give unauthorized access or cause permanent damage to any business.
  • Example: If a user visits a website called http://free.promocode.com/user, believing it to be a legitimate site offering free promotional codes. But this is a malicious website. The user doesn't see anything but in the background, the attacker runs a script like Object.entries(localStorage) and stores it as one variable or saves it on the attacker's database. As a result, the attacker now has access to all of the private data kept in the user's local storage, including session tokens and other information. With the help of the stolen data, the attacker may be able to take over the user's current sessions on other websites, perhaps gaining access to their accounts or doing other serious damage to the user's professional or personal life.
• CSRF (Cross-site request Forgery):
  • Occurrence: Moderate
  • Severity: Medium
  • Description: Authenticated users are tricked by CSRF attacks into taking activities on a web application without their knowledge. This is accomplished by inserting malicious browser requests that are subsequently forwarded to the target application.
  • Example: The victim (user) is already authenticated and has an active session with your organization's website, which grants them admin access. The attacker tricks the victim into visiting their malicious website (http://attacker.com) while they are still signed into the organization's website. Scripts or malicious requests on the attacker's website try to retrieve the session cookie from the victim's browser. The attacker can submit fake requests to your company's API on behalf of the victim once they have the user's session cookie.
  Since the attacker's requests carry the stolen session cookie, the organization's API will interpret them as legitimate actions initiated by the authenticated user (victim). With the stolen session, the attacker can gain unauthorized access to sensitive information, perform actions as an administrator, or carry out any other malicious activities within your organization's account.

Other API injection attacks include LDAP injection, Remote Code Execution (RCE), XML External Entity (XXE), and so on. These attacks can lead to significant disruption for organizations and pose personal threats. Therefore, it is crucial to implement preventive measures to mitigate these risks.

How can an API gateway prevent injection attacks?

Injection attacks are just one of the many sorts of attacks that the API gateway helps to stop. Between the client-side application and the backend server, it serves as a protective shield. The following strategies can be used with API gateways to stop injection attacks:

• Input Sanitization: Sanitization of input is important to protect against other security vulnerabilities and code injection attacks. Sanitization refers to cleaning or filtering the user inputs or data. The basic objective of sanitization is to remove harmful and malicious content from the input data. This is especially important when working with data from sources that are unreliable or user-generated content. Sanitization ensures that the input data that is processed and stored in the application is secure and reliable. Escaping special characters, deleting HTML tags, and converting input to a secure format, like changing user input to plain text to prevent script injection, are all examples of common sanitization methods.
• Input Validation: Input validation refers to the process of checking input against specific rules determined by the application. Validation is used to maintain the integrity and consistency of data used by the application. It ensures that the coming input is meaningful, correct, and according to the format. Instead of cleaning or filtering the input, validation's primary goal is to ensure that input data follows the required format and is ready for processing. For example, when a user submits a form, the validation process checks whether the input is of the correct type (email, text, number, etc.), ensuring it adheres to the expected format for further processing.
• Authentication and Authorization: The API gateway can provide various authentication and authorization methods. These methods ensure that only authorized or validated users can access the content which minimizes the possibility of an attacker accessing the resources. One more preventive measure is the CSRF (Cross-Site Request Forgery) token. CSRF token is a unique, secret, and random value generated by the server and given to the client application. This token is sent through the client application.
• Implement Rate Limit: Rate limit allows only limited requests in a particular time frame. So, if the attackers plan to disrupt the backend server with innumerable requests, rate limiting can help in stopping them. It blocks incoming malicious requests and prevents DDoS attacks from overwhelming the backend services.
• IP blocking: By monitoring traffic coming from particular IP addresses, we can determine the validity of users and block the IP addresses of malicious users. Users can also set whitelisted IPs and blacklisted IPs. At the server end, only whitelisted IP requests are sent for processing, while blacklisted or malicious user IPs are blocked.
• API schema validation: In the API gateway, you can enforce API schema for input request validation. So every time any request is made, the API gateway checks for the corresponding API Schema and validates the API request. When the schema doesn't match it generates an error message and attacker malicious requests can be blocked.
• Request and Response Validation: API gateway also provides a middleware to interact with request and response payload. Users can determine request body and response body schema or data models which helps to validate incoming and outgoing payload. Additionally, the API gateway can provide response modifiers which ensures that only the required response is sent to the user instead of complete data which may include sensitive information.
• HTTP Security Headers: API Gateway allows you to add additional security headers in response such as Content Security Policy (CSP), Strict-Transport-Security (HSTS), X-XSS-Protection, and X-Content-Type-Options. These headers help to protect from XSS attacks.
• Logging and Monitoring: Logging and Monitoring are basic features of the API gateway. Logging and Monitoring help to determine the data patterns using traffic monitoring. By observing these data patterns users can determine the abnormal activities of data traffic and take preventive actions accordingly. As mentioned in the beginning, injection attacks have been risking API security for years now. It is crucial to protect APIs from notorious attackers. Contact the team at XecureAPI Gateway for robust API security solutions.