ARMR SQL Rule

Overview

A SQL injection (SQLi) attack consists of the insertion or “injection” of a SQL query via the input data from the client to the application. The ARMR sql rule can be used to enable protection against SQL injection attacks.

SQL Injection vulnerabilities are covered by CWE-89.

Given (Conditions)

The user can specify two conditions in the ARMR sql rule - input and vendor.

input	This allows the user to specify the source of the untrusted data. The following three sources are supported:- http data introduced via HTTP/HTTPS requests

• database data introduced via JDBC connections

• deserialization data introduced via Java or XML deserializationThe rule will trigger if the source of the untrusted data matches that specified in the rule.If no value is specified then a default value of http is used.An exception will be thrown if an unsupported value is provided. | | | vendor | This is an optional declaration that allows the user to specify the database type to be protected. The following databases are supported:- db2

• mariadb

• mssql

• mysql

• oracle

• sybase

• postgresIn addition, a value of any may be specified which will enable the agent to automatically detect the database type used by the application.One of the listed database types, or the value any, must be specified if the vendor declaration is present.If no vendor declaration is specified then a default value of any is used. | | | | options | Depending on the database configuration, the following optional parameters are also supported to allow the agent to accurately detect SQL injection attacks:- ansi-quotes - mysql and mariadb: corresponds to the ANSI_QUOTES server mode.

• no-backslash-escapes - mysql and mariadb: corresponds to the NO_BACKSLASH_ESCAPES server mode.

• quoted-identifiers - mssql and sybase: corresponds to the QUOTED_IDENTIFIER flag |

When (Event)

injection	This condition allows the user to specify the type of injection:- successful-attempt the rule will trigger upon detecting a valid SQLi payload that would have resulted in a successful SQLi attack, exploiting the underlying database.

• failed-attempt the rule will trigger upon detecting an invalid SQLi payload that would have resulted in an unsuccessful SQLi attack, which could expose the underlying database configuration or vendor.If no value is specified then a default value of successful-attempt is used.In addition, the user may optionally specify the following parameter:- permit: query-provided the rule will not trigger in the case where the entire SQL query (and not just part of it) has come from any of the untrusted sources defined in the input declaration.An exception will be thrown if an unsupported value is provided. |

Multiple sql rules are allowed in the same ARMR mod providing they have different injection types.

Then (Action)

The action statement specifies the default action the agent takes whenever an attack is detected. There are two supported actions protect and detect:

	successful-attempt	failed-attempt
protect	A valid SQL injection attack is not allowed to be processed by the database. A SQLException is thrown by the agent to indicate the SQL statement is invalid, letting the server handle the exception gracefully. If configured, a log message is generated with details of the event.	An invalid SQL statement is not allowed to return any sensitive information about the database. The HTTP connection, from which the malicious data that exploited the SQL statement originated, is disconnected. If configured, a log message is generated with details of the event.
detect	Monitoring mode: the application behaves as normal. A valid SQL injection attack is allowed to be processed by the database. If configured, a log message is generated detailing that the agent has detected an attempt to exploit the database using a valid SQL statement.	Monitoring mode: the application behaves as normal. An invalid SQL statement is allowed to be processed by the database. If configured, a log message is generated detailing that the agent has detected an attempt to exploit the database using an invalid SQL statement.

Payload whitelisting can be applied using the Waratek command-line option com.waratek.AllowSQLiPayloads. The value supplied should be a comma-separated list of strings to substring-match against SQLi payloads to be whitelisted and therefore not register as an SQL injection attack. Example: com.waratek.AllowSQLiPayloads=AND,OR

Example

The following sql rule is used to protect a MySQL database from SQL injection attacks.

The input and injection conditions are satisfied when the untrusted data originates from an HTTP/HTTPS request, and the resulting SQL statement is either a valid query that will exploit the database, or an invalid query that may disclose information about the database configuration or vendor.

An action of protect is defined to ensure that the agent does not allow any malicious SQL statement to be processed by the database. A log message and severity are both specified which will be included in any generated log entries if an attack is detected.

app("SQL mod"):
  requires(version: ARMR/2.2)
  sql("Protect MySql database from SQL Injection attacks"):
    vendor(mysql)
    input(http)
    injection(successful-attempt, failed-attempt)
    protect(message: "SQL injection attack detected and blocked", severity: High)
  endsql
endapp

Logging

When the sql rule is triggered a log entry similar to the following is generated:

<13> 1 2020-06-05T17:00:13.944+01:00 l-qa02 java 596 - - CEF:0|ARMR:SQL mod|SQL mod|2.2|Protect MySql database from SQL Injection attacks|Execute Rule|High|rt=Jun 05 2020 17:00:13.943 +0100 dvchost=l-qa02 procid=596 outcome=success act=protect msg=SQL injection attack detected and blocked metadata="HeaderInfo":{"remoteAddr":"0:0:0:0:0:0:0:1","requestURI":"/spiracle/Get_int","sessionId":"CFB28F28C687620D3D0B3585229FC38B","cookieNames":{"JSESSIONID":"CFB28F28C687620D3D0B3585229FC38B","CUSTOMER_UUID":"05b7b9d7-2046-4014-b8c9-bc53c79790c5"}},"databaseVendor":"mysql"

Further Examples

The following mod enables the agent to automatically detect the database type in use by the application. The mod protects against valid SQL injection attacks that originate from an HTTP/HTTPS request.

app("SQL mod 2"):
  requires(version: ARMR/2.2)
  sql("Protect database from successful SQL Injection attacks"):
    vendor(any)
    input(http)
    injection(successful-attempt)
    protect(message: "SQL injection attack detected and blocked", severity: Very-High)
  endsql
endapp

The following mod monitors a MSSQL database, detecting valid SQL injection attacks that originate from a JDBC connection.

app("SQL mod 3"):
  requires(version: ARMR/2.2)
  sql("Protect MSSQL database from successful stored SQL Injection attacks"):
    vendor(mssql)
    input(database)
    injection(successful-attempt)
    detect(message: "SQL injection attack detected", severity: 5)
  endsql
endapp

The following mod protects an Oracle database against valid SQL injection attacks that originate from an HTTP /HTTPS request. If the entire SQL query has originated from an HTTP/HTTPS request then the mod will let it through to the database.

app("SQL mod 4"):
  requires(version: ARMR/2.2)
  sql("Protect Oracle database from successful SQL Injection attacks"):
    vendor(oracle)
    input(http)
    injection(successful-attempt, permit: query-provided)
    protect(message: "SQL injection attack detected and blocked", severity: 8)
  endsql
endapp

The following mod does not specify the vendor declaration, enabling, by default, the agent to automatically detect the database type in use by the application. The mod protects against invalid attempts at SQL injection that originate from various untrusted sources. Logging is switched off by the omission of the log message parameter.

app("SQL mod 5"):
  requires(version: ARMR/2.2)
  sql("Protect database from unsuccessful SQL Injection attacks from various sources"):
    input(http, database, deserialization)
    injection(failed-attempt)
    protect()
  endsql
endapp