GromHacks Labs – Les listes de payloads qu'ils ne veulent pas que vous ayez. 1 324 sondes d'injection envoyées depuis le vaisseau mère pour détecter ce qui est injectable dans 20 classes de vuln. Nous n'exploitons pas, nous frappons juste à la porte et voyons qui répond. Chaque payload testé contre de vrais parseurs car les extraterrestres exigent des preuves. Ne faites confiance à aucune entrée. Remettez tout en question !
Vous avez trouvé un payload qui ne fonctionne pas ? Veuillez ouvrir un ticket avec le payload, le contexte cible et ce que vous attendiez comme résultat. Les pull requests avec des correctifs ou de nouveaux payloads sont toujours les bienvenues.
La recherche est en cours. Ce projet est en développement actif et sera mis à jour avec de nouveaux contextes d'injection, payloads et améliorations de validation.
Avertissement : Ces payloads sont fournis uniquement à des fins de tests de sécurité autorisés, d'éducation et de recherche. Les auteurs n'assument aucune responsabilité ni obligation pour tout usage abusif ou effet en aval. Utilisez-les entièrement à vos propres risques. En utilisant ce projet, vous acceptez l'entière responsabilité de vos actions.
Licence : MIT - voir LICENSE
1 618 chaînes de payload uniques réparties sur 37 catégories de tests de sécurité, plus un ensemble polyglotte transversal, 35 formats de désérialisation nommés, bibliothèques et sinks, et 20 moteurs de templates. Le master préservant le contexte contient 1 760 affectations payload-vers-section sur 661 sections, de sorte qu'une chaîne partagée reste associée à chaque parseur et contexte d'insertion où elle s'applique. La liste minimale de 108 payloads inclut des sondes représentatives pour GraphQL, HQL/JPQL, XPath, JSONPath, la construction JSON, la pollution de paramètres HTTP, XQuery, Firestore, SMTP/IMAP et les en-têtes email, les en-têtes Host, la structure XML/SOAP, LDAP DN, HTML/CSS, CSV, les logs et LaTeX. La couverture de validation varie selon le payload, le parseur et le contexte d'insertion.
La matrice de langages couvre C, C++, C#, Dart, Elixir, Erlang, Go, Java, JavaScript, Kotlin, Lua, Objective-C, Perl, PHP, Python, Ruby, Rust, Scala, Swift et TypeScript.
Le validateur général est un contrôle de fumée, pas une preuve d'exploitation : les résultats antérieurs comptaient les erreurs arbitraires et les timeouts de requête comme des succès. La régression contextuelle couvre neuf dialectes SQL en conditions réelles, incluant les positions chaîne, numérique, clause ORDER BY injectée et expression de tri directe ; GraphQL.js, Hibernate HQL/JPQL, XPath/XQuery/JSONPath directs, la construction JSON et la pollution de paramètres dupliqués, les filtres structurés Firestore, l'injection de commandes SMTP/IMAP et d'en-têtes email, l'empoisonnement d'URL par en-tête Host, la structure XML et SOAP, l'injection de filtre et de DN LDAP, HTML/CSS/XSS dans Chromium, l'évasion de cellule de formule CSV, la falsification de logs, l'injection de source LaTeX, les contextes POSIX shell quote/backtick/pipeline, $() et saut de ligne percent-décodé, les fixtures locales SSRF/path/XXE, MongoDB/CouchDB/Redis/ArangoDB/DynamoDB PartiQL/Cassandra CQL/Couchbase SQL++/Elasticsearch/Neo4j, EL, XSLT, SSI, la pollution de prototype et les callbacks de désérialisation représentatifs. Les vérifications navigateur incluent les contextes de parseur attribut non quoté, fragment d'attribut, commentaire HTML et </script>. La matrice de langages vérifie les mathématiques, les erreurs, le timing, l'OOB et les évasions de quotes dans le code source généré dans les 20 langages demandés ; les contextes courants de quotes alternatives et de chaînes backtick sont testés lorsqu'ils sont supportés, aux côtés d'un polyglotte arithmétique partagé dans les 20 et de chaînes de format d'exécution le cas échéant. Voir COVERAGE.md pour la matrice vérifiée et les lacunes restantes spécifiques aux moteurs.
La plupart des listes de payloads publiquement disponibles sont organisées par type de vulnérabilité : une liste pour l'injection SQL, une autre pour le XSS, une autre pour l'injection de commandes, etc. Un testeur choisit la liste qu'il pense correspondre à la cible, la charge dans un outil d'intrusion et l'exécute contre un paramètre. S'il se trompe sur la classe de vulnérabilité, l'ensemble du scan ne produit rien. Si le backend est une base de données peu commune, un moteur de templates non standard ou un langage que la liste n'a pas pris en compte, les payloads échouent silencieusement. Le testeur passe à autre chose en pensant que le paramètre est propre.
Cette approche présente deux problèmes fondamentaux. Premièrement, elle exige que le testeur sache quelle vulnérabilité existe avant de l'avoir trouvée. Deuxièmement, la plupart des payloads en circulation sont théoriques -- copiés entre projets et articles de blog sans jamais avoir été testés contre un parseur réel. Ils semblent corrects. Ils peuvent même être syntaxiquement valides. Mais ils ne déclenchent pas réellement de réponse détectable de la part de la cible.
Ce projet utilise des polyglottes là où une seule chaîne peut couvrir plusieurs contextes liés. Le comportement d'un payload dépend toujours de la façon dont une application l'insère : un argument shell peut être non quoté, en guillemets simples ou en guillemets doubles ; les expressions SQL chaîne et numérique diffèrent ; les moteurs de templates utilisent des délimiteurs incompatibles. Le banc de test doit modéliser ces wrappers explicitement. Aucune chaîne unique ne doit être supposée s'échapper de chaque quote, commentaire ou parseur.
Les payloads sont regroupés autour de piliers de détection -- des réponses observables qui peuvent fournir des preuves dans un contexte correspondant :
7*191 qui s'évalue à 1337. Si ce nombre apparaît dans la réponse et que le payload n'a envoyé que 7*191 (pas le littéral 1337), le parseur cible a évalué l'expression. Le résultat prouve l'évaluation dans ce sink, qui peut être une requête, un template, un langage d'expression ou un runtime de code.Ces signaux ne sont utiles que lorsqu'ils sont vérifiés dans le contexte réel du payload. Le validateur général est un test de fumée ; une erreur de parseur, un timeout ou une chaîne reflétée seule ne prouve pas qu'un payload s'est exécuté. Utilisez les vérifications Docker spécifiques au contexte pour des preuves plus solides.
Les payloads OOB et timing traditionnels reposent sur des commandes shell : curl, nslookup, ping, sleep. Ceux-ci se cassent constamment. Ils dépendent de l'OS cible, du PATH disponible, du shell qui interprète la commande et de si le processus a la permission de lancer des sous-processus. Un payload OOB basé sur curl qui fonctionne sur Ubuntu échoue sur Alpine (pas de curl), échoue sur Windows (pas de curl) et échoue dans un conteneur restreint (pas d'exécution de processus sortant).