SQL Injection Attacker

• HTTP requests containing SQL keywords in parameters: UNION, SELECT, DROP, OR 1=1, --, xp_cmdshell
• Unusual characters in query parameters: single quotes ('), double dashes (--), semicolons (;)
• Application error responses revealing database error messages or stack traces
• Requests to URL parameters with encoded SQL: %27, %3B, %2D%2D
• Automated sqlmap signatures in User-Agent or request patterns (sqlmap/1.x)

Detect SQLi attempts in web logs

# Grep Nginx/Apache logs for common SQLi patterns
grep -Ei "(union.*select|select.*from|insert.*into|drop.*table|or.*1=1|'.*--|xp_cmdshell|information_schema)" \
  /var/log/nginx/access.log | awk '{print $1, $7}' | head -30

ModSecurity WAF (OWASP CRS SQLi rules)

# OWASP CRS Rule Set IDs 942xxx cover SQL injection
SecRuleEngine On
# Key rules:
# 942100: SQL Injection Attack Detected via libinjection
# 942200: Detects MySQL comment-/space-obfuscated injections
# 942440: SQL Comment Sequence Detected

Suricata HTTP rule

alert http any any -> $HTTP_SERVERS any \
  (msg:"SQL Injection attempt"; \
   pcre:"/(\bUNION\b.*\bSELECT\b|OR\s+1\s*=\s*1|DROP\s+TABLE)/Ui"; \
   http_uri; sid:4000001;)

Application-level logging (Django example)

import logging
import re

SQLI_PATTERN = re.compile(
    r"(\bUNION\b|\bSELECT\b|\bDROP\b|\bINSERT\b|OR\s+1\s*=\s*1|--\s*$)",
    re.IGNORECASE,
)

def sqli_detection_middleware(get_response):
    def middleware(request):
        for key, value in request.GET.items():
            if SQLI_PATTERN.search(value):
                logging.warning("SQLi pattern in param %s from %s", key, request.META.get("REMOTE_ADDR"))
        return get_response(request)
    return middleware

1. Use parameterised queries exclusively — Never interpolate user input into SQL strings. Use ORM query builders (Django ORM, SQLAlchemy) or prepared statements with bound parameters (cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])).
2. Implement a Web Application Firewall — OWASP ModSecurity CRS or a cloud WAF (Cloudflare, AWS WAF) blocks the vast majority of automated SQLi attempts.
3. Apply least-privilege database accounts — The application database user should have only SELECT/INSERT/UPDATE/DELETE on necessary tables — never DROP, CREATE, or FILE privileges.
4. Sanitise and validate all inputs — Enforce strict type validation (integers must be integers, emails must match regex) and reject unexpected characters before they reach query logic.
5. Disable detailed database error messages in production — Return generic error pages; never expose SQL error text, table names, or stack traces to the client.
6. Enable database activity monitoring — Tools like pgAudit (PostgreSQL) or MySQL General Query Log can detect anomalous query patterns.
7. Run regular DAST scans — Use OWASP ZAP or Burp Suite against your staging environment to catch SQLi vulnerabilities before deployment.
8. Rotate database credentials immediately on suspected compromise — If SQLi is confirmed, assume all data is exfiltrated and rotate all database passwords.

2017 — Equifax data breach (147 million records): While the Equifax breach's initial vector was Apache Struts RCE (CVE-2017-5638), subsequent lateral movement included SQL injection attacks against internal database interfaces. The breach exposed names, SSNs, birth dates, and credit card numbers of 147 million Americans, resulting in a $575 million FTC settlement.

2012 — LinkedIn 6.5 million password hash dump: Attackers exploited SQL injection vulnerabilities in LinkedIn's web application to extract 6.5 million unsalted SHA-1 password hashes, which were cracked within hours due to the absence of password salting. The breach was later revised to 117 million accounts in a 2016 disclosure.