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.

Ir a la instalación

Repositorio: igbuend/grimbard
Última actividad en el origen: 12 de febrero de 2026 a las 07:05
Idioma detectado de SKILL.md: inglés
Estrellas: 8
Forks: 1

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Volver a la búsqueda Volver a la instalación

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