SQL Injection: Blind Boolean Based

A SQL injection attack is the insertion (injection) of a malicious SQL query via the input data from a client to an application. As a result, an attacker can execute any SQL query on the client's database with the access rights that are granted to the application. It means that the attacker can read, update, or delete sensitive data, or even administrate operations on the server side.

Blind Boolean Based is a specific type of the SQL Injection, which relies on the TRUE or FALSE question to the database and determines the answer based on the response.

This vulnerability allows an attacker to:

• Modify application data
• Bypass protection mechanism
• Read application data

1. The unprotected application executes the following query containing the user input Laptops, which returns only active products for selected category:

SELECT name, price FROM products WHERE category = 'Laptops' AND status = 'active'

2. Instead of the Laptops, an attacker can submit the input like: ' OR 1=1--. As a result, the application will return all products with any status. The following SQL will be executed:

SELECT name, price FROM products WHERE category = '' OR 1=1-- 

The issue can be found in the source code on the server side.

• Use the prepared statements with variable binding (aka parameterized queries). Parameterized queries force the developer to first define all the SQL code, and then pass each parameter (given below) to the query later. This coding style allows the database to distinguish between code and data, regardless of the input type a user supplies.
  • Java EE – use PreparedStatement() with bind variables
  • .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
  • PHP – use PDO with strongly typed parameterized queries (using bindParam())
  • Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)
  • SQLite - use sqlite3_prepare() to create a statement object
• Avoid generation of dynamic SQL inside stored procedures. If it can't be avoided, the stored procedure must use input validation or proper escaping to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query.
• Use the least privilege approach to provide defense in depth and minimize the potential damage of a successful SQL injection attack. Minimize the privileges assigned to every database account in your environment (do not assign DBA or admin type access rights to your application accounts).

• CWE-89
• CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

• https://cwe.mitre.org/data/definitions/89.html
• https://www.owasp.org/index.php/Blind_SQL_Injection
• https://brightsec.com/blog/blind-sql-injection/