gromhacks/payload-and-polyglot-listsGromHacks Labs -- Die Payload-Listen, die sie dir nicht geben wollen. 1.324 Injektionssonden, die vom Mutterschiff herabgestrahlt werden, um zu erkennen, was über 20 Schwachstellenklassen hinweg injizierbar ist. Wir nutzen nichts aus, wir klopfen nur an die Tür und schauen, wer antwortet. Jede Payload wird an echten Parsern getestet, weil die Aliens Beweise fordern. Vertraue keiner Eingabe. Stelle alles in Frage!
Einen Payload gefunden, der nicht funktioniert? Bitte öffne ein Issue mit dem Payload, dem Zielkontext und dem, was du erwartet hast. Pull Requests mit Korrekturen oder neuen Payloads sind immer willkommen.
Die Recherche läuft weiter. Dieses Projekt befindet sich in aktiver Entwicklung und wird mit neuen Injektionskontexten, Payloads und Validierungsverbesserungen aktualisiert.
Haftungsausschluss: Diese Payloads werden ausschließlich für autorisierte Sicherheitstests, Schulungs- und Forschungszwecke bereitgestellt. Die Autoren übernehmen keine Verantwortung oder Haftung für jeglichen Missbrauch oder daraus resultierende Folgen. Die Nutzung erfolgt vollständig auf eigenes Risiko. Durch die Nutzung dieses Projekts übernimmst du die volle Verantwortung für deine Handlungen.
Lizenz: MIT - siehe LICENSE
1.618 eindeutige Payload-Strings über 37 Kategorien für Sicherheitstests sowie ein übergreifendes Polyglot-Set, 35 benannte Deserialisierungsformate, Bibliotheken und Sinks und 20 Template-Engines. Der kontexterhaltende Master enthält 1.760 Payload-zu-Abschnitt-Zuordnungen über 661 Abschnitte, sodass ein gemeinsamer String jedem Parser und Einfügekontext zugeordnet bleibt, in dem er zutrifft. Die minimale Liste mit 108 Payloads enthält repräsentative Sonden für GraphQL, HQL/JPQL, XPath, JSONPath, JSON-Konstruktion, HTTP-Parameter-Pollution, XQuery, Firestore, SMTP/IMAP und E-Mail-Header, Host-Header, XML/SOAP-Struktur, LDAP-DN, HTML/CSS, CSV, Logs und LaTeX. Die Validierungsabdeckung variiert je nach Payload, Parser und Einfügekontext.
Die Sprachmatrix deckt C, C++, C#, Dart, Elixir, Erlang, Go, Java, JavaScript, Kotlin, Lua, Objective-C, Perl, PHP, Python, Ruby, Rust, Scala, Swift und TypeScript ab.
Der allgemeine Validator ist ein Smoke-Check, kein Beweis für eine Ausnutzung: Frühere Ergebnisse zählten beliebige Fehler und Request-Timeouts als Treffer. Die Kontext-Regression deckt neun Live-SQL-Dialekte ab, einschließlich String-, Numerik-, injizierter ORDER BY-Klausel- und direkter Sort-Expression-Positionen; GraphQL.js, Hibernate HQL/JPQL, direktes XPath/XQuery/JSONPath, JSON-Konstruktion und Duplicate-Parameter-Pollution, Firestore-strukturierte Filter, SMTP/IMAP-Kommando- und E-Mail-Header-Injektion, Host-Header-URL-Poisoning, XML- und SOAP-Struktur, LDAP-Filter- und DN-Injektion, HTML/CSS/XSS in Chromium, CSV-Formelzellen-Ausbruch, Log-Forging, LaTeX-Quellcode-Injektion, POSIX-Shell-Quote/Backtick/Pipeline, $()- und prozent-dekodierte Newline-Kontexte, lokale SSRF/Path/XXE-Fixtures, MongoDB/CouchDB/Redis/ArangoDB/DynamoDB PartiQL/Cassandra CQL/Couchbase SQL++/Elasticsearch/Neo4j, EL, XSLT, SSI, Prototype Pollution und repräsentative Deserialisierungs-Callbacks. Browser-Checks umfassen unquoted Attribute-, Attribute-Fragment-, HTML-Kommentar- und </script>-Parser-Kontexte. Die Sprachmatrix prüft Math, Errors, Timing, OOB und generierte Source-Quote-Ausbrüche in allen 20 angeforderten Sprachen; gängige alternative Quote- und Backtick-String-Kontexte werden getestet, wo unterstützt, zusammen mit einem gemeinsamen arithmetischen Polyglot in allen 20 und Runtime-Format-Strings, wo anwendbar. Siehe COVERAGE.md für die verifizierte Matrix und verbleibende engine-spezifische Lücken.
Die meisten öffentlich verfügbaren Payload-Listen sind nach Schwachstellentyp organisiert: eine Liste für SQL-Injection, eine andere für XSS, eine weitere für Command Injection und so weiter. Ein Tester wählt die Liste aus, von der er glaubt, dass sie zum Ziel passt, lädt sie in ein Intruder-Tool und führt sie gegen einen Parameter aus. Wenn er sich bei der Schwachstellenklasse irrt, liefert der gesamte Scan nichts. Wenn das Backend eine ungewöhnliche Datenbank, eine nicht standardmäßige Template-Engine oder eine Sprache ist, die die Liste nicht berücksichtigt hat, schlagen die Payloads stillschweigend fehl. Der Tester macht weiter in der Annahme, der Parameter sei sauber.
Dieser Ansatz hat zwei grundlegende Probleme. Erstens muss der Tester wissen, welche Schwachstelle existiert, bevor er sie gefunden hat. Zweitens sind die meisten im Umlauf befindlichen Payloads theoretisch -- zwischen Projekten und Blogbeiträgen kopiert, ohne jemals gegen einen echten Parser getestet worden zu sein. Sie sehen richtig aus. Sie sind vielleicht sogar syntaktisch gültig. Aber sie lösen tatsächlich keine erkennbare Reaktion des Ziels aus.
Dieses Projekt verwendet Polyglots, bei denen ein String mehrere verwandte Kontexte abdecken kann. Das Verhalten eines Payloads hängt jedoch weiterhin davon ab, wie eine Anwendung ihn einfügt: Ein Shell-Argument kann unquoted, single-quoted oder double-quoted sein; SQL-String- und Numerik-Ausdrücke unterscheiden sich; Template-Engines verwenden inkompatible Delimiter. Das Testbed muss diese Wrapper explizit modellieren. Es sollte nicht angenommen werden, dass ein einzelner String aus jedem Quote, Kommentar oder Parser ausbricht.
Payloads sind um Erkennungssäulen gruppiert -- beobachtbare Reaktionen, die in einem passenden Kontext Beweise liefern können:
7*191, der zu 1337 ausgewertet wird. Wenn diese Zahl in der Antwort erscheint und der Payload nur 7*191 gesendet hat (nicht das Literal 1337), hat der Zielparser den Ausdruck ausgewertet. Das Ergebnis beweist die Auswertung in diesem Sink, der eine Query, ein Template, eine Expression Language oder eine Code-Runtime sein kann.Diese Signale sind nur nützlich, wenn sie im tatsächlichen Kontext des Payloads geprüft werden. Der allgemeine Validator ist ein Smoke-Test; ein Parser-Fehler, Timeout oder reflektierter String allein beweist nicht, dass ein Payload ausgeführt wurde. Verwende die kontextspezifischen Docker-Checks für stärkere Beweise.
Traditionelle OOB- und Timing-Payloads verlassen sich auf Shell-Befehle: curl, nslookup, ping, sleep. Diese brechen ständig. Sie hängen vom Zielbetriebssystem, dem verfügbaren PATH, der Shell, die den Befehl interpretiert, und davon ab, ob der Prozess die Berechtigung hat, Subprozesse zu starten. Ein curl-basierter OOB-Payload, der auf Ubuntu funktioniert, schlägt auf Alpine fehl (kein curl), schlägt auf Windows fehl (kein curl) und schlägt in einem eingeschränkten Container fehl (keine ausgehende Prozessausführung).