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!
Haben Sie einen Payload gefunden, der nicht funktioniert? Bitte eröffnen Sie ein Issue mit dem Payload, dem Zielkontext und dem erwarteten Verhalten. Pull-Requests mit Korrekturen oder neuen Payloads sind immer willkommen.
Die Forschung läuft weiter. Dieses Projekt befindet sich in aktiver Entwicklung und wird regelmäßig mit neuen Payloads, Schwachstellenklassen und Validierungsverbesserungen aktualisiert.
Haftungsausschluss: Diese Payloads sind ausschließlich für autorisierte Sicherheitstests, Schulungen und Forschungszwecke vorgesehen. Die Autoren übernehmen keinerlei Verantwortung oder Haftung für Missbrauch oder daraus resultierende Folgen. Die Nutzung erfolgt vollständig auf eigenes Risiko. Mit der Nutzung dieses Projekts übernehmen Sie die volle Verantwortung für Ihr Handeln.
Lizenz: MIT – siehe LICENSE
1.353 validierte Injektions-Payloads, die 20 Schwachstellenklassen, 31 Deserialisierungs-Frameworks und 14 Template-Engines abdecken. Jeder Payload erzeugt ein detektierbares Signal. Null theoretische Payloads.
Validierung: 1.353 getestet / 1.353 feuern / 0 Fehlschläge / 0 übersprungen gegen 35 Docker-Testumgebungen. Strikte Validierung beweist tatsächliche Ausnutzung (serverseitige Berechnung, echte Parserfehler, gemessene Zeitverzögerungen, OOB-Callbacks von Zielcontainern) – kein Zeichenkettenabgleich.
Die meisten öffentlich verfügbaren Payload-Listen sind nach Schwachstellentyp organisiert: eine Liste für SQL-Injektion, eine andere für XSS, eine weitere für Befehlsinjektion 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 in der Liste nicht berücksichtigt wurde, schlagen die Payloads stillschweigend fehl. Der Tester geht weiter und hält den Parameter für sauber.
Dieser Ansatz hat zwei grundlegende Probleme. Erstens erfordert er, dass der Tester weiß, welche Schwachstelle existiert, bevor er sie gefunden hat. Zweitens sind die meisten in Umlauf befindlichen Payloads theoretisch – sie werden zwischen Projekten und Blogbeiträgen kopiert, ohne jemals gegen einen echten Parser getestet zu werden. Sie sehen richtig aus. Sie könnten sogar syntaktisch gültig sein. Aber sie lösen tatsächlich keine detektierbare Antwort des Ziels aus.
Dieses Projekt verfolgt einen anderen Ansatz. Die primäre Arbeitseinheit ist der Polyglot – eine einzelne Payload-Zeichenfolge, die so konstruiert ist, dass sie in möglichst vielen Injektionskontexten gleichzeitig gültig (oder bedeutungsvoll ungültig) ist. Ein einziger Polyglot bricht aus einfachen Anführungszeichen, doppelten Anführungszeichen, Klammern, Blockkommentaren, HTML-Attributen, Template-Begrenzern und Backtick-Kontexten gleichzeitig aus. Anstatt zu wissen, was die Schwachstelle ist, schießt der Tester Polyglots auf jeden Parameter und beobachtet die Signale.
Jeder Payload in dieser Sammlung basiert auf Erkennungssäulen – beobachtbaren Antworten, die bestätigen, dass eine Schwachstelle existiert, ohne dass Zugriff auf Serverlogs, Quellcode oder das Dateisystem erforderlich ist:
7*191, der zu 1337 ausgewertet wird. Wenn diese Zahl in der Antwort erscheint und der Payload nur 7*191 (nicht den Literal 1337) gesendet hat, hat das Backend den Ausdruck berechnet – ein Beweis für Codeausführung.Wenn ein Payload mindestens eines dieser Signale im Test gegen seinen Zielkontext nicht erzeugt, gehört er nicht in die Liste. Jeder der 1.353 Payloads hier wurde gegen eigens erstellte Docker-Testumgebungen mit strengem Nachweis der Ausnutzung validiert. Keiner ist theoretisch.
Traditionelle OOB- und Timing-Payloads verlassen sich auf Shell-Befehle: curl, nslookup, ping, sleep. Diese versagen 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 zum Erstellen von Unterprozessen hat. Ein curl-basierter OOB-Payload, der auf Ubuntu funktioniert, schlägt auf Alpine (kein curl), auf Windows (kein curl) und innerhalb eines eingeschränkten Containers (keine ausgehende Prozessausführung) fehl.
Dieses Projekt ersetzt Shell-Befehle nach Möglichkeit durch sprachspezifische Built-ins. Python-Payloads verwenden urllib.request.urlopen() und time.sleep(). Java-Payloads verwenden java.net.URL.openStream() und Thread.sleep(). Ruby verwendet Net::HTTP.get() und Kernel.sleep. PHP verwendet file_get_contents() und sleep(). Diese Funktionen sind in jeder Standardinstallation ihrer jeweiligen Sprache vorhanden – kein PATH-Lookup, kein Unterprozess, keine Betriebssystemabhängigkeit.
Wo selbst Standardbibliotheksimporte blockiert sein könnten (Sandbox-Eval, eingeschränktes Exec), greifen die Payloads auf import-freie Alternativen zurück: CPU-Spin-Loops für Timing (sum(range(500000000)) in Python, Atomics.wait() in Node) und direkte Socket-Verbindungen für OOB (__import__('socket').create_connection(), fsockopen(), TCPSocket.new()).
Nicht alles kann ein Polyglot sein. Template-Engines verwenden grundlegend inkompatible Syntax – {{}} in Jinja2 bedeutet nichts für ERBs <%= %>, und beides wird nicht als Freemarker-${} geparst). Deserialisierungsformate sind binär oder strukturierte Daten, die für ein bestimmtes Framework spezifisch sind. Für diese Kategorien verwendet das Projekt pro-Engine-Payloads, die unter demselben Erkennungssäulen-System organisiert sind und 14 Template-Engines und 31 Deserialisierungs-Frameworks in 7 Sprachen abdecken.
Das Ergebnis ist ein einzelnes Korpus, in dem Polyglots die Kontexte abdecken, die sie können (SQLi, OS-Befehlsinjektion, XSS, Code-Injektion), und speziell entwickelte pro-Engine-Payloads den Rest, alle validiert, alle erzeugen detektierbare Signale, alle bereit für zeilenweise Injektionswerkzeuge.
83 Payloads decken alle 35 Testumgebungen, alle 55+ Endpunkte und alle 4 Erkennungssäulen pro Kategorie ab. Validierung: 83 FEUERN / 0 NICHT-FEUERN / 0 ÜBERSPRUNGEN.
Jede Injektionskategorie erhält, wo architektonisch möglich, Fehler- + Mathe- + Timing- + OOB-Abdeckung. Deserialisierungs-Frameworks, die Codeausführung unterstützen (Pickle, PyYAML, jsonpickle, node-serialize, XMLDecoder, .NET Json.NET), erhalten vollständige Multi-Säulen-Abdeckung. Frameworks, die auf Sondierung beschränkt sind (PHP unserialize, Ruby Marshal, SnakeYAML usw.), erhalten fehlerbasierte Erkennung. Feuern Sie diese Liste auf jeden Parameter, bevor Sie für die Tiefe zu den vollständigen Kategorielisten übergehen.