Why are valid traffic and valid SQL queries triggering SQL Injection threat IDs? What is the workaround?

A SQL query or a valid web traffic is marked as SQL injection vulnerability. In that situation, one of the 'HTTP SQL Injection Attempt' signatures may trigger for traffic containing SQL statements in HTTP that look otherwise harmless.

• What is SQL injection:

The SQL injection is a web security vulnerability where crafted SQL quires allow an attacker to view data, edit it, and in extreme cases denied access to data. In other words, an attacker can manipulate the SQL query in a way that it ends up in privacy, unauthorized access to sensitive information and modification rights, and DoS.

• What are the common keywords:

In attempts at SQL injection, one of the most frequently employed payloads is the 'SELECT * FROM sensitive_table' statement. This payload is used to ascertain the existence of a particular table within the database. For example, an attacker might transmit the query 'SELECT * FROM admin' and analyze the response to verify the presence of the 'admin' table. If successful, the attacker can then progress to subsequent steps, such as dispatching 'SELECT username, password FROM admin' to retrieve the administrator's credentials.

SQL statements being transmitted over HTTP are not typically anticipated in well-developed web applications. Generally, HTTP requests are directed towards the web server itself, rather than containing direct SQL statements. The web server then interacts with the backend database using SQL on behalf of the application.

The primary objective of utilizing signatures is to identify instances in which malicious actors might attempt to exploit vulnerabilities by sending meticulously crafted queries through HTTP forms. This serves as a safeguard against unauthorized or unexpected queries originating from the web application towards its backend database. Given the myriad ways in which SQL queries can be constructed, our signatures aim to encompass the usual SQL commands that attackers employ to probe and uncover SQL Injection vulnerabilities.

It is important to emphasize that executing SQL statements transmitted via HTTP requests can present significant hazards, particularly if the backend interface not only permits the extraction of sensitive data from the database but also allows for reading/writing server files (including establishing backdoors) and executing system commands. As a result, it is relatively uncommon for systems to feature interfaces that enable the execution of SQL statements through HTTP requests. This rarity underscores the reason we regard triggers originating from SQL statements in the HTTP parameters as genuine attacks.
 

Simply disabling the signature outright would expose all customers to potential risks. To address this, we recommend implementing a specific threat exception. By instituting such an exception, we can maintain essential security measures while enabling their specific case to function without triggering false positives.

• If you are sure that your SQL query is benign you can add an exception for the signature. 
• If necessary, you can add an exception just for one website to narrow down the attack surface. Please follow the steps listed below. 
  1. Create a new vulnerability profile and add the exception for the threat ID. 
  2. Create a custom URL category for your website.
  3. Create a new policy, (a) Add your website category under "Service/URL Category" tab (b) Add the new vulnerability profile under the "Actions" tab.
  4. Make sure your new policy is before the original one.
  5. Now the exception will only be applied to one website.

You can find the vulnerability signatures that detects SQL injection on Threat Vault.