DAST: testes dinâmicos de segurança
1. O que é DAST e por que desenvolvedores devem se importar
DAST (Dynamic Application Security Testing) é uma técnica de teste de segurança que analisa aplicações em execução, simulando ataques reais contra a interface exposta — normalmente HTTP/HTTPS. Diferente do SAST (Static Application Security Testing), que examina o código-fonte sem executá-lo, o DAST opera como um verdadeiro black-box: o scanner não conhece a estrutura interna, os frameworks utilizados ou as bibliotecas importadas.
Para desenvolvedores, o DAST oferece uma perspectiva única: ele enxerga exatamente o que um atacante externo veria. Enquanto o SAST pode apontar um eval() perigoso no código, o DAST vai descobrir se aquele endpoint realmente aceita injeção de comando no ambiente de produção. Essa diferença é crucial no Ciclo de Vida de Desenvolvimento Seguro (SDL), onde o DAST atua como a última barreira automatizada antes de um teste manual ou de uma liberação para produção.
2. Como o DAST funciona na prática
O processo típico de uma varredura DAST segue estas etapas:
- Descoberta — O scanner navega pela aplicação (spider/crawler) para mapear todos os endpoints, parâmetros GET/POST, cookies e cabeçalhos.
- Modelagem — Cada entrada identificada (formulários, APIs, parâmetros de URL) é catalogada com seu tipo esperado (string, inteiro, booleano, JSON).
- Ataque — O scanner substitui os valores originais por payloads maliciosos pré-definidos e mutações (fuzzing).
- Análise — As respostas HTTP são inspecionadas em busca de padrões indicativos de vulnerabilidade (erros de banco, execução de scripts, headers ausentes).
Exemplo de fluxo HTTP durante um teste de SQL Injection:
GET /api/users?id=1 HTTP/1.1
Host: app.exemplo.com
Response: {"id":1,"nome":"João"}
GET /api/users?id=1' OR '1'='1 HTTP/1.1
Host: app.exemplo.com
Response: {"id":1,"nome":"João"},{"id":2,"nome":"Maria"},{"id":3,...}
A segunda resposta retornou múltiplos registros, indicando que a query foi alterada — sinal clássico de SQL Injection.
3. Principais vulnerabilidades detectadas por DAST
O DAST é especialmente eficaz nas seguintes categorias do OWASP Top 10:
Injeção (SQLi, XSS, Command Injection)
- Testa campos de busca, login, APIs REST e parâmetros de URL.
- Detecta反射型XSS ao observar se o payload <script>alert(1)</script> aparece na resposta.
Quebra de autenticação e sessão
- Verifica se cookies de sessão são marcados como HttpOnly e Secure.
- Tenta reutilizar tokens JWT expirados ou manipulados.
Configuração incorreta de segurança
- Checa headers HTTP: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security.
- Identifica CORS permissivo (Access-Control-Allow-Origin: *).
- Testa falhas de TLS (protocolos obsoletos, certificados autoassinados).
4. Integração do DAST no pipeline de CI/CD
Para que o DAST seja efetivo no dia a dia do desenvolvedor, ele precisa estar integrado ao pipeline de entrega contínua. Os gatilhos mais comuns são:
- Pull Requests — Varredura rápida apenas nos endpoints modificados (quando possível).
- Deploy em staging — Varredura completa após cada deploy em ambiente de teste.
- Agendamento noturno — Varredura profunda em horário de baixo tráfego.
Ferramentas populares para integração:
| Ferramenta | Tipo | Integração CI |
|---|---|---|
| OWASP ZAP | Open-source | Plugin Jenkins, GitHub Actions, GitLab CI |
| Burp Suite Professional | Comercial | CLI via burpsuite + relatórios XML |
| Acunetix | Comercial | API REST, webhook para falhas críticas |
Tratamento de falsos positivos: configure thresholds de severidade (ex.: ignorar alertas "Informational" no pipeline de PR) e mantenha uma baseline de alertas conhecidos.
5. Exemplo prático: varredura DAST com OWASP ZAP
A seguir, um passo a passo para executar uma varredura básica usando o ZAP em modo daemon (headless).
1. Configuração de contexto e autenticação
# Iniciar ZAP em modo headless
zap.sh -daemon -port 8080 -host 0.0.0.0 -config api.disablekey=true
# Criar contexto com autenticação via formulário
curl "http://localhost:8080/JSON/context/action/newContext/?contextName=MeuApp"
# Configurar credenciais (substitua pelos dados reais)
curl "http://localhost:8080/JSON/authentication/action/setAuthenticationMethod/"
--data "contextName=MeuApp&authMethodName=formBasedAuth&authMethodConfigParams=loginUrl=http://app.test/login&loginRequestData=username={%username%}&password={%password%}"
curl "http://localhost:8080/JSON/authentication/action/setLoggedInIndicator/"
--data "contextName=MeuApp&loggedInIndicatorRegex=\\Qlogout\\E"
2. Execução do spider e active scan
# Spider (crawler) — descobre URLs
curl "http://localhost:8080/JSON/spider/action/scan/?url=http://app.test&contextName=MeuApp"
# Aguardar conclusão do spider (verificar status)
curl "http://localhost:8080/JSON/spider/view/status/"
# Active Scan — testa vulnerabilidades
curl "http://localhost:8080/JSON/ascan/action/scan/?url=http://app.test&contextName=MeuApp&recurse=true"
3. Interpretação dos resultados
Após a varredura, gere um relatório HTML:
curl "http://localhost:8080/OTHER/core/other/htmlreport/" -o relatorio-dast.html
No relatório, procure por:
- Alerta vermelho (Alto) — SQL Injection, Command Injection, XSS persistente.
- Alerta laranja (Médio) — Missing headers de segurança, CORS permissivo.
- Alerta amarelo (Baixo) — Cookies sem flag
Secure, informações de versão expostas.
Cada alerta contém a URL exata, o parâmetro testado e a evidência (trecho da requisição/resposta).
6. Limitações e cuidados ao usar DAST
Cobertura limitada em autenticação complexa
- Fluxos OAuth 2.0 com redirects e troca de tokens são difíceis de configurar.
- Aplicações Single-Page (SPA) que usam JWT armazenado em memória podem não ser corretamente rastreadas.
Risco de degradação ou quebra
- Um active scan pode gerar milhares de requisições por minuto.
- Em ambientes de staging com dados reais, payloads de DELETE ou UPDATE podem corromper registros.
Dependência de ambiente representativo
- Se o ambiente de teste não tiver dados populados, o DAST não encontrará vulnerabilidades em funcionalidades que dependem de estado (ex.: "minha conta" só aparece após login com dados reais).
Mitigações:
- Use ambientes isolados com dados sintéticos.
- Defina rate limiting no scanner (ex.: -maxprocs 2 no ZAP).
- Exclua endpoints destrutivos da varredura ativa.
7. Estratégia combinada: DAST + SAST + testes manuais
Nenhuma técnica isolada cobre todas as vulnerabilidades. A recomendação prática para times de desenvolvimento é:
| Técnica | Quando usar | O que cobre |
|---|---|---|
| SAST | A cada commit/PR | Vulnerabilidades no código fonte (injeção, lógica, dependências) |
| DAST | Antes de cada release | Configuração de runtime, headers, falhas de deploy |
| Teste manual | Pré-produção (sprint review) | Lógica de negócio, bypass de regras, autorização |
Ciclo de correção ideal:
- Desenvolvedor escreve código → SAST aponta falha → correção no PR.
- Deploy em staging → DAST executa → alerta de CORS aberto → ajuste de configuração.
- Homologação → pentester manual descobre que usuário pode acessar dados de outro usuário (IDOR) → correção de autorização.
Para unificar a visão, crie um dashboard que agregue alertas de SAST e DAST por severidade, com links diretos para o commit e a URL vulnerável. Ferramentas como DefectDojo ou ThreadFix podem consolidar esses dados.
Referências
- OWASP ZAP Documentation — Guia oficial de instalação, configuração e API do ZAP, com exemplos de autenticação e varredura.
- OWASP DAST Guide — Documentação completa sobre boas práticas de testes dinâmicos, incluindo preparação de ambiente e interpretação de resultados.
- Burp Suite Scanner Overview — Tutorial oficial da PortSwigger sobre configuração de varreduras automatizadas com Burp Suite.
- Integrating DAST into CI/CD (GitLab Docs) — Documentação do GitLab sobre como adicionar varredura DAST no pipeline com templates prontos.
- OWASP Top 10:2021 — Lista atualizada das vulnerabilidades mais críticas em aplicações web, referência para priorização de alertas DAST.