INYECCIÓN SQL EN VIVO
Base de datos de ejemplo (visible solo para que puedas construir logins válidos):
Consulta enviada a la base de datos:
🎬 EJEMPLOS PARA PROBAR
📖 CHULETA RÁPIDA
Qué es exactamente una inyección
El backend construye la consulta pegando trozos de texto: "... WHERE usuario = '" + entrada + "'". Si tu entrada contiene una comilla, dejas de estar "dentro" del valor y empiezas a escribir SQL de verdad.
El comentario no es opcional
' OR '1'='1 a secas casi nunca cuela: en SQL, AND tiene más prioridad que OR, así que la condición de la contraseña sigue aplicando. El -- final es lo que de verdad anula el resto de la consulta — pruébalo con y sin él arriba.
Por qué los parámetros lo arreglan del todo
Con una consulta parametrizada, el motor de base de datos compila la estructura de la consulta antes de saber los valores. Una comilla que llega como parámetro es solo un carácter más del dato — nunca puede convertirse en sintaxis SQL, la escribas como la escribas.
Un error también es una fuga
Una comilla suelta rompe la sintaxis y el motor devuelve un error. En un sistema real mal configurado, ese mensaje de error puede revelar el nombre de las tablas o columnas — por eso nunca se deben mostrar errores de base de datos en crudo al usuario.
Defensa en profundidad
Los parámetros son la solución real, pero conviene sumar: mínimo privilegio (la cuenta de BD de la app no debería poder DROP TABLE), un ORM que parametrice por defecto, y un WAF como red adicional — nunca como sustituto.
Esto no lo cubre todo
Este simulador se centra en el bypass de login clásico (tautología + comentario). Existen otras variantes — inyección UNION para extraer datos de otras tablas, o inyección "ciega" (blind/time-based) cuando no hay ningún mensaje visible — que quedan fuera de este alcance. Sigue siendo la categoría A03 del OWASP Top 10.