SQL Injection

SQL injection attacks are a type of injection, in which malicious SQL commands are injected into otherwise benign and trusted websites.

Overview

SQL injection attacks occur when an attacker uses SQL code (queries) in order to manipulate the back-end database to display or return information that was never intended to be returned to users.

To accomplish this, the attacker looks for a web application that does not sanitize its form inputs properly and filter out SQL commands.  This way an attacker can send the backend SQL commands and force the site to do a number of things.  For example the attacker can get the database to display a list of all of the credit card or social security numbers in the system.  An attacker can then edit the information in the database, or even delete parts or the entire database.  Most often this can be done by typing in SQL code into a webform on an insecure page and clicking the Submit button.

Rule Options

Log Attack Attempts

Selecting one or both checkboxes will protect against or detect, and log any attempted SQL injection attacks. At least one must be selected:

• Successful - The rule will trigger upon detecting a valid SQL Injection that would have resulted in exploiting the underlying database.
• Failed - The rule will trigger upon detecting an invalid SQL Injection that could return an error informing an attacker of the database structure.

Database Provider

When the Successful checkbox is selected, you can select the provider that matches the backend database that you wish to protect.  Different selections have different options:

• Any, DB2, Postgres, and Oracle all have no additional options
• Sybase and MsSql both allow the optional selection of quoted-identifiers
• MySql and MariaDB allows for the options of quoted-identifiers and no-backslash-escapes

If you do not know your provider or have multiple providers it is best to choose the default option: Any.

Do Not Trust Requests From

When the Successful checkbox is selected, you can choose the sources that the strict policy option will treat as untrusted.

• HTTP - Data received by the application from HTTP requests (e.g. from a web browser).
• Database - Data received by the application from a database.
• Deserialization - Data received by the application via deserialization APIs (e.g. RMI, JMX, java.io.ObjectInputStream, etc.)

You may select one or many of these, but at least one selection is required. The default value is HTTP.

Safe Requests From Untrusted Sources

When the Successful checkbox is selected, you will have the option to allow SQL requests from an untrusted source, which means that the rule will not trigger in the case where the entire SQL query (and not just part of it) has come from any of sources selected in the Do Not Trust Requests From panel.

Action

• Detect - The Agent will detect the attack, it will log the event to the event database, and the event will be viewable on the Security Events pages in the Portal, but the Agent will take no further action
• Protect - In addition to the Detect actions, the Waratek Agent will also actively prevent the attack from succeeding.

If Protect is selected, you will have the option to select the Protect Override option. When this toggle is turned on, an attacker will receive a HTTP 400 error. If the toggle is turned off (the default position), then the attacker will be disconnected.

The Protect Override option is only supported on ARMR 2.4 or higher

Log Messaging

The logs provide a message field, which can be customized. Text entered here is the message that will be seen on the log file’s when the rule has been triggered, regardless of the Action. If the field is left blank, then the default logging message will be displayed in the message portion of the event log.

Severity

The log files allow you to select a custom severity level for the event: Low, Medium, High or Critical.  A severity is required, and there is no default selection.

Advanced Options

Disable Logging - By checking this option, disable logging will be performed when a rule is triggered. Subsequently the Portal will not see these events, and they will not appear anywhere in the Portal, nor will they be searchable in Event Storage

This option will be greyed out if the rule action is set to Detect.

Enable Stack Trace - By checking this option, when a rule is triggered, the stack trace will be included in the event log, and will be available for viewing in the Portal UI for each triggering security event.

Resources

More information on SQL Injection can be found at:

• the CWE’s community-developed website
• the OWASP Foundation’s website