GromHacks Labs -- Le liste di payload che non vogliono farti avere. 1.324 sonde di iniezione trasmesse dalla nave madre per rilevare cosa è iniettabile in 20 classi di vulnerabilità. Non sfruttiamo, bussiamo solo alla porta e vediamo chi risponde. Ogni payload testato su parser reali perché gli alieni esigono prove. Non fidarti di nessun input. Metti tutto in discussione!
Hai trovato un payload che non funziona? Per favore apri una issue con il payload, il contesto target e cosa ti aspettavi che accadesse. Le pull request con correzioni o nuovi payload sono sempre benvenute.
La ricerca è in corso. Questo progetto è in sviluppo attivo e verrà aggiornato con nuovi contesti di injection, payload e miglioramenti alla validazione.
Disclaimer: Questi payload sono forniti esclusivamente per test di sicurezza autorizzati, scopi educativi e di ricerca. Gli autori non si assumono alcuna responsabilità per qualsiasi uso improprio o effetto derivato. Usa interamente a tuo rischio. Utilizzando questo progetto accetti la piena responsabilità delle tue azioni.
Licenza: MIT - vedi LICENSE
1.618 stringhe di payload uniche distribuite su 37 categorie di security-test più un set polyglot trasversale, 35 formati di deserializzazione denominati, librerie e sink, e 20 template engine. Il master context-preserving contiene 1.760 assegnazioni payload-a-sezione su 661 sezioni, così una stringa condivisa rimane associata a ogni parser e contesto di inserimento in cui si applica. La lista minimale di 108 payload include probe rappresentative per GraphQL, HQL/JPQL, XPath, JSONPath, costruzione JSON, HTTP parameter pollution, XQuery, Firestore, SMTP/IMAP e header email, header Host, struttura XML/SOAP, LDAP DN, HTML/CSS, CSV, log e LaTeX. La copertura di validazione varia in base al payload, al parser e al contesto di inserimento.
La matrice dei linguaggi copre C, C++, C#, Dart, Elixir, Erlang, Go, Java, JavaScript, Kotlin, Lua, Objective-C, Perl, PHP, Python, Ruby, Rust, Scala, Swift e TypeScript.
Il validatore generale è uno smoke check, non una prova di exploitation: i risultati precedenti contavano errori arbitrari e timeout delle richieste come hit. La regressione contestuale copre nove dialetti SQL live, incluse posizioni string, numeriche, clausola ORDER BY iniettata ed espressione di ordinamento diretta; GraphQL.js, Hibernate HQL/JPQL, XPath/XQuery/JSONPath diretti, costruzione JSON e duplicate-parameter pollution, filtri strutturati Firestore, injection di comandi SMTP/IMAP e header email, Host-header URL poisoning, struttura XML e SOAP, injection di filtro e DN LDAP, HTML/CSS/XSS in Chromium, breakout di celle formula CSV, log forging, injection di sorgente LaTeX, quote/backtick/pipeline della shell POSIX, contesti $() e newline percent-decoded, fixture locali SSRF/path/XXE, MongoDB/CouchDB/Redis/ArangoDB/DynamoDB PartiQL/Cassandra CQL/Couchbase SQL++/Elasticsearch/Neo4j, EL, XSLT, SSI, prototype pollution e callback di deserializzazione rappresentativi. I controlli browser includono contesti parser unquoted attribute, attribute-fragment, HTML-comment e </script>. La matrice dei linguaggi verifica math, errori, timing, OOB e breakout di quote nel codice sorgente generato in tutti i 20 linguaggi richiesti; i contesti comuni di stringhe con quote alternative e backtick sono testati dove supportati, insieme a un polyglot aritmetico condiviso in tutti i 20 e format string runtime dove applicabile. Vedi COVERAGE.md per la matrice verificata e le lacune rimanenti specifiche per engine.
La maggior parte delle liste di payload pubblicamente disponibili è organizzata per tipo di vulnerabilità: una lista per SQL injection, un'altra per XSS, un'altra per command injection, e così via. Un tester sceglie la lista che ritiene corrisponda al target, la carica in uno strumento intruder e la esegue contro un parametro. Se sbaglia la classe di vulnerabilità, l'intera scansione non produce nulla. Se il backend è un database poco comune, un template engine non standard o un linguaggio che la lista non considerava, i payload falliscono silenziosamente. Il tester va avanti pensando che il parametro sia pulito.
Questo approccio ha due problemi fondamentali. Primo, richiede al tester di sapere quale vulnerabilità esiste prima di averla trovata. Secondo, la maggior parte dei payload in circolazione è teorica -- copiata tra progetti e post di blog senza essere mai testata contro un parser reale. Sembrano corretti. Potrebbero persino essere sintatticamente validi. Ma non innescano effettivamente una risposta rilevabile dal target.
Questo progetto usa polyglot dove una singola stringa può coprire più contesti correlati. Il comportamento di un payload dipende comunque da come un'applicazione lo inserisce: un argomento shell può essere unquoted, single-quoted o double-quoted; le espressioni SQL string e numeriche differiscono; i template engine usano delimitatori incompatibili. Il testbed deve modellare esplicitamente quei wrapper. Nessuna singola stringa dovrebbe essere presunta in grado di uscire da ogni quote, commento o parser.
I payload sono raggruppati attorno a detection pillar -- risposte osservabili che possono fornire evidenza in un contesto corrispondente:
7*191 che restituisce 1337. Se quel numero appare nella risposta e il payload ha inviato solo 7*191 (non il letterale 1337), il parser target ha valutato l'espressione. Il risultato prova la valutazione in quel sink, che può essere una query, un template, un expression language o un runtime di codice.Questi segnali sono utili solo quando verificati nel contesto effettivo del payload. Il validatore generale è uno smoke test; un errore del parser, un timeout o una stringa riflessa da soli non provano che un payload sia stato eseguito. Usa i controlli Docker specifici per contesto per evidenze più forti.
I payload OOB e timing tradizionali si basano su comandi shell: curl, nslookup, ping, sleep. Questi si rompono costantemente. Dipendono dal sistema operativo target, dal PATH disponibile, da quale shell interpreta il comando e se il processo ha il permesso di generare sottoprocessi. Un payload OOB basato su curl che funziona su Ubuntu fallisce su Alpine (niente curl), fallisce su Windows (niente curl) e fallisce dentro un container ristretto (nessuna esecuzione di processi in uscita).
Questo progetto sostituisce i comandi shell con built-in nativi del linguaggio dove possibile. I payload Python usano urllib.request.urlopen() e time.sleep(). I payload Java usano java.net.URL.openStream() e Thread.sleep(). Ruby usa Net::HTTP.get() e Kernel.sleep(). PHP usa file_get_contents() e sleep(). Queste funzioni provengono dal runtime del linguaggio o dalla libreria standard, quindi evitano la ricerca nel PATH e le dipendenze da sottoprocessi. Policy e configurazione runtime possono comunque disabilitare l'accesso alla rete o singole API; la matrice delle fixture registra l'ambiente esatto che è stato esercitato.