DAST (teste dinâmico de segurança de aplicações) testa uma aplicação em execução por fora para encontrar fraquezas. Esta página explica como ele se diferencia de outros métodos e como usá-lo no seu próprio app (ela não trata de testes em sites de terceiros).
O que é DAST
DAST significa teste dinâmico de segurança de aplicações (dynamic application security testing). O DevSecOps Guideline da OWASP o descreve como um teste de caixa-preta que encontra vulnerabilidades e fraquezas de segurança em uma aplicação em execução. Caixa-preta significa testar apenas pelo que é visível de fora, sem olhar o código-fonte interno.
Na prática, uma ferramenta percorre as páginas e os campos de entrada do app, envia requisições de teste e procura sinais de problemas nas respostas. A diretriz diz que ele é especialmente útil para validação de entrada e saída, problemas de autenticação e erros de configuração do servidor.
Como funciona
Como ele se diferencia de SAST, IAST e SCA
| Método | O que examina | Executa o app? | Bom para |
|---|---|---|---|
| DAST | O comportamento do app em execução, por fora | Sim | Validação de entrada e saída, autenticação, configuração do servidor |
| SAST | Código-fonte ou código compilado | Não | Encontrar problemas de codificação no início do desenvolvimento |
| IAST | O comportamento interno do app (via sensores) | Sim (durante os testes) | Problemas que aparecem durante testes automatizados |
| SCA | Bibliotecas e outras dependências | Não | Componentes com vulnerabilidades conhecidas (CVEs) |
Para o SAST, a OWASP lista limitações como encontrar apenas um percentual relativamente pequeno das falhas de segurança de aplicações, muitos falsos positivos e problemas de configuração não identificados. O DAST ajuda a cobrir essa lacuna, mas também não é completo. Para o SCA, veja auditoria de dependências com o OSV-Scanner.
Como usá-lo no seu próprio app (exemplo com OWASP ZAP)
O ZAP (Zed Attack Proxy; antes chamado OWASP ZAP) é uma ferramenta DAST gratuita e de código aberto. O site oficial agora o identifica como "ZAP by Checkmarx".
- Prepare a URL de um ambiente de teste que você gerencia. Use um ambiente de teste, não a produção
- Execute uma varredura de linha de base (baseline scan). Segundo a documentação do ZAP, ela é apenas passiva: executa o spider (o recurso que percorre as páginas) por 1 minuto por padrão e não realiza ataques. Leva no máximo alguns minutos
- Leia os resultados e peça a uma pessoa que confirme quais achados são reais; falsos positivos acontecem
- Se necessário, passe para uma varredura ativa, apenas em um ambiente de teste. Ela executa ataques conhecidos contra o alvo, e a documentação diz que não deve ser usada em aplicações web que você não possui
- Execute novamente com regularidade, por exemplo no CI, após cada correção
Somente contra ambientes de teste de apps que você possui ou gerencia
Ferramentas DAST enviam tráfego semelhante a ataques reais. Executá-las em um site para o qual você não tem permissão de teste pode ser considerado acesso não autorizado ou interrupção de serviço. A documentação do ZAP também diz para não usar a varredura ativa em aplicações web que você não possui. Executar em produção também pode causar efeitos colaterais, como criação de dados ou aumento de carga.
O que o DAST deixa passar
A documentação do ZAP diz que sua varredura ativa não consegue encontrar problemas lógicos, como controle de acesso quebrado, por isso deve ser acompanhada de testes manuais. Uma falha como IDOR, em que um usuário pode ver os dados de outro, é difícil para uma ferramenta automatizada, porque ela não sabe qual é o comportamento correto. Você precisa escrever seu próprio teste que solicite o ID de outro usuário e confirme que o acesso é recusado.
Já as verificações de configuração são algo em que o DAST é bom. Sobre o que vale configurar, veja cabeçalhos de segurança: o que ainda importa.
Visão deste site: o DAST é a última camada. Pense em três camadas: código, componentes e comportamento
É mais realista combinar três métodos que olham em lugares diferentes do que esperar que uma única ferramenta encontre tudo: ler o código (SAST), verificar componentes em busca de vulnerabilidades conhecidas (SCA) e, então, executar o app e testá-lo por fora (DAST). O que as ferramentas não fazem bem, "quem pode fazer o quê", você protege com testes escritos por você. Não confie na saída das ferramentas sem revisão; peça a uma pessoa que a confirme antes de corrigir.
Fontes (primárias)
- OWASP DevSecOps Guideline, "Dynamic Application Security Testing" — owasp.github.io (definição de DAST, caixa-preta)
- OWASP DevSecOps Guideline, "Interactive Application Security Testing" — owasp.github.io (IAST)
- OWASP Community, "Source Code Analysis Tools" — owasp.org (SAST e suas limitações)
- ZAP Documentation, "Active Scan" — zaproxy.org (não para apps que você não possui; não encontra problemas lógicos)
- ZAP Documentation, "Baseline Scan" — zaproxy.org (apenas passiva; tempo de execução)
- A descrição de SCA é uma definição geral; não foi verificada nenhuma definição oficial única para ele
Leia em seguida
- Glossário: O que é fuzzing · O que é o OWASP Top 10 · O que é IDOR
- Guias: Cabeçalhos de segurança: o que ainda importa · Auditoria de dependências com o OSV-Scanner
- Glossário: O que é um CVE