GromHacks Labs — As listas de payloads que eles não querem que você tenha. 1.324 sondas de injeção enviadas da nave-mãe para detectar o que é injetável em 20 classes de vulnerabilidade. Nós não exploramos, apenas batemos na porta e vemos quem atende. Cada payload testado contra parsers reais porque os alienígenas exigem provas. Não confie em nenhuma entrada. Questione tudo!
Encontrou um payload que não funciona? Por favor, abra uma issue com o payload, o contexto alvo e o que você esperava que acontecesse. Pull requests com correções ou novos payloads são sempre bem-vindos.
A pesquisa está em andamento. Este projeto está em desenvolvimento ativo e será atualizado com novos contextos de injeção, payloads e melhorias de validação.
Aviso legal: Estes payloads são fornecidos apenas para testes de segurança autorizados, educação e fins de pesquisa. Os autores não assumem qualquer responsabilidade por qualquer uso indevido ou efeitos posteriores. Use inteiramente por sua conta e risco. Ao usar este projeto, você aceita total responsabilidade por suas ações.
Licença: MIT - consulte LICENSE
1.618 strings de payload únicas em 37 categorias de testes de segurança, além de um conjunto poliglota transversal, 35 formatos nomeados de desserialização, bibliotecas e sinks, e 20 mecanismos de template. O mestre com preservação de contexto contém 1.760 atribuições de payload para seção em 661 seções, de modo que uma string compartilhada permanece associada a cada parser e contexto de inserção onde se aplica. A lista mínima de 108 payloads inclui sondagens representativas para GraphQL, HQL/JPQL, XPath, JSONPath, construção de JSON, poluição de parâmetros HTTP, XQuery, Firestore, SMTP/IMAP e cabeçalhos de e-mail, cabeçalhos Host, estrutura XML/SOAP, LDAP DN, HTML/CSS, CSV, logs e LaTeX. A cobertura de validação varia conforme o payload, o parser e o contexto de inserção.
A matriz de linguagens cobre C, C++, C#, Dart, Elixir, Erlang, Go, Java, JavaScript, Kotlin, Lua, Objective-C, Perl, PHP, Python, Ruby, Rust, Scala, Swift e TypeScript.
O validador geral é uma verificação superficial, não uma prova de exploração: resultados anteriores contavam erros arbitrários e timeouts de requisição como acertos. A regressão de contexto cobre nove dialetos SQL ativos, incluindo posições de string, numéricas, cláusula ORDER BY injetada e expressão de ordenação direta; GraphQL.js, Hibernate HQL/JPQL, XPath/XQuery/JSONPath diretos, construção de JSON e poluição de parâmetros duplicados, filtros estruturados do Firestore, injeção de comando SMTP/IMAP e cabeçalho de e-mail, envenenamento de URL via cabeçalho Host, estrutura XML e SOAP, injeção de filtro e DN LDAP, HTML/CSS/XSS no Chromium, breakout de célula de fórmula CSV, forjamento de log, injeção de código-fonte LaTeX, aspas/backtick/pipeline do shell POSIX, contextos de $() e nova linha com decodificação percentual, fixtures locais de SSRF/path/XXE, MongoDB/CouchDB/Redis/ArangoDB/DynamoDB PartiQL/Cassandra CQL/Couchbase SQL++/Elasticsearch/Neo4j, EL, XSLT, SSI, poluição de protótipo e callbacks representativos de desserialização. As verificações de navegador incluem contextos de parser de atributo sem aspas, fragmento de atributo, comentário HTML e </script>. A matriz de linguagens verifica matemática, erros, timing, OOB e breakouts de aspas em código-fonte gerado nas 20 linguagens solicitadas; contextos comuns de aspas alternativas e backtick são testados onde houver suporte, juntamente com um poliglota aritmético compartilhado nas 20 e format strings de runtime onde aplicável. Consulte COVERAGE.md para a matriz verificada e as lacunas restantes específicas de cada mecanismo.
A maioria das listas de payloads disponíveis publicamente é organizada por tipo de vulnerabilidade: uma lista para injeção SQL, outra para XSS, outra para injeção de comando, e assim por diante. O testador escolhe a lista que acredita corresponder ao alvo, carrega-a em uma ferramenta de intrusão e a executa contra um parâmetro. Se ele errar a classe de vulnerabilidade, toda a varredura não produz nada. Se o backend for um banco de dados incomum, um mecanismo de template não padrão ou uma linguagem que a lista não considerou, os payloads falham silenciosamente. O testador segue em frente pensando que o parâmetro está limpo.
Essa abordagem tem dois problemas fundamentais. Primeiro, exige que o testador saiba qual vulnerabilidade existe antes de tê-la encontrado. Segundo, a maioria dos payloads em circulação é teórica -- copiada entre projetos e posts de blog sem nunca ter sido testada contra um parser real. Eles parecem corretos. Podem até ser sintaticamente válidos. Mas não disparam de fato uma resposta detectável do alvo.
Este projeto usa poliglotas onde uma única string pode cobrir múltiplos contextos relacionados. O comportamento de um payload ainda depende de como uma aplicação o insere: um argumento de shell pode estar sem aspas, entre aspas simples ou entre aspas duplas; expressões SQL de string e numéricas diferem; mecanismos de template usam delimitadores incompatíveis. O testbed precisa modelar esses wrappers explicitamente. Nenhuma string única deve ser presumida como capaz de escapar de toda aspa, comentário ou parser.
Os payloads são agrupados em torno de pilares de detecção -- respostas observáveis que podem fornecer evidência em um contexto correspondente:
7*191 que resulta em 1337. Se esse número aparecer na resposta e o payload tiver enviado apenas 7*191 (não o literal 1337), o parser alvo avaliou a expressão. O resultado prova a avaliação naquele sink, que pode ser uma query, template, expression language ou runtime de código.Esses sinais só são úteis quando verificados no contexto real do payload. O validador geral é um teste superficial; um erro de parser, timeout ou string refletida sozinho não prova que um payload foi executado. Use as verificações Docker específicas de contexto para evidências mais fortes.
Payloads tradicionais de OOB e timing dependem de comandos de shell: curl, nslookup, ping, sleep. Eles quebram constantemente. Dependem do SO alvo, do PATH disponível, de qual shell interpreta o comando e se o processo tem permissão para gerar subprocessos. Um payload OOB baseado em curl que funciona no Ubuntu falha no Alpine (sem curl), falha no Windows (sem curl) e falha dentro de um contêiner restrito (sem execução de processo de saída).
Este projeto substitui comandos de shell por built-ins nativos da linguagem sempre que possível. Payloads Python usam urllib.request.urlopen() e time.sleep(). Payloads Java usam java.net.URL.openStream() e Thread.sleep(). Ruby usa Net::HTTP.get() e Kernel.sleep(). PHP usa file_get_contents() e sleep(). Essas funções vêm do runtime da linguagem ou da biblioteca padrão, então evitam a busca no PATH e dependências de subprocessos. Políticas de runtime e configuração ainda podem desabilitar acesso à rede ou APIs individuais; a matriz de fixtures registra o ambiente exato que foi exercitado.