Testes Dinâmicos (DAST)

Testes Dinâmicos é a capacidade de Dynamic Application Security Testing (DAST) do ZeroPath para aplicações em execução. Ela pode ser empregada de três formas: descobrir vulnerabilidades em aplicações ao vivo, confirmar quais descobertas estáticas são exploráveis em tempo de execução e verificar que as correções resolvem o problema após o merge.

​

O Que Ele Faz

Os Testes Dinâmicos exercitam um alvo em execução configurado com o contexto da descoberta, os inputs do perfil da aplicação, credenciais de runtime criptografadas e, quando necessário, um artefato compilado da aplicação local. O objetivo é produzir evidências a partir da aplicação ao vivo, em vez de depender apenas da análise estática. Os resultados de runtime validation usam estes veredictos: Descobertas com veredicto Disconfirmed podem ser movidas para o fluxo de falso positivo com evidência de runtime explicando por que a issue não se reproduziu.

​

Classes de Vulnerabilidade

Os testes dinâmicos podem visar comportamentos de runtime que são difíceis de provar apenas a partir do código-fonte:

• Injeção de prompt - testa se funcionalidades com IA executam instruções injetadas, manipulando inputs em prompts voltados ao usuário e de backend. As descobertas mostram o caminho da injeção e a resposta do modelo.
• IDOR - exercita identificadores de objetos entre papéis autenticados para provar quando usuários conseguem acessar recursos que não lhes pertencem.
• Encadeamento de vulnerabilidades - combina múltiplos comportamentos de runtime para mostrar como fraquezas menores se tornam um caminho de ataque prático.
• Vulnerabilidades out-of-band (OOB) - detecta SSRF cego, XXE cego, injeção de SQL cega, exfiltração via DNS e outras vulnerabilidades em que o comportamento explorado não é visível na resposta HTTP. O agente de validação gera URLs de callback únicas em oob.0path.ai e monitora requisições de saída da aplicação-alvo, provando que o payload injetado disparou uma requisição real do lado do servidor.

​

Testes Out-of-Band e Requisitos de Rede

Os testes OOB usam oob.0path.ai como servidor de callback padrão. O agente de validação injeta URLs únicas sob esse domínio na aplicação-alvo e monitora lookups de DNS, requisições HTTP e outras interações de protocolo que provam que a vulnerabilidade é explorável. Se a sua aplicação-alvo roda atrás de um firewall ou de um filtro de saída, pode ser necessário adicionar *.oob.0path.ai (DNS e HTTPS) à lista de permissões para que o alvo consiga alcançar o servidor de callback. Sem isso, os testes OOB não retornarão interações mesmo quando a vulnerabilidade for real.

​

Pré-requisitos

Os Testes Dinâmicos exigem:

• Uma aplicação implantada alcançável pelo worker de validação, ou um artefato compilado da aplicação local enviado no painel de configuração da Runtime Validation.
• Um perfil de aplicação de Runtime Validation para a aplicação detectada.
• Todos os inputs obrigatórios do perfil salvos, como a URL do alvo e os campos de autenticação gerados.
• Para validação específica por issue, um full scan concluído com descobertas SAST elegíveis.

Os campos de input gerados são representados como campos estruturados no dashboard, e não como um único blob JSON. Os valores são criptografados antes de serem armazenados, e verificações de prontidão impedem que a validação comece até que os inputs obrigatórios estejam presentes. A validação com artefato local atualmente suporta artefatos compilados para Linux x86_64/amd64 empacotados como .zip, .tar, .tar.gz ou .tgz. O artefato é executado dentro do contêiner gVisor de Runtime Validation do ZeroPath, baseado em Debian; outros sistemas operacionais e arquiteturas de CPU não são suportados.

​

Executando a Runtime Validation

​

Revisando os Resultados

A aba Runtime Validation do repositório mostra as execuções de validação recentes. Selecionar uma execução abre uma página dedicada com abas de resultados:

• Queued - issues que ainda aguardam a validação em tempo de execução.
• Confirmed - issues comprovadamente exploráveis em tempo de execução.
• Disconfirmed - issues que não se reproduziram no ambiente de runtime configurado.
• Unable - issues em que a validação não conseguiu produzir um veredicto confiável.

Clicar em uma issue a partir de qualquer aba de resultados abre a visão padrão de issues do ZeroPath, de modo que a descoberta estática, o passo a passo do exploit, a orientação de remediação e a evidência de runtime podem ser revisados em conjunto.

​

Evidência em Nível de Issue

Quando uma descoberta tem saída de Runtime Validation, o modal da issue e a visão completa da issue incluem uma seção de Runtime Validation recolhida abaixo do passo a passo do exploit. Ela resume:

• O veredicto mais recente e o status da execução.
• O que o ZeroPath tentou durante os testes em tempo de execução.
• As evidências observadas durante a tentativa.
• Por que a descoberta foi confirmada, refutada ou marcada como unable.
• Um link para a página dedicada da execução, para um contexto mais amplo.

A seção fica recolhida por padrão para que a visão da issue permaneça legível para usuários que só precisam dos detalhes da descoberta original.

​

Dados de Validação Estruturados na API

As respostas da API de detalhes da issue e de runtime validation incluem dois campos estruturados que fornecem uma visão legível por máquina do que o agente de validação fez:

• validationSteps — uma lista ordenada de objetos, um por ação executada pelo agente. Cada objeto contém:
  • target — o endpoint, workflow, objeto ou caminho de código exercitado (pode ser nulo).
  • action — a ação concreta executada.
  • expectedResult — o comportamento seguro esperado ou o sinal de exploit para esse passo (pode ser nulo).
  • observedResult — o que o agente de fato observou em tempo de execução.
  • conclusion — por que essa observação importa para o veredicto.
• attackReproductionSteps — apenas para descobertas confirmadas, uma lista ordenada de passos em linguagem natural que reproduzem o ataque confirmado. Adequada para inclusão em um relatório de bug ou em um ticket de remediação.

Ambos os campos são retornados como arrays e estão sempre presentes (vazios quando não aplicáveis). O campo agentGroupKey, anteriormente disponível, foi removido da resposta da API.

​

Notas Operacionais

• Execuções de aplicação completa são bloqueadas enquanto existir outra execução ativa para o mesmo escaneamento e perfil de aplicação.
• Execuções de issue selecionada são bloqueadas apenas quando uma execução de aplicação completa está ativa ou quando outra execução ativa de issue selecionada já visa a mesma descoberta.
• Os Testes Dinâmicos dependem do alvo implantado configurado, portanto uma falha em alcançar a aplicação deve ser tratada como um problema de ambiente ou de perfil antes de considerar a descoberta como refutada.
• Para repositórios com muitos escaneamentos, use a lista de execuções e as abas de resultados em vez de examinar issue por issue na tabela principal de issues.

​

Páginas Relacionadas

• Visão Geral do SAST
• Configurações do Scanner
• Auto-Fix e Patches