DataSunrise’s Approach to Configuring Penalties for SQL Injection Detection

SQL injection is a prevalent threat to database security, where attackers manipulate SQL queries to gain unauthorized access to data. DataSunrise, a database security solution, offers a robust mechanism to detect and prevent SQL injection attacks through a system of penalty points. This article will explore how DataSunrise configures penalties for different types of SQL injection patterns and provide examples of each.

Penalty Points System

DataSunrise’s penalty points system assigns a numerical value to various components of an SQL query that may indicate a potential injection. When the sum of these penalties exceeds a predefined threshold, DataSunrise takes action, either by logging a warning (Audit Rule) or by blocking the query outright (Security Rule).

Examples of SQL Injection Patterns and Penalties

Comment Penalty

One of the basic tasks for an attacker when he tries to make an injection is to radically change the request. For this, he needs to disable/cut off that part of the request that he does not control or that will prevent him from performing the injection. To do this, code is added to the injection that will comment out that part of the request that is located after the injected block. Here are some examples.

1 Example. A common example is logging as admin:

Injection into the username parameter: admin’–

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

If successful, this will log you as the admin user because the rest of the SQL query after ‘–’ will be ignored.

2 Example. Classic Inline Comment SQL Injection Attack Samples

ID value: 10; DROP TABLE members /*

Simply get rid of other stuff at the end of the query. Same as 10; DROP TABLE members –

Therefore, the presence of comments in the request is one of the signs of a potential injection.

A Keyword in a Comment Penalty

Continuing the theme of comments in a request, we can say that ordinary comments can be found quite often in legitimate requests. For example, many IDEs used by developers automatically add the current time to the beginning of the request in the form of a comment or the version of the IDE in which the request was generated or other meta information. Therefore, an additional sign that a comment is suspicious is the presence of SQL keywords in it such as AND/OR/SELECT, etc.

For example, in the SQL expression discussed above

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

The AND keyword was commented out.

Double Query Penalty (Stacking Queries)

Stacking means executing more than one query in one transaction. This technique can be useful but only works for some combinations of database server and access methods:

SELECT * FROM members; DROP members--`

When successful, this will end one query and start another one.

Not all databases support executing two or more expressions in one query, but where it is supported, such cases need to be controlled.

DataSunrise does not generate errors if configuration expressions (SET and similar) or variable declaration queries are used in one expression. Such requests are not unusual.

OR Penalty + Constant Expression Penalty

Often, to use one or another injection, an attacker needs to create a condition such that it is true (TRUE). And for this, the simplest way can be an OR operation with a value that is always TRUE. For example, as in the example: https://insecure-website.com/products?category=Gifts’+OR+1=1–

This results in the SQL query:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

In this case, the query will display all categories, and not just those that should.

Of course, the OR operation is common and popular in application development, but together with other signs, it can help detect injection. The same applies to expressions that always return TRUE or FALSE.

Union Penalty

Our research has shown that cyber attackers use automated tools that help them identify the theoretical possibility of exploiting a particular vulnerability. If it is possible to add an additional expression to a vulnerable query, then the ability to access other tables is usually checked

select id, id from products where name = 'Gifts' UNION SELECT NULL, NULL from SYS.USERS --'

When you perform an SQL injection UNION attack, there are two effective methods to determine how many columns are being returned from the original query.

One method involves submitting a series of UNION SELECT payloads specifying a different number of null values:

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL–, etc.

If the number of nulls does not match the number of columns, the database returns an error, such as:

All queries combined using a UNION, INTERSECT or EXCEPT operator must have an equal number of expressions in their target lists.

An attacker uses NULL as the values returned from the injected SELECT query because the data types in each column must be compatible between the original and the injected queries. NULL is convertible to every common data type, so it maximizes the chance that the payload will succeed when the column count is correct.

To reduce the chances of detecting an injection, DataSunrise detects similar UNIONs that are used when scanning vulnerable applications and assigns additional penalty points.

Suspicious Conversion: Error Attack

Error-based SQL Injection technique forces the database to generate an error, giving the attacker or tester information upon which to refine their injection.

To force an application to generate a request that will be executed with an error, many different techniques are used. One of them is operations that explicitly or implicitly try to cast a value to a type to which it cannot be cast:

‘ and 1=convert(int,(select top 1 table_name from information_schema.tables))--

In this case, an error will be generated, the text of which will include a text value from the system table information_schema.tables.

However, this technique is not limited to such attacks. This technique can also be used for Blind Error-based attacks when the attacker can only find out whether there was an error or not.

Probably the most difficult type of check from an implementation point of view. The reason for this is that there are a huge number of possibilities to cause an error.

Concatenation of Single Characters for Many Types of Attacks

Another pattern that is often used in attacks is escaping the returned data. This is often necessary when the content of the attacked page changes frequently, and the automatic injection verification script must use special markers to find the payload (the valuable data that we want to extract).

For example,

AND 3516=CAST((CHR(113)||CHR(106)||CHR(122)||CHR(106)||CHR(113))||(SELECT (CASE WHEN (3516=3516) THEN 1 ELSE 0 END))::text||(CHR(113)||CHR(112)||CHR(106)||CHR(107)||CHR(113)) AS NUMERIC)

Such designs are suspicious for DataSunrise.

Suspicious Function Call

In any decent production application, you generally cannot see any error responses on the page. These rules out extracting data directly through UNION attacks or error-based attacks. In these cases, you have to use blind SQL injections to extract the data. There are two basic kinds of blind SQL injections.

Normal blind injections. You cannot see the response directly on the page, but you can still determine the result of a query based on a response or HTTP status code.

Totally blind injections. You cannot see the effects of your injection in any kind of output. This is less common, for example when you’re injecting into a logging function or similar.

In normal blind injections, you can use IF statements or abuse WHERE clauses in queries, which is generally the easier route. For totally blind injections, you need to use some kind of wait function and then analyze the response times.

Examples of available wait/timeout functions include:

WAITFOR DELAY '0:0:10' in SQL Server
BENCHMARK() and sleep(10) in MySQL
pg_sleep(10) in PostgreSQL

DataSunrise assigns additional penalty points if the request contains similar queries that are often used in attacks.

Suspicious Condition to Check for Boolean Blind Attack

Blind SQL injection is a type of SQL injection where the attacker does not receive an obvious response from the attacked database and instead reconstructs the database structure step-by-step by observing the behavior of the database server and the application. Blind SQL injection is also called inferential SQL injection.

There are two types of blind SQL injections: Boolean-based and time-based.

In this kind of attack, you cannot get the full result. The attacker comes to blindly obtain the content of the tables he is interested in, letter by letter. This can be very time-consuming and requires good automation.

Here is an example of such a request.

ORD(MID((SELECT grantee FROM(SELECT DISTINCT(grantee) FROM INFORMATION_SCHEMA.USER_PRIVILEGES LIMIT 0, 1) AS caou), 22, 1)) > 39--MnqX'

DataSunrise also issues penalty points if signs of such queries are detected.

Suspicious Count Penalty

These are the points that DataSunrise awards for suspicious blocks in SQL in the form SELECT count(*) FROM t1,t2.

The point is that if Time-based SQL Injection is available, the attacker needs to somehow distinguish between two branches of code execution. To do this, a request is executed in one of the branches, which takes a lot of time. For example, counting the number of rows in a join of two or more tables. When joining, the lines are multiplied and a lot of lines are obtained. And COUNT runs long enough for the script to notice it. You can read more details here. In that article, you will find the SLEEP(5), but that’s just kindergarten.

Many people have already proven this, and for this reason, they use more sophisticated methods in the form of COUNT+JOIN, which we described above. In normal practice, such a request, which is part of a more complex request, is not used and therefore this can serve as one of the signs of injection.

Conclusion

DataSunrise’s approach to configuring penalties for SQL injection detection presents a comprehensive and proactive strategy to safeguard databases against this pervasive threat. By employing a penalty points system that evaluates various aspects of SQL queries, DataSunrise effectively identifies and mitigates potential injection attempts. Through examples illustrating different SQL injection patterns and associated penalties, this article demonstrates the versatility and effectiveness of DataSunrise’s detection mechanisms.

In essence, DataSunrise’s meticulous configuration of penalties for SQL injection detection underscores its commitment to providing robust database security solutions. By leveraging advanced detection techniques and continuously refining its penalty system, DataSunrise empowers organizations to protect their critical data assets against SQL injection attacks effectively.