Escreva uma verificação portátil de diagnóstico com Nuclei

Introdução

Um scanner que verifica apenas o status encontrou tanto uma resposta real de diagnóstico quanto um exemplo de documentação. Agora, crie uma verificação que responda à pergunta pretendida: uma requisição não autenticada recebeu o objeto de diagnóstico interno real desta aplicação?

Você criará um template YAML nativo do Nuclei, testará suas condições de resposta e fará a varredura de seis sites aprovados da Fieldwork Studio. Seu template reutilizável e seus achados reais serão a entrega. O ambiente é independente do laboratório anterior; nenhum arquivo ou processo é transferido.

Conclua primeiro Confirme a exposição de diagnóstico com respostas reais ou esteja à vontade para ler status HTTP, cabeçalhos de tipo de conteúdo, um pequeno objeto JSON e achados JSONL do Nuclei. Este laboratório explica seu YAML e suas expressões de correspondência. Toda a configuração dos alvos é sintética. Use apenas o escopo de leitura fornecido, preserve as páginas públicas e as programações das oficinas e reserve cerca de 65 minutos, incluindo leitura e erros comuns; esta é uma estimativa do autor.

Estabeleça o contrato de resposta da verificação

Nesta etapa, você estabelecerá o serviço normal e a pergunta exata que seu template deve responder. Abra Workshops, navegue pelas sessões e use Get the workshop schedule para baixar o arquivo real fieldwork-schedule.csv. Printmaking e Bookbinding devem permanecer disponíveis durante toda a avaliação.

Os dois cartões das oficinas mostram o serviço público que você deve preservar. O link verde Get the workshop schedule baixa a programação real.

Mude para Auditor. Ele entra no contêiner de auditoria Kali em /home/labex/project. Leia o escopo e as URLs base aprovadas:

cat scope.txt

cat targets.txt

Os seis sites são studio, archive, manual, garden, status e members, sob http://workshop.test:8080/. Teste somente essas URLs, usando requisições HTTP GET de leitura. Não modifique os sites-alvo nem os arquivos de escopo fornecidos.

Reveja uma resposta real de diagnóstico. Como antes, curl -i inclui os cabeçalhos da resposta:

curl -i http://workshop.test:8080/studio/maintenance/diagnostics

Um achado deve combinar HTTP 200, um tipo de conteúdo JSON e o objeto de diagnóstico interno no nível superior da aplicação. Seus quatro campos escalares identificam o serviço e a visibilidade, um caminho absoluto de arquivo de banco de dados e uma contagem inteira não negativa de requisições, sem aspas. O caminho do arquivo e a contagem podem mudar. A ordem das chaves e os espaços em branco não afetam o significado. Um exemplo aninhado de documentação não é o objeto real.

Sua verificação se destina ao formato de resposta declarado desta pequena aplicação. Ela não comprova que qualquer endpoint JSON seja vulnerável nem que um site não tenha outros problemas. Em particular, uma página pública, um resumo JSON público, uma resposta de integridade, uma recusa HTTP ou um redirecionamento para login não são a evidência de exposição exigida.

Se seu diretório mudar, use pwd para inspecioná-lo e cd /home/labex/project para voltar antes de ler ou criar nomes de arquivo relativos. Mantenha seu trabalho ao reconectar; abrir um terminal não reconstrói o cenário.

Crie os matchers nativos de resposta

Nesta etapa, você escreverá um template reutilizável em vez de depender de uma correspondência com HTTP 200. Permaneça em Auditor.

Um template do Nuclei tem um id, informações descritivas em info e uma seção de protocolo como http. A indentação agrupa campos YAML aninhados, enquanto um hífen inicia um item de lista. Use espaços, não tabulações. method: GET seleciona uma requisição de leitura. {{BaseURL}} vem do alvo passado ao Nuclei, de modo que o template não incorpora um nome de host, porta ou prefixo de site específico. redirects: false mantém um redirecionamento para login visível como redirecionamento.

Um matcher é uma condição aplicada a uma resposta. Este template exige os três grupos de matchers:

matchers-condition: and combina esses grupos. Sem isso, a relação OR padrão poderia fazer HTTP 200 sozinho produzir um achado novamente. Dentro do matcher DSL, condition: and também exige todas as expressões de corpo listadas.

DSL significa linguagem de domínio específico: aqui, expressões curtas que inspecionam uma resposta. body é o texto da resposta. json_minify(body) analisa e compacta JSON válido, removendo espaços em branco sem significado sem depender da ordem das chaves. contains(text, fragment) procura um fragmento literal. Normalizar primeiro permite que um campo escrito como "visibility" : "internal" corresponda à mesma condição que "visibility":"internal".

regex(pattern, text) aplica uma expressão regular. As expressões abaixo usam um pequeno conjunto de símbolos:

• /[A-Za-z0-9._/-]+ exige uma barra inicial seguida de um ou mais caracteres de caminho: letras, dígitos, pontos, sublinhados, barras ou hífens. Aceita caminhos absolutos alterados, incluindo letras maiúsculas.
• [0-9]+[,}] exige dígitos seguidos imediatamente por uma vírgula ou chave de fechamento. Isso evita tratar uma contagem entre aspas, um valor negativo ou o início de um decimal como a contagem inteira.
• ^\{[^{}]*\}$ exige um par externo de chaves e nenhuma chave aninhada, correspondendo ao formato de diagnóstico plano de quatro campos deste curso, em vez de um objeto dentro de um exemplo de documentação.

A expressão do cabeçalho usa (?im) para correspondência por linha sem distinguir maiúsculas de minúsculas; \s* permite espaços em branco. Seu grupo opcional (?: ... )? aceita parâmetros como ; charset=utf-8. Você pode copiar essa expressão como uma verificação completa de tipo de conteúdo JSON; não precisa construir um analisador MIME genérico.

No YAML abaixo, >- introduz um valor textual na linha indentada seguinte. Isso preserva as aspas e barras invertidas da expressão sem escapes adicionais de aspas no YAML. As aspas simples dentro de cada expressão delimitam texto literal; as aspas duplas dentro desse texto são a pontuação dos campos JSON que deve corresponder.

Crie diagnostics.yaml. Como no laboratório anterior, > substitui este arquivo e o delimitador do here-document entre aspas copia o bloco literalmente. O YAML final deve ficar sozinho em sua linha.

cat > diagnostics.yaml <<'YAML'
id: workshop-diagnostics-exposed
info:
  name: Public workshop diagnostics
  author: labex
  severity: medium
http:
  - method: GET
    path:
      - "{{BaseURL}}/maintenance/diagnostics"
    redirects: false
    matchers-condition: and
    matchers:
      - type: status
        status: [200]
      - type: regex
        part: header
        regex:
          - '(?im)^content-type:\s*application/json(?:\s*;[^\r\n]*)?\s*$'
      - type: dsl
        condition: and
        dsl:
          - >-
            contains(json_minify(body), '"service":"workshop-portal"')
          - >-
            contains(json_minify(body), '"visibility":"internal"')
          - >-
            regex('"database_file":"/[A-Za-z0-9._/-]+"', json_minify(body))
          - >-
            regex('"request_count":[0-9]+[,}]', json_minify(body))
          - >-
            regex('^\{[^{}]*\}$', json_minify(body))
YAML

Peça ao mecanismo real que valide o template. -validate verifica a sintaxe do template do Nuclei; não comprova um comportamento de detecção correto. -t seleciona seu arquivo, -duc desativa verificações de atualização, -ni desativa callbacks externos do Interactsh e -nc remove códigos de cor do terminal.

nuclei -t diagnostics.yaml -validate -duc -ni -nc

Espere All templates validated successfully. Se o Nuclei informar um erro de YAML ou de expressão, compare a indentação, as aspas e as barras invertidas com o bloco completo; depois, repita o here-document corrigido e o comando de validação. Preserve targets.txt e scope.txt.

O curso aceita este subconjunto ensinado: uma definição HTTP GET no caminho aprovado {{BaseURL}}/maintenance/diagnostics, sem redirecionamentos e com matchers de status, palavra, regex ou DSL aplicados somente à resposta. Os auxiliares DSL permitidos são contains, contains_all, contains_any, regex, json_minify, len, tolower, toupper, starts_with e ends_with, aplicados a body, all_headers, status_code ou content_length. Use apenas id, info e http no nível superior, e os campos de requisição method, path, redirects, matchers-condition e matchers. Mantenha o template em até 32 KiB e no máximo doze matchers. Outros protocolos, scripts, callbacks externos e acesso a arquivos locais estão fora desta tarefa. Arranjos equivalentes de matchers dentro deste escopo são aceitos.

A verificação executa seu template inalterado com o mecanismo nativo do Nuclei em exemplos descartáveis de respostas positivas e negativas. Esses exemplos incluem alterações de portas, nomes de host, valores, disposição do JSON e parâmetros do tipo de conteúdo. Um arquivo que apenas valida, sempre corresponde ou nunca corresponde não pode passar nessas verificações funcionais.

Execute a verificação e revise a entrega

Nesta etapa, você aplicará seu template aos sites reais aprovados e guardará evidências que possam ser revisadas. Permaneça em Auditor. O mesmo arquivo pode ser reutilizado quando a lista de alvos mudar, pois seu caminho é relativo a BaseURL.

Execute a avaliação real. -l fornece as URLs base, -o salva achados e -elog salva erros de requisição. -jsonl usa um objeto JSON por achado; -ot omite o template codificado, mantendo a requisição e a resposta nativas.

nuclei -t diagnostics.yaml -l targets.txt -duc -ni -nc -jsonl -ot -o findings.jsonl -elog scan-errors.jsonl

Antes de interpretar a ausência de um achado, inspecione o log nativo de erros de requisição:

cat scan-errors.jsonl

Ele deve estar vazio nesta execução bem-sucedida. Um erro de conexão é uma verificação incompleta, mesmo se o Nuclei terminar com zero ou imprimir No results found. Corrija problemas de grafia ou conexão antes de tirar uma conclusão e use novos nomes de arquivo para uma nova tentativa, para que as evidências anteriores não sejam confundidas com a nova execução. Os arquivos finais aceitos são findings.jsonl e scan-errors.jsonl; se você tentou novamente com novos nomes, use cp para copiar o par bem-sucedido para esses nomes finais. Por exemplo, cp retry-findings.jsonl findings.jsonl copia o primeiro arquivo por cima do segundo; copie também o log de erros correspondente.

Leia os achados:

cat findings.jsonl

Espere uma URL correspondente terminada em /studio/maintenance/diagnostics. Leia a resposta incorporada e seu X-Audit-Event, não apenas o número de achados. O corpo deve atender ao contrato que você verificou manualmente.

Confirme por que duas alternativas plausíveis não corresponderam:

curl -i http://workshop.test:8080/garden/maintenance/diagnostics

Este é um JSON público com visibility definido como public. Não é uma exposição de diagnóstico interno.

curl -i http://workshop.test:8080/members/maintenance/diagnostics

Espere HTTP 302 com um Location apontando para login. Seu template não o segue nem confunde a página de login com um resultado de diagnóstico. Os outros sites sem correspondência são o archive protegido, a documentação aninhada em manual e a resposta mínima de integridade em status. Cada um ainda recebe a requisição de leitura aprovada; a ausência de achado descreve somente as condições deste template, não a segurança geral do site.

Entregue arquivos regulares autossuficientes que auditor possa ler. Sua entrega consiste no diagnostics.yaml reutilizável, no findings.jsonl real e no scan-errors.jsonl correspondente. Mantenha os arquivos de escopo ao lado deles. O template não contém caminho de arquivo de banco de dados, contagem de requisições, nome de host ou porta específicos de um alvo. A verificação confere a evidência real antes de executar exemplos isolados e preserva seus arquivos. Suas requisições comuns de leitura para verificar a preservação podem acrescentar entradas ao log do servidor e aumentar as contagens de requisições; elas não se tornam evidências da avaliação do aluno.

O desafio independente apresenta uma nova lista de implantações e novos endereços. Aplique o mesmo contrato de resposta e o mesmo rigor no tratamento de erros, mantendo disponíveis o uso público das oficinas e o acesso autorizado de manutenção.

Resumo

Você escreveu um template HTTP nativo do Nuclei que combina status, tipo de conteúdo e campos de diagnóstico normalizados. Testou diferenças entre respostas, preservou a portabilidade de BaseURL e avaliou todos os sites aprovados sem tratar uma falha de execução como resultado negativo. Sua entrega é composta pelo template real, pelos achados e pelo log nativo correspondente de erros de requisição.