November 30, 2020

WAF Rules for SQLi

Use a Web Application Firewall (WAF) to defend against SQLi.  Configure the WAF to inspect SQL queries and block SQLi attempts.  A common tactic to evade the WAF pattern matching is to encode the parts of the query.  So prior to performing the pattern match, values are first URL-decoded in order to avoid WAF evasion techniques of various sorts.

  • Create a rule to look for multiple instances of keywords related to SELECT statements.  Detect the existence of these keywords using the phrase match (Aho-Corasik algorithm). If at least one keyword exists in the input, the rule starts counting the number of different keywords that appeared in the input. If at least 3 (or more) keywords appeared, the rule will block the request.
    • select
    • show
    • top
    • distinct
    • from
    • dual
    • where
    • group by
    • order by
    • having
    • limit
    • offset
    • union
    • union all
    • rownum as
    • (case
    • join
    • into
  • Create a rule that will trigger on attempts to perform SQL Injection through the usage of SQL comment sequences, which are commonly used in many SQL Injection attack payloads. The sequences are:
    • C-style comments (/* , /*! , and */)
    • String termination characters such as apostrpohe ('), semicolon (;) and closing parenthesis, or a numeric value followed by two dashes(--)
    • MySQL style comment (#)
    • Semicolon (with and without a following null byte ‘\x00‘)
  • In order to perform SQL Injection attacks, a common tactic is often the use of SQL operators, mainly in the context of Blind SQL attacks.  Create a rule that looks SQL operators like:
    • !=
    • &&
    • ||
    • <<
    • >>
    • <=
    • >=
    • <>
    • <=>
    • xor
    • rlike
    • regexp
    • isnull
    • not between 0 and
    • is null
    • like null
    • in (..)
    • rlike
    • rlike binary
    • regexp
    • regexp binary
  • In order to perform SQL Injection attacks, a common tactic is the use SQL operators and SQL expressions, mainly in the context of Blind SQL attacks. Create a rule that looks for certain common SQL expressions and phrases, such as:
    • Equations (e.g 1=1),
    • Math expressions (e.g. 3<4 or 1!=0) and
    • String expressions (e.g. 'Blackhawks' is not 'RedWings').
  • Common forms of Blind SQL Injection attacks manipulate boolean expressions inside SQL statements in order to undermine application logic. This can be done by using the ‘OR‘ operator.  Create a rule that looks for certain SQL expressions that use the ‘OR’ operator, for example:
    • OR 1<
    • OR 'string'=
    • ' OR 'string' <
    • ' XOR 'string' >
    • OR 'string'
    • XOR 1=.
  • Create a rule that will block HTTP requests which contain 4 or more hazardous characters (i.e. ~!@#$%^&*()-+={}[]|:;"'`<>).   CAVEAT, This type of rule may yield false positives on some cookie values, especially when cookie values are complex and contain multiple elements within a single cookie. For example JSON objects, XML payloads and any proprietary format which uses certain non-word delimiters.  If you aren’t using JSON, cookies, XML, etc. then you might be ok with a rule like this.
  • A Common tactic of SQL Injection attacks manipulate conditions inside SQL statements such as those in the ‘WHERE’ clause of the query. This is done in order to undermine application logic.  This rule looks for certain common SQL injection payloads, which attempt to manipulate query logic. For example:
    • ' like '
    • 1' '1
    • admin'
    • ' or '
    • ''='
    • ' or < 1
    • where col=.
  • As part of most SQL Injection attacks, a common tactic is often attempt to inject known built-in SQL functions, objects and keywords. Create a rule that will trigger on HTTP requests, which contain such keywords and relevant phrases such as:
    • @a = (select...
    • 5 and 5-
    • /a; having
    • 5 group by (
    • ; drop
    • ; update...
    • SET @
    • like (abc) = '.

[981256] score + 5
As part of most SQL Injection attacks, hackers often attempt to inject SQL keywords. This rule will trigger on HTTP requests, which contain such keywords. For example: ‘merge…using(‘, ‘execute immediate…”’, ‘ having xyz…’

[981240] score + 5
This rule will trigger on HTTP requests, which contain SQL keywords and conditions, or attempts to use SQL comment sequences, which are commonly used in many SQL Injection attack payloads. For example:
– …) when 123 then …
– “#
– “–
– “ {
– chr(123)
– char(123)
– and some_word(…
– or some_word(…
– like some_word(…
– div some_word(…
– not some_word(…
– || (…
– && (…

[3000029] score + 5
This rule is a complement to rule 981240, and they should be enabled together.

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.
As part of most SQL Injection attacks, hackers often attempt to manipulate the original query’s logic by inserting additional conditions or comment sequences.

This rule will trigger on HTTP requests, which contain SQL keywords and conditions, or attempts to use SQL comment sequences, which are commonly used in many SQL Injection attack payloads. For example:
– …) when 123 then …
– “#
– “–
– “ {
– chr(123)
– char(123)
– and some_word(…
– or some_word(…
– like some_word(…
– div some_word(…
– not some_word(…
– || (…
– && (…

[981249] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule looks for certain partial SQL statements, which may be used by hackers to mount a SQL Injection attack. The partial statements include:
– ‘ and =<…
– ( select column (…
– */from…
– +4+@…
– foo’ = (…
– coalesce (…
– @@foobar =…
– !’a…
– ‘; if…
– ‘; while…
– ‘; begin…
– ‘5=5…
– order by if (…
– (case abc then (…

[981242] score + 5
This rule looks for HTTP requests, which contain certain SQL operators, expressions and other SQL Injection probing payloads such as (multiple alternatives appear inside [ ])
– ‘ [or, div, like, between, and] ‘5
– \\x23
– \\x27
– \\x3d
– ‘
– a’ [and, or, div, like, between, and, not, ||, &&] ‘+
– ‘foo|’bar
– @foo [and, or, xor, div, like, between] ‘
– ‘ 5 < ‘
– information_schema
– table_name

[981246] score + 5
In some scenarios, SQL injection is used to bypass web-based authentication. The bypass is done by manipulating the original query’s logic, which is usually performed by injecting SQL expressions and certain SQL keywords.

This rule looks for HTTP requests, which contain certain SQL operators, expressions and other common SQL Injection payloads such as (multiple alternatives appear inside [ ])
– in (select…
– [nand, and, xor, xxor, div, like, between, and, not, ||, &&] x regexp (…
– [nand, and, xor, xxor, div, like, between, and, not, ||, &&] x sounds like ‘…
– [nand, and, xor, xxor, div, like, between, and, not, ||, &&] a = x…
– ‘ 5 –…
– ‘ 5 #…
– ‘<5 [=, xor, or, div, like, between, and]…
– ‘ x = 5 ‘…
– ‘ is 5 ‘foo…

[3000030] score + 5
This rule is a complement to rule 981246, and they should be enabled together.

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.

In some scenarios, SQL injection is used to bypass web-based authentication. The bypass is done by manipulating the original query’s logic, which is usually performed by injecting SQL expressions and certain SQL keywords.

This rule looks for HTTP requests, which contain certain SQL operators, expressions and other common SQL Injection payloads such as (multiple alternatives appear inside [ ])
– in (select…
– [nand, and, xor, xxor, div, like, between, and, not, ||, &&] x regexp (…
– [nand, and, xor, xxor, div, like, between, and, not, ||, &&] x sounds like ‘…
– [nand, and, xor, xxor, div, like, between, and, not, ||, &&] a = x…
– ‘ 5 –…
– ‘ 5 #…
– ‘<5 [=, xor, or, div, like, between, and]…
– ‘ x = 5 ‘…
– ‘ is 5 ‘foo…

[981243] score + 3
In order to perform SQL Injection attacks, hackers often use SQL operators, mainly in the context of Blind SQL attacks.

This rule looks for HTTP requests, which contain certain SQL operators, expressions and other SQL Injection probing payloads such as ‘xor’, ‘or’, ‘div’, ‘like’, ‘between’, ‘and’, ‘id’, ‘nand’, …

[3000017] score + 5
As part of most SQL Injection attacks, hackers often attempt to access known common database resources such as databases, tables, objects and functions. This rule looks for certain common MySQL database function calls, which appear as part of an HTTP request input. The functions are:
– benchmark()
– sleep()
– char()
– concat()
– sha1()
– substr()
– cast()
– varchar()
– ascii()
– md5()
– sha()
– bin()
– uncompress()
– find_in_set()
– conv()

The rule counts the number of different functions used (uniquely), and if the number is greater or equal to 2 – it will trigger an action.

The detection runs on the following selectors:
– Parameter (body and query) values
– Parameter (body and query) names
– XML data

[981260] score + 3
In order to bypass SQL Injection protections, as well as web application firewall logic, some hackers attempt to inject SQL encoded strings. There are several types of encoding schemes, one of which is referred to as Hex encoding. For example, the string ‘Hello World’ can be encoded in SQL hex encoding as: ‘0x48656c6c6f20576f726c64’.

[981318] score + 1
In order to mount a SQL Injection attack, hackers and SQL Injection exploit scripts are required to first terminate the existing string literal context of the original SQL query. In order to do so, SQL string terminating characters must be used – these include: apostrophe (‘), quotes (“) and other Unicode representation of these characters.
This rule will detect an attempt to inject string terminating characters, if they appear at the beginning or end of the user’s input. For example, the string – admin’ will trigger this rule.

[981320] score + 5
As part of most SQL Injection attacks, hackers often attempt to access known common database resources such as databases, tables, objects and functions. This rule looks for certain known database resources, which appear as part of an HTTP request input. The resources are: ‘msysaccessobjects’, ‘msysaces’, ‘msysobjects’, ‘msysqueries’, ‘msysrelationships’, ‘msysaccessstorage’, ‘msysaccessxml’, ‘msysmodules’, ‘msysmodules2’, ‘mdb’, ‘master..sysdatabases’, ‘mysql.db’, ‘sys.database_name’, ‘sysaux’, ‘schema(‘, ‘schema_name’, ‘sqlite_temp_master’, ‘sqlite_master’, ‘database(‘, ‘db_name(‘, ‘information_schema’, ‘pg_catalog’, ‘pg_toast’, ‘northwind’ and ‘tempdb’.

[950007] score + 5
As part of most SQL Injection attacks, hackers often attempt to access known common database resources such as databases, tables, objects and functions. This rule looks for certain known database resources and keywords, which appear as part of an HTTP request input. The resources are: ‘sys.user_tab_columns’, ‘sys.user_tables’, ‘sys.user_triggers’, ‘sys.user_objects’, ‘sys.user_views’, ‘sys.user_constraints’, ‘sys.user_catalog’, ‘sys.all_tables’, ‘sys.tab’, select (keyword) followed by ‘substring’, select (keyword) followed by ‘users’, select (keyword) followed by ‘ascii’, ‘msysqueries’, ‘msysrelationships’, ‘msyscolumns’, ‘msysobjects’, ‘mysql.db’, ‘mysql.user’, ‘constraint_type’, ‘charindex’, ‘waitfor delay’, ‘attnotnull’, ‘locate’, ‘instr(‘, ‘@@spid’, ‘sysprocesses’, ‘systables’, ‘sysfiltergroups’, ‘sysobjects’, ‘sysconstraints’, ‘syscolumns’, ‘syscat’, ‘sysdba’, ‘sysibm’, ‘substr’ and ‘substring’, ‘user_contstraints’, ‘user_objects’, ‘user_tab_columns’, ‘user_tables’, ‘user_ind_columns’, ‘user_users’, ‘user_passwords’, ‘user_groups’, ‘attrelid’, ‘atttypid’, ‘all_objects’, ‘object_name’, ‘object_type’, ‘object_id’, ‘pg_attribute’, ‘pg_class’, ‘column_name’, ‘column_id’, ‘xtype’ and ‘char’, ‘mn_users’, ‘rownum’, ‘table_name’, ‘textpos(‘.

[950001] score + 5
As part of most SQL Injection attacks, hackers often attempt to inject known built-in SQL functions, objects and keywords. This rule will trigger on HTTP requests containing functions such as: ‘sys_context’, ‘utl_inaddr’, ‘benchmark’, ‘print @@’, ‘collation’, ‘dbms_java’, ‘cast(‘, ‘shutdown’, ‘drop’, ‘@@version’, etc.

[959070] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule looks for certain partial SQL statements, which may be used by hackers to mount a SQL Injection attack. The partial statements include:
– SQL ‘having’ clause (e.g. having ‘abc’ > …)
– Transact-SQL ‘execute’ statements (e.g. ‘execute (‘ )
– SQL ‘create table’ statements (e.g. ‘create table (‘ )
– SQL ‘like’ operator and ‘char()’ function (e.g. ‘like char(‘ )
– SQL ‘select’ followed by the ‘case’ keyword
– SQL ‘from’ followed by the ‘limit’ keyword
– SQL ‘order by’ keywords
– SQL subquery using ‘exists’ followed by ‘select’
– SQL subquery using ‘exists’ followed by ‘select if null(‘
– SQL subquery using ‘exists’ followed by ‘select top’
– SQL subquery using ‘exists’ followed by ‘select concat’
– SQL subquery using ‘exists’ followed by ‘system (‘
– SQL subquery using ‘exists’ followed by ‘having [number]’
– SQL subquery using ‘exists’ followed by a string literal

[959072] score + 5
Common forms of Blind SQL Injection attacks manipulate boolean expressions inside SQL statements in order to undermine application logic. This can be done by using the ‘AND’ operator.

This rule looks for certain SQL expressions that rely on the ‘AND’ operator, for example:
– AND 1=
– AND ‘string’=
– AND ‘string'<
– AND 2<
– AND ‘string’

[950908] score + 5
As part of most SQL Injection attacks, hackers often attempt to inject known built-in SQL functions, objects and keywords. This rule will trigger on HTTP requests containing the keywords:
– ‘root@’
– ‘coalesce’

[959073] score + 5
As part of most SQL Injection attacks, hackers often attempt to inject known built-in SQL functions, objects and keywords. This rule will trigger on HTTP requests, which contain such keywords. For example: ‘std_dev_pop’, ‘str_to_date’, ‘sec_to_time’, ‘soundex’, ‘system_user’, ‘schema’, ‘isnull’, ‘is_free_lock’, ‘is_not_null’, ‘inet6_aton’, ‘ifnull’, ‘last_insert_id’, ‘timestamp’, ‘timediff’, ‘select’…’length’…’from’, ‘select’…’count’…’from’, ‘sp_sqlexec’, ‘group’…’by’…’having’, ‘etc’.

[960024] score + 3
Many web application layer attacks such as SQL Injection, Cross-Site Scripting, Path Traversal and so forth, rely on the fact that the web application allows certain hazardous characters to be injected as user input. Some of these characters are: apostrophe (‘), quotes (“), slash (/), backslash (\), dot (.), parenthesis, curly brackets, angle bracket, and so forth.

This rule will trigger on HTTP requests, which contain 4 or more consecutive ‘non-word’ characters (i.e. every character except a-z, A-Z, 0-9 and underscore).

The detection runs on the ‘ARGS’ selector (parameter values – both body and query). Prior to the pattern match, values are first URL-decoded in order to avoid WAF evasion techniques of various sorts.

Note: this rule may yield irrelevant triggers on some cookie values, especially when cookie values are complex and contain multiple elements within a single cookie. For example JSON objects, XML payloads and any proprietary format which uses certain non-word delimiters.

[981272] score + 5
According to the MITRE CAPEC project, a Blind SQL Injection vulnerability results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection.

One form of Blind SQL Injection is referred to as ‘Time-based Blind SQL Injection’. In this technique, the attacker relies on the database pausing for a specified amount of time, then returning the results, indicating successful SQL query executing. Using this method, an attacker enumerates each letter of the desired piece of data using the following logic – If the first letter of the first database’s name is an ‘A’, wait for 10 seconds…If the first letter of the first database’s name is an ‘B’, wait for 10 seconds. etc.

This rule will trigger on HTTP requests, which contain the SQL expressions:
– benchmark(… , …)
– sleep (…)

[981255] score + 5
As part of most SQL Injection attacks, hackers often attempt to inject known built-in SQL functions, objects and keywords. This rule will trigger on HTTP requests, which contain such keywords. For example:
– exec xp_cmdshell
– from information_schema
– current_user(…
– ‘; union …
– iif(…
– exec master.
– union select @
– select…user(
– into dump file ‘

[981277] score + 3
According to the MITRE CWE project, an integer overflow or wraparound occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may wrap to become a very small or negative number. While this may be intended behavior in circumstances that rely on wrapping, it can have security consequences if the wrap is unexpected. This is especially the case if the integer overflow can be triggered using user-supplied inputs. This becomes security-critical when the result is used to control looping, make a security decision, or determine the offset or size in behaviors such as memory allocation, copying, concatenation, etc.

This rule will trigger on HTTP requests, which contain attempts to overflow integer values. The following patterns in this rule were taken from the Skipfish web application scanner: ‘-0000023456′,’ 4294967295′,’ 4294967296′,’ 2147483648′,’ 2147483647′,’ 0000012345′,’ -2147483648′,’ -2147483649′,’ 0000023456′,’ 2.2.60738585072007e-308′ and ‘1e309’.

[981250] score + 5
According to the MITRE CAPEC project, a Blind SQL Injection vulnerability results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection.

One form of Blind SQL Injection is referred to as ‘Time-based Blind SQL Injection’. In this technique, the attacker relies on the database pausing for a specified amount of time, then returning the results, indicating successful SQL query executing. Using this method, an attacker enumerates each letter of the desired piece of data using the following logic – If the first letter of the first database’s name is an ‘A’, wait for 10 seconds…If the first letter of the first database’s name is an ‘B’, wait for 10 seconds. etc.

This rule will trigger on HTTP requests, which contain the SQL expressions:
– select benchmark((…
– select sleep ((…
– ; benchmark ((…
– ; sleep ((…

[981241] score + 5
A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.

As part of most SQL Injection attacks, hackers often attempt to manipulate the original query’s logic by inserting additional conditions. This rule will trigger on HTTP requests, which contain relevant keywords and conditions. For example:
– ) case (
– ) like (
– having ‘col’
– if (5=…)

[981252] score + 5
As part of most SQL Injection attacks, hackers often attempt to inject known built-in SQL functions, objects and keywords. This rule will trigger on HTTP requests, which contain such keywords and relevant phrases. For example:
– alter x character set utf8
– ‘; waitfor time ‘
– ‘; label: goto

[981276] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

One of the common ways to piggyback a seconday SQL query on top of the existing one, is to use the ‘UNION’ SQL keyword, which combines the results of two or more queries into a single result set that includes all the rows that belong to all queries in the union.

This rule will trigger on HTTP requests, which contain attempts to inject a secondary SQL query using the ‘UNION’ keyword. For example: ‘ union select * from users…’

[981254] score + 5
According to the MITRE CAPEC project, a Blind SQL Injection vulnerability results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection.

One form of Blind SQL Injection is referred to as ‘Time-based Blind SQL Injection’. In this technique, the attacker relies on the database pausing for a specified amount of time, then returning the results, indicating successful SQL query executing. Using this method, an attacker enumerates each letter of the desired piece of data using the following logic – If the first letter of the first database’s name is an ‘A’, wait for 10 seconds…If the first letter of the first database’s name is an ‘B’, wait for 10 seconds. etc.

This rule will trigger on HTTP requests, which contain the SQL expressions:
– select pg_sleep… (PostgreSQL sleep function)
– waitfor delay ‘…(Transact-SQL ‘block until’ function)
– ; shutdown … (Transact-SQL shutdown function)

[981270] score + 5
According to OWASP – NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren’t using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural language , rather than in the declarative SQL language, the potential impacts are greater than traditional SQL injection.

One of the most popular open source NoSQL databases is MongoDB.

This rule will trigger on HTTP requests, which contain attempts to perform simple NoSQL injections on MongoDB, by looking for certain MongoDB keywords such as:
– [$size]
– [$slice]
– [$lte]
– [$exists]
– [$and]
– [$type]
– [$between]
– [$mod]
– [$nin]

[981253] score + 5
One of the common approaches for mitigating SQL Injections is to use stored procedures. While stored procedures prevent some types of SQL injection attacks, they fail to protect against many others.

This rule looks for HTTP requests containing attempts to perform SQL Injection on stored procedures. For example:
– procedure analyse(…
– ; declare foobar…
– ; open foobar…
– create procedure foobar ( ) -…
– create function foobar ( ) -…
– declare @foobar…
– exec (@foobar…

[981251] score + 5
MySQL databases exposes an API to add functions through the user-defined function (UDF) interface. User-defined functions are compiled as object files and then added to and removed from the server dynamically using the CREATE FUNCTION and DROP FUNCTION statements. In some scenarios, the UDF interface may be exploited to perform SQL Injection attacks against applications using MySQL.

This rule looks for HTTP requests, which contain certain MySQL UDF related keywords and expressions, such as:
– create function foobar returns…
– ; [select, create, rename, truncate, load, alter, delete, update, insert, desc] (foobar…

[981247] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution. In addition to using secondary SQL statements, hackers also attempt to access local files on the database system, through native database file APIs.

This rule looks for certain partial SQL statements, or the use of database file APIs, which may be used by hackers to mount a SQL Injection attack. This includes (multiple alternatives appear inside [ ]):
– ) as foobar from…
– 5 [union, select, create, rename, truncate, load, alter, delete, update, insert, desc]
– [union, select, create, rename, truncate, load, alter, delete, update, insert, desc] group_concat(
– [union, select, create, rename, truncate, load, alter, delete, update, insert, desc] char(
– [union, select, create, rename, truncate, load, alter, delete, update, insert, desc] load_file(
– end );
– ‘ regexp
– (load_file(

[3000000] score + 1000
One of the common ways to probe applications for SQL Injection vulnerabilities is to use the ‘GROUP BY’ and ‘ORDER BY’ clause. Prior to using these clause in a SQL statement, the hacker first terminates the current query’s context (assuming user input is used in the WHERE clause), which could be either numeric or a string literal, and after the clauses and comments out the rest of the query.

This rule triggers on HTTP requests, which contain SQL Injection probes that use the ‘GROUP BY’ and ‘ORDER BY’ clause as mentioned above, when they are sent as user-input.
For example:
– some_string’ ORDER BY some_col–
– some_string’ GROUP BY some_col;#
– 12345 ORDER BY some_col;#
– 12345 GROUP BY some_col–

[3000006] score + 5
Through SQL Injection attacks, hackers often manipulate the original underlying SQL query – in some cases, this is done by ending the query and commenting out the rest of the SQL statement after the injection point. For example, lets consider a query, which receives the username (e.g. ‘foo’) and password (e.g. ‘bar’) form the user, and embeds them inside the statement as follows:

SELECT * from users where username=’foo’ and password=’bar’

If a hacker terminates the query after the username, and comments out the rest of the query as follows:

SELECT * from users where username=’foo’;– and password=’whatever’

The application will allow the user to log into the site, without actually validating the password.

This rule triggers on HTTP requests, which contain SQL Injection attack payloads that attempt to end the query prematurely and comment out the rest of the statement. For example:
– admin’;–
– 111;–
– foobar’)#
– foobar’ /*

The detection runs on the following selectors:
– Parameter (body and query) values
– XML data

Prior to the pattern match, values are first URL-decoded in order to avoid WAF evasion techniques of various sorts.

[981245] score + 5
As part of most SQL Injection attacks, hackers often attempt to inject known built-in SQL functions, objects and keywords. This rule will trigger on HTTP requests, which contain such keywords and relevant phrases. For example:
– union all (select…
– union distinct (select…
– union @(select…
– foobar like ‘…
– like ‘%…
– ‘ like ‘…
– ‘ and a=a having…
– ‘ or a=a having…
– ‘ * a ‘
– select (‘abc’) from

[3000044] score + 5
Common forms of Blind SQL Injection attacks manipulate boolean expressions inside SQL statements in order to undermine application logic. This can be done by using the boolean operators.

This rule looks for certain SQL expressions that rely on ‘boolean’ operators.

[3000045] score + 5
Common forms of Blind SQL Injection attacks manipulate boolean expressions inside SQL statements in order to undermine application logic. This can be done by using the boolean operators.

This rule looks for certain SQL expressions that rely on ‘boolean’ operators.

[3000046] score + 3
Common forms of Blind SQL Injection attacks manipulate boolean expressions inside SQL statements in order to undermine application logic. This can be done by using the boolean operators.

This rule looks for certain SQL expressions that rely on ‘boolean’ operators.

[3000047] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule will trigger on HTTP requests, that contain attempts to inject a secondary SQL query using the ‘backup’ keyword.

[3000048] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule will trigger on HTTP requests, that contain attempts to inject a secondary SQL query using the ‘restore’ keyword.

[3000049] score + 5
A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.

In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule will trigger on HTTP requests, that contain attempts to inject a secondary SQL query using cursor declarations.

[3000050] score + 5
Common forms of Blind SQL Injection attacks manipulate boolean expressions inside SQL statements in order to undermine application logic. This can be done by using the boolean operators.

This rule looks for certain SQL expressions that rely on ‘boolean’ operators.

[3000051] score + 5
Common forms of Blind SQL Injection attacks manipulate boolean expressions inside SQL statements in order to undermine application logic. This can be done by using the boolean operators.

This rule looks for certain SQL expressions that rely on ‘boolean’ operators.

[3000052] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule will trigger on HTTP requests, that contain attempts to inject a secondary SQL query using the ‘EXISTS’ keyword.

[3000053] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule will trigger on HTTP requests, that contain attempts to inject a secondary SQL query using the ‘DELETE’ keyword.

[3000054] score + 5
In order to perform SQL Injection attacks, hackers often inject a secondary SQL statement, which ‘piggybacks’ on the original query. If successful, the secondary SQL statement can perform unintended actions on the SQL database, such as data extraction, data corruption or even command execution.

This rule will trigger on HTTP requests, that contain attempts to inject a secondary SQL query using the ‘UPDATE’ keyword.

[3000022] score + 5
This rule will trigger on attempts to perform damaging actions on SQL databases, such as deleting entire tables, databases, indexes, schemas or columns. The rule looks for:
– DROP statements
– TRUNCATE statements

[3000015] score + 5
According to the MITRE CAPEC project, a Blind SQL Injection vulnerability results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection.

One form of Blind SQL Injection is referred to as ‘Time-based Blind SQL Injection’. In this technique, the attacker relies on the database pausing for a specified amount of time, then returning the results, indicating successful SQL query executing. Using this method, an attacker enumerates each letter of the desired piece of data using the following logic – If the first letter of the first database’s name is an ‘A’, wait for 10 seconds…If the first letter of the first database’s name is an ‘B’, wait for 10 seconds. etc.

This rule will trigger on HTTP requests, which contain the SQL expressions:
– pg_sleep… (PostgreSQL sleep function)
– waitfor delay…(Transact-SQL ‘block until’ function)
– waitfor time… (Transact-SQL shutdown function)

The detection runs on the following selectors:
– Parameter (body and query) values
– XML data

Note: this rule is very similar to rule 981254, but uses a more strict and accurate pattern, based on further research of proper syntax and actual usage of these functions by hackers. It is recommended to use this rule in conjunction to the already existing rules, as a mean to boost anomaly score.

[981257] score + 2
As part of most SQL Injection attacks, hackers often attempt to inject SQL keywords. This rule will trigger on HTTP requests, which contain such keywords. For example: ‘select’, ‘create’, ‘rename’, ‘truncate’, ‘load’, ‘alter’, ‘delete’, ‘update’, ‘insert’, ‘desc’, ‘select…from’, etc.

=============================================

[ALL]
The detection runs on the following selectors:
– Request cookie names
– Request cookie values (not including Google analytics cookies)
– Parameter (body and query) names
– Parameter (body and query) values
– XML data