SQL Injection

SQL injection is a method of attacking data-driven applications wherein an attacker includes portions of SQL statements in an entry field. The newly-formed rogue SQL command is passed by the website to your database where it is executed. The command can result in the attacker being able to read, add, delete, or change information in the database. Application Security protects against SQL injections by blocking common SQL injection techniques.

Configure the SQL Injection policy

  1. Go to Your Group > Policies > SQL Injection and ensure that it is enabled.
  2. Set the state to Report. This will trigger events without blocking the request, which allows you to run your application and see which expected behaviors trigger SQL injection events.
  3. On the right of the page, select Configure Policy.
  4. The following settings need to be switched on to protect against SQL injection:
    • Always False: Detects SQL where clause conditions that are always false, such as AND 1=0.
    • Always True: Detects SQL where clause conditions that are always true, such as OR 1=1.
    • Bad Function: Detects SQL functions that are commonly abused as part of SQL injection attacks, such as sleep() or load_file().
    • HTTP Params: Detects HTTP GET or POST parameters that are copied verbatim into an SQL statement, and are not safely contained in a string or a number.
    • Stacking Queries: Detects attempts to stack more than one SQL query in a single RDBMS call.
    • Syntax Error: Detects SQL syntax errors.
    • Trailing Comment: Detects the injection of comments at the end of SQL statements.
    • Unions Set: Detects SQL SELECT statement UNIONs, which are frequently abused in SQL injection attacks. SQL Injection policy
  5. Select Save Changes and close the window.

    By default, only the HTTP Params algorithm is enabled. The other algorithms can be enabled as needed. Note that the algorithms analyse the SQL statement for anomalies. When analysing the SQL statement, the dialect for the specific database is used. If the the dialect database is unknown, the default dialect is used. The default dialect is postgres. When the dialect is unknown and thus the default dialect is used, certain algorithms like Bad Function and Syntax Error might generate false positives. The dialects currently supported are: db2, mssql, mysql, oracle, postgres, sybase.

  6. Navigate to your application and use it in the various scenarios that it was designed to handle.

  7. On the Application Security dashboard, check the Events page for SQL Injection events. If one has been triggered, follow the steps in Manage SQL Injection events.
  8. Once you're happy with your policy configuration and events are no longer being triggered by expected behavior, go to Your Group > Policies > SQL injection.
  9. On the right of SQL Injection, set the state to Mitigate. When a rule is triggered, the attempt will be blocked and a SQL Injection event will appear on the Dashboard.

SQL Injection events

SQL Injection events are displayed on the Dashboard in Events or Filter by Group > Your Group.

Every event includes the Request Details panel for general information about the event. For more information, see Manage Events.

Under SQL Injection Details the following information is displayed:

  • Trigger: The rule that triggered the SQL Injection event.
  • Dialect: The SQL dialect that you are using
  • Supported: Whether or not that SQL dialect is supported. Unsupported dialects may have reduced quality of SQL syntax and statement vetting.
  • SQL Statement: The SQL statement that triggered the event.

Screenshot

Under Triggered Policy Details is more information about the policy rule that was triggered and the properties of that rule. Screenshot

Manage SQL Injection events

If Application Security is reporting SQL Injection events:

  • In the top right corner of the event details panel, select View Stack to see where in your code the attack was leveraged. Modify your code so a SQL Injection attack can't be leveraged in the future.
  • If the event was triggered by an expected behavior of your application and you'd prefer not to modify your code and allow the behavior, select Click to Manage Policy. In the Alert section, you can see what policy rule was triggered. If you'd like to allow this behavior on your application, turn the rule OFF.

For example, if a Stacking Queries event was triggered because that is how the application built its SQL query, either modify your application's code based on the payload details, or go to Click to Manage Policy and select Disable Stacking_Queries. Screenshot