SQL injection defensiva: queries parametrizadas

# Una vez: cloná el repo y construí la imagen
git clone https://github.com/ValentinTorassa/Open-Security-Labs.git
cd Open-Security-Labs
podman build -t osl/sql-injection-parametrizada -f entornos/ciberseguridad/sql-injection-parametrizada/Containerfile entornos

# Abrí el entorno (se borra al salir)
podman run --rm -it --name osl-sql-injection-parametrizada --hostname labs osl/sql-injection-parametrizada

# Al terminar, adentro del contenedor
lab-check

SQL injection ocurre cuando input no confiable deja de ser dato y pasa a formar parte del programa SQL. La defensa no es “filtrar palabras raras”: es mantener separados código y datos.

El patrón vulnerable

email = request.query.email
sql = "SELECT id, email FROM users WHERE email = '" + email + "'"
db.query(sql)

El problema es que email termina dentro del texto SQL. Si el usuario controla ese valor, controla parte de la query.

La versión segura

email = request.query.email
sql = "SELECT id, email FROM users WHERE email = ?"
db.query(sql, [email])

El ? no se reemplaza concatenando strings. El driver manda el valor como parámetro.

Cómo documentarlo

source:      request.query.email
sink malo:   string SQL concatenado
impacto:     el input puede cambiar la lógica de la consulta
mitigación:  parámetro del driver + validación de formato
test bueno:  email normal devuelve un usuario
test malo:   input raro no cambia la estructura de la query