Understanding Database SQL Injection: Types, Examples, and Defense Strategies

Background

Databases play a critical role in information systems due to their strong storage and processing capabilities, but their widespread adoption has led to frequent data leakage incidents, making database security a growing concern. Although vendors have introduced many mitigations, vulnerabilities continue to rise, and SQL injection remains the most common type.

SQL Injection Classification

1) Injection Path Classification

SQL injection can be divided into two major physical paths: injection through a web front‑end that reaches the database, and direct injection by connecting to the database as a privileged user.

Direct database injection allows an attacker to execute arbitrary SQL statements after gaining a database account, often exploiting stored procedures, functions, triggers, or anonymous blocks that lack proper privilege checks.

Web‑based injection typically relies on concatenating user input into SQL queries, enabling attackers to retrieve all information accessible to the compromised account.

Advanced attacks often combine both paths: first exploiting a web‑application injection to gather database details, then using a native database injection to elevate privileges or exfiltrate data.

2) Injection Method Classification

Based on the technique used, SQL injection attacks are grouped into four categories: SQL Manipulation, Code Injection, Function Call Injection, and Buffer Overflows. The first two are common in web contexts, while the latter two target the database engine directly and are typically more severe.

SQL Manipulation : The attacker injects additional clauses (e.g., UNION, INTERSECT) into an existing query to alter its logic. Classic examples include bypassing authentication by forcing a WHERE clause to always evaluate true.

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'guess';
-- attacker modifies to:
SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'xxxx' or 'a'='a';

Union‑based manipulation can also merge results from another table, exposing sensitive data such as usernames and passwords.

SELECT product_name FROM all_products WHERE product_name like '%ddd%';
-- attacker modifies to:
SELECT product_name FROM all_products WHERE product_name like '%ddd%' UNION SELECT username,password FROM dba_users WHERE username like '%';

Code Injection : The attacker adds whole SQL statements or commands to an existing query. This technique is prevalent against Microsoft SQL Server's EXECUTE statements and can affect PL/SQL or Java environments that allow multiple statements in a single call.

Function Call Injection : Vulnerabilities in stored functions, procedures, or triggers enable the attacker to execute unintended operations, such as sending data to remote hosts or performing privileged actions. Oracle packages with hundreds of functions are especially attractive targets.

Buffer Overflows : Certain unpatched database functions (e.g., TZ_OFFSET, BFILENAME) can be abused via SQL injection to trigger memory corruption, leading to remote code execution or denial‑of‑service conditions.

Example: Creating a Stored Procedure "test"

create or replace procedure test (putin varchar2) as
  type c_type is ref cursor;
  cv c_type;
  buffer varchar2(200);
begin
  dbms_output.enable(1000000);
  open cv for 'select object_name from all_objects where owner ='''||putin||''' and object_type=''library''';
  -- ...
  close cv;
end;
/

This procedure appears safe but is vulnerable to function‑call injection because it concatenates the input variable directly into a dynamic SQL statement without validation.

Create or replace function get_dba return varchar authid current_user is
  pragma autonomous_transaction;
begin
  execute immediate 'grant dba to scott';
end;
/

A low‑privilege user can create the above function and then invoke the vulnerable procedure to obtain DBA rights.

Exec sys.test('AAAA' || username.get_dba()--');

After the privilege escalation, the attacker can fully control the database. Vendors typically mitigate such issues by revoking public execution rights on vulnerable functions.

Defending Against SQL Injection

Database vendors have released patches and utilities (e.g., Oracle's DBMS_ASSERT) to harden input handling, but these solutions do not cover all second‑order or cross‑language injection scenarios. Timely patching is essential, yet many environments cannot apply updates promptly.

1. Encrypt sensitive data at its source so that even if it is stolen, the information remains unreadable. 2. Deploy a database firewall that parses the database protocol, accurately identifies risky SQL syntax, provides virtual patching, enforces fine‑grained permission controls, and offers auditing, monitoring, and behavior analysis to block intrusion attempts.

Implementing these strategies, together with regular patch management, significantly improves the security posture of database systems.