Pruebas de vulnerabilidades de inyección

La inyección ocurre cuando se envían datos no confiables a un intérprete como parte de un comando o una consulta. El intérprete no puede distinguir los datos de los comandos y ejecuta lógica controlada por el atacante. La inyección SQL, de comandos, LDAP, XPath y de plantillas pertenecen a esta clase.

Comience con payloads sencillos para detectar una posible inyección SQL. Una comilla simple provoca un error de sintaxis SQL en las aplicaciones vulnerables. Compruebe los mensajes de error, las diferencias en la longitud de las respuestas y el tiempo de respuesta.

SQLMap automatiza la detección y explotación de la inyección SQL: detecta puntos de inyección, identifica el DBMS y puede volcar bases de datos, leer archivos y lograr la ejecución de código del sistema operativo en sistemas vulnerables.

La inyección de comandos ocurre cuando la entrada del usuario se pasa a funciones del shell del sistema operativo. Pruebe con metacaracteres del shell: punto y coma, tuberías, comillas invertidas y sustitución de comandos mediante $().

La inyección LDAP manipula las consultas LDAP utilizadas para la autenticación y las búsquedas en directorios. Pruebe los campos de autenticación con: *)(uid=*))(|(uid=* para omitir los filtros.

La inyección XPath ataca sistemas de autenticación basados en XML. Es similar a la inyección SQL: los payloads manipulan las consultas XPath; por ejemplo, ' or '1'='1 permite omitir la autenticación.

La inyección de plantillas del lado del servidor ocurre cuando la entrada del usuario se procesa en un motor de plantillas (Jinja2, Twig, Freemarker). Para detectarla, inyecte {{7*7}}; si la respuesta muestra 49, existe SSTI.

Envíe las solicitudes a Repeater e inyecte manualmente payloads en cada parámetro. Use Intruder para automatizar el fuzzing con listas de palabras para inyecciones (SecLists contiene excelentes payloads de inyección).

Cuando no hay una salida visible, use retrasos temporales para confirmar la ejecución, callbacks DNS fuera de banda (Burp Collaborator o interactsh) y respuestas basadas en booleanos (cambios en la longitud del contenido).

Los errores detallados revelan el tipo de base de datos, la estructura de las consultas y las rutas de los archivos, lo que resulta invaluable para crear payloads precisos. Pruebe siempre entradas que activen la depuración o revelen errores, además de los payloads normales.

La inyección se previene mediante consultas parametrizadas (inyección SQL), validación de entradas y escape del shell (inyección de comandos), y evitando procesar la entrada del usuario en plantillas (SSTI). Los desarrolladores deben comprender estas medidas para escribir código seguro.

¿Qué confirma el payload de detección de SSTI {{7*7}} cuando la respuesta muestra 49?

Las vulnerabilidades de inyección se deben a la mezcla de datos y comandos. Pruebe cada entrada controlada por el usuario con payloads de inyección SQL, de comandos, de plantillas y LDAP. Use SQLMap para automatizar la inyección SQL, Burp Repeater para las pruebas manuales y técnicas de retraso temporal o fuera de banda para la explotación ciega. Documente siempre los payloads y las evidencias en el informe.