GromHacks Labs — Las listas de payloads que no quieren que tengas. 1,324 sondas de inyección enviadas desde la nave nodriza para detectar qué es inyectable a través de 20 clases de vulnerabilidades. No explotamos, solo tocamos la puerta y vemos quién responde. Cada payload probado contra analizadores reales porque los aliens exigen pruebas. No confíes en ninguna entrada. ¡Cuestiona todo!
¿Encontraste un payload que no funciona? Por favor abre un issue con el payload, el contexto objetivo y lo que esperabas que sucediera. Los pull requests con correcciones o nuevos payloads son siempre bienvenidos.
La investigación está en curso. Este proyecto está en desarrollo activo y se actualizará con nuevos contextos de inyección, payloads y mejoras de validación.
Aviso legal: Estos payloads se proporcionan únicamente con fines de pruebas de seguridad autorizadas, educación e investigación. Los autores no asumen ninguna responsabilidad ni obligación por cualquier uso indebido o efectos derivados. Úsalos enteramente bajo tu propio riesgo. Al usar este proyecto aceptas plena responsabilidad por tus acciones.
Licencia: MIT - consulta LICENSE
1.618 cadenas de payload únicas en 37 categorías de pruebas de seguridad más un conjunto poliglota transversal, 35 formatos de deserialización nombrados, bibliotecas y sinks, y 20 motores de plantillas. El maestro con preservación de contexto contiene 1.760 asignaciones de payload a sección en 661 secciones, de modo que una cadena compartida permanece asociada con cada parser y contexto de inserción donde aplica. La lista mínima de 108 payloads incluye sondas representativas para GraphQL, HQL/JPQL, XPath, JSONPath, construcción de JSON, contaminación de parámetros HTTP, XQuery, Firestore, SMTP/IMAP y cabeceras de correo, cabeceras Host, estructura XML/SOAP, LDAP DN, HTML/CSS, CSV, logs y LaTeX. La cobertura de validación varía según el payload, el parser y el contexto de inserción.
La matriz de lenguajes cubre C, C++, C#, Dart, Elixir, Erlang, Go, Java, JavaScript, Kotlin, Lua, Objective-C, Perl, PHP, Python, Ruby, Rust, Scala, Swift y TypeScript.
El validador general es una comprobación superficial, no una prueba de explotación: los resultados anteriores contaban errores arbitrarios y tiempos de espera de solicitudes como aciertos. La regresión de contexto cubre nueve dialectos SQL en vivo, incluyendo posiciones de cadena, numéricas, cláusula ORDER BY inyectada y expresión de ordenamiento directa; GraphQL.js, Hibernate HQL/JPQL, XPath/XQuery/JSONPath directos, construcción de JSON y contaminación por parámetros duplicados, filtros estructurados de Firestore, inyección de comandos SMTP/IMAP y cabeceras de correo, envenenamiento de URL mediante cabecera Host, estructura XML y SOAP, inyección de filtro y DN en LDAP, HTML/CSS/XSS en Chromium, escape de celda de fórmula CSV, falsificación de logs, inyección de código fuente LaTeX, comillas/backticks/pipelines de shell POSIX, contextos de $() y saltos de línea decodificados por porcentaje, fixtures locales de SSRF/path/XXE, MongoDB/CouchDB/Redis/ArangoDB/DynamoDB PartiQL/Cassandra CQL/Couchbase SQL++/Elasticsearch/Neo4j, EL, XSLT, SSI, contaminación de prototipos y callbacks de deserialización representativos. Las comprobaciones de navegador incluyen contextos de parser de atributo sin comillas, fragmento de atributo, comentario HTML y </script>. La matriz de lenguajes comprueba matemáticas, errores, temporización, OOB y escapes de comillas en código fuente generado en los 20 lenguajes solicitados; se prueban contextos comunes de comillas alternativas y backticks donde están soportados, junto con un poliglota aritmético compartido en los 20 y cadenas de formato en tiempo de ejecución donde aplica. Consulta COVERAGE.md para la matriz verificada y las brechas restantes específicas de cada motor.
La mayoría de las listas de payloads disponibles públicamente están organizadas por tipo de vulnerabilidad: una lista para inyección SQL, otra para XSS, otra para inyección de comandos, y así sucesivamente. Un tester elige la lista que cree que coincide con el objetivo, la carga en una herramienta de intrusión y la ejecuta contra un parámetro. Si se equivoca sobre la clase de vulnerabilidad, todo el escaneo no produce nada. Si el backend es una base de datos poco común, un motor de plantillas no estándar o un lenguaje que la lista no contemplaba, los payloads fallan silenciosamente. El tester continúa pensando que el parámetro está limpio.
Este enfoque tiene dos problemas fundamentales. Primero, requiere que el tester sepa qué vulnerabilidad existe antes de haberla encontrado. Segundo, la mayoría de los payloads en circulación son teóricos -- copiados entre proyectos y publicaciones de blogs sin haber sido probados nunca contra un parser real. Parecen correctos. Puede que incluso sean sintácticamente válidos. Pero en realidad no desencadenan una respuesta detectable del objetivo.
Este proyecto usa poliglotas donde una sola cadena puede cubrir múltiples contextos relacionados. El comportamiento de un payload aún depende de cómo lo inserte una aplicación: un argumento de shell puede estar sin comillas, entre comillas simples o entre comillas dobles; las expresiones de cadena y numéricas de SQL difieren; los motores de plantillas usan delimitadores incompatibles. El banco de pruebas necesita modelar esos envoltorios explícitamente. No debe asumirse que una sola cadena rompe todas las comillas, comentarios o parsers.
Los payloads se agrupan en torno a pilares de detección -- respuestas observables que pueden aportar evidencia en un contexto coincidente:
7*191 que evalúa a 1337. Si ese número aparece en la respuesta y el payload solo envió 7*191 (no el literal 1337), el parser objetivo evaluó la expresión. El resultado prueba la evaluación en ese sink, que puede ser una consulta, plantilla, lenguaje de expresión o runtime de código.Estas señales solo son útiles cuando se comprueban en el contexto real del payload. El validador general es una prueba superficial; un error de parser, un tiempo de espera o una cadena reflejada por sí solos no prueban que un payload se ejecutó. Usa las comprobaciones Docker específicas de contexto para obtener evidencia más sólida.
Los payloads OOB y de temporización tradicionales dependen de comandos de shell: curl, nslookup, ping, sleep. Estos se rompen constantemente. Dependen del sistema operativo objetivo, del PATH disponible, de qué shell interpreta el comando y de si el proceso tiene permiso para generar subprocesos. Un payload OOB basado en curl que funciona en Ubuntu falla en Alpine (no hay curl), falla en Windows (no hay curl) y falla dentro de un contenedor restringido (sin ejecución de procesos salientes).