DAST

DAST é uma análise dinâmica de aplicações em execução. No XGuardian, ela é destinada a sites, portais, serviços HTTP/HTTPS, APIs e outras superfícies acessíveis por URL, sempre dentro de um escopo autorizado. Ela não é uma varredura geral de rede, portas ou infraestrutura.

Visão geral

A análise dinâmica observa o comportamento que o alvo expõe em tempo de execução. Conforme o escopo definido, ela pode percorrer URLs alcançáveis, analisar requisições e respostas HTTP e registrar evidências para apoiar a investigação dos achados.

Uma execução não autenticada cobre apenas o que está disponível sem sessão válida. Uma execução autenticada depende de uma conta de teste, dados de acesso e condições que mantenham a sessão ativa. A cobertura pode variar conforme o mecanismo de autenticação, as rotas alcançáveis e as regras do próprio alvo.

DAST complementa outras modalidades: ele observa a aplicação ou API em execução; não substitui análise de código, inventário de componentes, revisão de infraestrutura ou teste manual especializado.

Como uma execução evolui

O resultado retrata o que estava acessível no ambiente e no período analisados. Uma rota indisponível, fora do escopo ou inacessível à conta de teste não faz parte da cobertura daquela execução.

Escopo e pré-requisitos

Defina o alvo antes da execução. Registre o domínio ou subdomínio, a URL de entrada, os caminhos incluídos e os caminhos que não devem ser acessados. Limite o teste aos hosts autorizados e revise redirecionamentos para evitar saída acidental do escopo.

Para um ambiente interno, o executor precisa ter conectividade com o alvo. DNS, rotas e controles de rede devem permitir o tráfego necessário, e o serviço precisa estar autorizado para teste. Esta documentação não pressupõe VPN, agente, túnel, proxy ou outra arquitetura específica.

Refinar escopo e execução

O XGuardian oferece controles para configurar o cenário antes de iniciar a análise. Registre cada escolha junto com o escopo: isso reduz acessos desnecessários, torna a execução mais previsível e ajuda a interpretar a cobertura alcançada.

Exclusão de escopo por padrão (URLs e extensões)

É possível refinar o escopo da varredura excluindo determinados caminhos por meio de expressões regulares, bem como excluir tipos de arquivo específicos por extensão, evitando ruído de conteúdo estático ou irrelevante para a análise.

Headers HTTP personalizados

À varredura permite a definição de cabeçalhos HTTP personalizados a serem enviados durante os testes, possibilitando cenários que exigem headers adicionais além dos utilizados na autenticação padrão.

Modo de descoberta (crawler) isolado

Àlém da varredura completa, é possível executar apenas a etapa de descoberta (crawler), navegando pela aplicação para identificar URLs existentes sem realizar testes ativos, útil para mapeamento prévio da superfície.

Seleção granular de testes

É possível selecionar de forma granular quais testes, plugins ou classes de ataque serão executados durante a varredura, adequando o escopo da análise ao perfil de risco da aplicação.

Limites de varredura configuráveis

À varredura pode ser configurada com limites como número máximo de URLs e diretórios analisados, quantidade máxima de elementos de página processados, tamanho máximo de resposta considerada, limite de redirecionamentos seguidos, tempo máximo de execução, e limites de conexões e requisições por segundo ao servidor avaliado.

Detecção de congestionamento

À varredura monitora o comportamento de rede durante a execução, com limite de tempo para timeout de requisições e um número máximo de timeouts consecutivos antes de interromper a varredura, evitando impacto desnecessário sobre o ambiente avaliado.

Aplicações web

Para uma aplicação web acessível, use o fluxo DAST Web e informe uma URL inicial dentro do escopo. A descoberta depende dos links, formulários, respostas e rotas que o alvo expõe ao contexto da execução. Quando a aplicação exigir interação, sessão ou conteúdo carregado dinamicamente, a cobertura depende da configuração e da superfície efetivamente alcançável.

A análise pode observar respostas durante a descoberta e realizar verificações ativas controladas, conforme a configuração escolhida. Os achados devem ser avaliados com a evidência registrada no resultado; uma execução automatizada não promete cobertura total nem confirma, por si só, impacto de negócio.

Em aplicações modernas, rotas carregadas por JavaScript, filtros, formulários e chamadas assíncronas podem exigir configuração, tempo de carregamento, permissões e massa de teste apropriados. Confirme a jornada que se espera cobrir antes de interpretar a ausência de achados.

Conforme o escopo e a superfície alcançável, a auditoria inclui cookies, cabeçalhos, formulários, links, nomes e valores de parâmetros, elementos JSON e XML trafegados nas requisições e respostas e o DOM renderizado. Isso abrange aplicações tradicionais e, quando a jornada estiver configurada e alcançável, interfaces dinâmicas de página única.

DAST avalia superfícies expostas por HTTP ou HTTPS. A cobertura continua limitada à URL autorizada, às rotas alcançáveis e à configuração do cenário; ela não representa uma varredura geral de protocolos, portas ou infraestrutura.

APIs

Compatibilidade REST e SOAP

A varredura de API é compatível com web services REST e SOAP, cobrindo diferentes padrões de integração.

Para o fluxo DAST API, prepare uma URL de entrada, os métodos e parâmetros necessários, cabeçalhos exigidos, autenticação e dados de teste seguros.

Ao configurar uma API, revise se a definição representa a versão implantada e se não descreve operações destrutivas, administrativas ou que manipulem dados sensíveis antes de incluí-la no escopo.

Sinais técnicos e evidências

Conforme a superfície alcançável e a configuração, a análise pode gerar evidências para investigação de controles de acesso expostos, entradas e parâmetros, respostas e mensagens de erro, sessão, autenticação, comunicação HTTP/HTTPS, redirecionamentos, formulários e integrações acessíveis.

Evidência detalhada para vulnerabilidades de injeção

Para vulnerabilidades de injeção (SQL, XSS, XSRF), os detalhes do achado incluem o payload utilizado, a evidência na resposta da aplicação, e os detalhes completos da requisição e da resposta HTTP envolvidas.

Trate esses dados como sensíveis ao contexto: evite reproduzir valores reais, tokens, cookies ou informações pessoais ao compartilhar o resultado.

Classificação por OWASP Top 10

Cada achado é classificado de acordo com as categorias do OWASP Top 10, permitindo leitura de risco alinhada a uma referência reconhecida internacionalmente.

Esses sinais não confirmam impacto de negócio sozinhos. O time responsável deve revisar a evidência no contexto da aplicação, reproduzir de forma segura quando necessário e priorizar a correção com base no risco real.

Acompanhar resultados

Os resultados podem ser acompanhados ao longo do tempo para observar a evolução das correções e a entrada de novos achados. Nas visões de riscos e relatórios, a leitura pode ser agregada por tipo de vulnerabilidade e por aplicação, facilitando a priorização técnica e o acompanhamento gerencial.

A tendência deve ser interpretada junto com escopo, ambiente, disponibilidade, autenticação e versão analisada. Mudanças nesses fatores podem alterar a cobertura e os resultados entre execuções.

Autenticação e sessão

Quando a área protegida precisar ser analisada, configure um cenário de autenticação adequado ao alvo e use uma conta de teste com o menor privilégio possível. O resultado depende do mecanismo de login e de a sessão permanecer válida durante a execução.

Verifique, quando o cenário permitir:

• URL ou condição que confirma o login;
• URL ou condição que confirma logout ou perda da sessão;
• cookies, headers de autorização ou tokens de sessão necessários;
• expiração, renovação e reautenticação configuradas para a jornada;
• dados de teste compatíveis com as rotas que serão acessadas.

Fluxos modernos, múltiplas etapas ou altamente personalizados podem exigir configuração específica. Não presuma que a ferramenta identificará automaticamente cada mecanismo de autenticação, códigos temporários ou regras de negócio.

Se a autenticação falhar, o teste pode ficar restrito à área pública ou não alcançar o comportamento planejado. Antes de interpretar o resultado, confirme que a conta chegou à página, rota ou operação esperada.

Segurança operacional

• Use ambientes autorizados e, quando possível, homologação.
• Use usuários de teste com o menor privilégio possível; evite contas e dados reais.
• Defina limites de requisição e acompanhe logs, disponibilidade e respostas do alvo.
• Exclua rotas destrutivas, fluxos financeiros, exclusões de dados e outras operações sensíveis.
• Proteja credenciais de teste e revogue ou troque o acesso após o uso, quando necessário.
• Combine uma janela de execução e um canal de contato com os responsáveis pela aplicação.
• Considere que testes ativos podem alterar dados ou aumentar carga, mesmo em ambiente controlado.

Antes de iniciar, alinhe com os responsáveis a autorização, o ambiente, os hosts e caminhos incluídos, as exclusões de alto impacto, a conectividade, a conta de menor privilégio, a massa sanitizada e o plano de interrupção da execução.

Limitações

A análise automatizada depende da superfície alcançável e da qualidade da configuração. Ela pode não acessar funcionalidades protegidas se a autenticação falhar, não compreende automaticamente todas as regras de negócio e pode produzir falsos positivos ou falsos negativos.

Um resultado sem achados não garante ausência de vulnerabilidades. Investigue os itens com evidências, complemente o trabalho com revisão humana quando o risco justificar e nunca execute testes sem autorização.

Troubleshooting

Não repita uma execução sem investigar o motivo. Guarde a evidência disponível, corrija a configuração ou o ambiente e reteste apenas dentro da autorização aprovada.

Interpretar e tratar resultados

1. Confirme aplicação, ambiente, URL, escopo e data da execução.
2. Revise a evidência técnica e reproduza de forma segura quando necessário.
3. Determine o impacto no contexto da aplicação e priorize a correção.
4. Corrija no código, configuração ou controle operacional correspondente.
5. Execute uma nova análise no mesmo escopo para confirmar o tratamento.

Os resultados podem variar quando URL, ambiente, conta, disponibilidade, escopo ou versão implantada mudam. Registre esses fatores junto à evidência de remediação.

Próximo passo

Antes de criar o scan, revise Aplicações e scans e alinhe o escopo com quem responde pelo ambiente testado.