second-order-injection-anti-pattern

Security anti-pattern for second-order injection vulnerabilities (CWE-89 variant). Use when generating or reviewing code that retrieves data from databases, caches, or storage and uses it in subsequent queries or commands. Detects trusted internal data used unsafely.

Jump to install

Repository: igbuend/grimbard
Last source activity: February 12, 2026 at 07:05
Detected SKILL.md language: English
Stars: 8
Forks: 1

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

name	second-order-injection-anti-pattern
description	Security anti-pattern for second-order injection vulnerabilities (CWE-89 variant). Use when generating or reviewing code that retrieves data from databases, caches, or storage and uses it in subsequent queries or commands. Detects trusted internal data used unsafely.

Second-Order Injection Anti-Pattern

Severity: High

Summary

Malicious payloads are stored safely in databases or logs, then executed later when retrieved and used without re-sanitization. Initial storage appears secure (properly parameterized), but subsequent retrieval and unsafe use activates the payload. Injection and execution points are separated in time and code location, making detection difficult.

The Anti-Pattern

The anti-pattern is treating database-retrieved data as safe and using it in queries or commands without re-sanitization or parameterization.

BAD Code Example

# VULNERABLE: Data is stored safely, but later retrieved and used unsafely.
import sqlite3

db = sqlite3.connect("app.db")
db.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT, email TEXT)")
db.execute("CREATE TABLE IF NOT EXISTS logs (id INTEGER PRIMARY KEY, action TEXT, user_email TEXT)")

# Step 1: User Registration (appears safe)
def register_user(name, email):
    # Parameterized query, safe against direct injection.
    # Attacker email: "bad@example.com' UNION SELECT password FROM users -- "
    # Safely stored as string in 'email' column.
    db.execute("INSERT INTO users (name, email) VALUES (?, ?)", (name, email))
    db.commit()

# Step 2: Logging (VULNERABLE on retrieval)
def log_user_action(user_id, action):
    # Retrieve user email from database.
    cursor = db.execute("SELECT email FROM users WHERE id = ?", (user_id,))
    user_email = cursor.fetchone()[0]

    # FLAW: user_email concatenated into query.
    # Application "trusts" data from own database.
    log_query = f"INSERT INTO logs (action, user_email) VALUES ('{action}', '{user_email}')"

    # Result: INSERT INTO logs (action, user_email) VALUES ('view_profile', 'bad@example.com' UNION SELECT password FROM users -- ')
    # Injected SQL executes, exposing passwords.
    db.execute(log_query)
    db.commit()

# Attack: Register with crafted email → trigger logging → payload executes.

GOOD Code Example

# SECURE: All data used in SQL queries is parameterized, regardless of its source.
import sqlite3

db = sqlite3.connect("app_safe.db")
db.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT, email TEXT)")
db.execute("CREATE TABLE IF NOT EXISTS logs (id INTEGER PRIMARY KEY, action TEXT, user_email TEXT)")

# Step 1: User Registration (safe)
def register_user_safe(name, email):
    db.execute("INSERT INTO users (name, email) VALUES (?, ?)", (name, email))
    db.commit()

# Step 2: Logging (safe)
def log_user_action_safe(user_id, action):
    cursor = db.execute("SELECT email FROM users WHERE id = ?", (user_id,))
    user_email = cursor.fetchone()[0]

    # SECURE: Database-retrieved user_email still treated as untrusted.
    # Passed as parameter, not concatenated.
    db.execute("INSERT INTO logs (action, user_email) VALUES (?, ?)", (action, user_email))
    db.commit()

Detection

Audit data flows: Systematically track data from its entry point (user input) through its storage and subsequent retrieval and use.
Identify dynamic query/command construction: Look for any code that builds SQL queries, shell commands, or other interpretive language statements by concatenating strings that include variables whose values originated from user input, even if they were stored in a database.
Review stored procedures: If your application uses stored procedures, examine their definitions for any dynamic SQL that might use input parameters without proper escaping or parameterization.
Consider background jobs/asynchronous tasks: Pay special attention to components that process data in the background, as they might retrieve stored data and use it in new, insecure contexts.

Prevention

Parameterize all queries: Always use prepared statements for all database interactions, regardless of data source (user input or database retrieval).
Never trust database data: Treat database-retrieved data as tainted if it originated from user input. Apply same validation/sanitization as fresh input.
Use ORMs consistently: ORMs auto-parameterize queries when used correctly. Avoid "raw query" features bypassing protections.
Escape output before display: Defense-in-depth against XSS when rendering database data in HTML.

Related Security Patterns & Anti-Patterns

SQL Injection Anti-Pattern: Second-order SQL injection is a variant of this fundamental vulnerability.
Command Injection Anti-Pattern: Similar second-order risks exist when data stored safely is later used in an insecure shell command.
Log Injection Anti-Pattern: Log files can be a vector for second-order attacks if logged data is later used in an insecure context (e.g., parsing logs with a vulnerable regex).

References