Database Injection Attacks: Principles, Exploits, and Defense Strategies

Data is a core asset for both enterprises and users, and frequent large‑scale leaks highlight the urgent need for robust data protection; database injection attacks are a major vector that compromises confidentiality, integrity, and availability of stored information.

Database injection occurs when malicious SQL commands are inserted into web‑form inputs or query strings, tricking the server into executing unintended queries, which can lead to unauthorized data reading, modification, deletion, credential theft, and even full system compromise.

Typical data‑leak sources include user‑provided information (e.g., insecure Wi‑Fi, malware‑infected devices) and malicious actors who harvest, sell, or exploit leaked databases, as illustrated by numerous high‑profile incidents involving billions of records.

Attackers may use manual probing or automated tools. Common utilities include Nmap for port scanning, AWVS for web‑vulnerability assessment, sqlmap.py for fully automated SQL injection, nosqlmap.py for NoSQL databases, and various webshell payloads.

A typical exploitation workflow involves scanning the target, identifying vulnerable parameters (e.g., http://192.168.115.131/cat.php?id=1 ), confirming injection via error or time‑based techniques, using sqlmap to enumerate databases, tables, and columns, extracting data, uploading a webshell through sqlmap --sql-shell , and escalating privileges on the underlying operating system.

Example of vulnerable code (PHP): <?php $username = "aaa"; $pwd = "fdsafda' or '1'='1"; $sql = "SELECT * FROM table WHERE username = '{$username}' AND pwd = '{$pwd}'"; echo $sql; // outputs injected query ?> This illustrates the classic “universal password” problem caused by unsanitized input.

Defensive measures are organized into four layers:

Secure Coding (SDL): validate and sanitize all user input, use parameterized queries or stored procedures, encrypt sensitive data, and limit error information.

Database Hardening: enforce least‑privilege accounts, disable empty or weak passwords, restrict external access (e.g., firewall rules for port 3306), and employ DB‑proxy solutions such as Mycat or Druid‑sql‑wall for query filtering.

Web‑Server & WAF Configuration: implement request‑filtering rules (e.g., Nginx snippets that block suspicious query strings) and deploy web application firewalls (tengine_waf, nginx+Mod_security, etc.) to intercept injection patterns.

Log Analysis & Monitoring: analyze web server access logs with ELK, Hadoop, or Storm+Spark to detect anomalous SQL patterns and generate alerts.

By combining these practices, organizations can significantly reduce the risk of successful database injection, though the ongoing arms race between attackers and defenders means vigilance must be continuous.