Um DAST executado sem sessão logada avalia só a fachada da aplicação: a página de login, arquivos públicos e rotas abertas. Painéis administrativos, APIs autenticadas, fluxos de upload e telas de perfil — onde boa parte das falhas exploráveis vive — ficam invisíveis, e o relatório conclui que não há vulnerabilidades apenas porque o crawler foi barrado na porta de entrada. Equipes que mantêm aplicações web com área restrita precisam configurar a autenticação dentro do próprio scanner antes de confiar na cobertura: contexto de URLs, gerenciamento de sessão, método de autenticação, estratégia de verificação e usuários de teste dedicados.
Por que o login bloqueia varreduras
A varredura anônima tem valor próprio: encontra diretórios abertos, cabeçalhos ausentes e páginas esquecidas. Ela não substitui, porém, o teste autenticado. Controles de acesso quebrados, referências inseguras a objetos e exposição de dados em endpoints internos só se manifestam quando existe uma sessão válida em uso. O resultado silencioso é o mais perigoso: a equipe acredita em cobertura completa porque o scanner terminou sem erros, quando na prática mediu dez telas públicas de um sistema com centenas.
A causa técnica é simples. O scanner é um cliente HTTP sem memória de identidade: quando a aplicação redireciona para o login, ele registra o redirecionamento e segue adiante. Ele não percebe que perdeu acesso — a menos que alguém ensine qual sinal distingue sessão ativa de sessão expirada. É essa configuração que separa um DAST útil de um gerador de falsa tranquilidade.
As camadas da autenticação
O Web Security Testing Guide da OWASP define o ponto de partida. O gerenciamento de sessão cobre os mecanismos que armazenam e validam credenciais por um tempo pré-determinado, e o teste correspondente exige que cookies e demais tokens sejam gerados de forma segura e imprevisível.
No lado da ferramenta, a documentação de autenticação do ZAP organiza a configuração em elementos obrigatórios: contexto, gerenciamento de sessão, método de autenticação, estratégia de verificação e usuários definidos por contexto. Cada um responde a uma pergunta distinta.
- Contexto: o conjunto de URLs que pertence à aplicação; sem ele, o crawler persegue domínios de terceiros e encerra sem mapear a área logada.
- Gerenciamento de sessão: como a sessão é mantida entre requisições — por cookie, pelo cabeçalho Authorization ou por script, quando o fluxo é customizado.
- Método de autenticação: como o login é executado — formulário, autenticação HTTP, script dedicado ou autenticação executada no navegador.
- Estratégia de verificação: o sinal que identifica sessão ativa, como um link de logout ou uma mensagem de boas-vindas, e seu oposto, o indicador de expiração.
- Usuários: credenciais de teste isoladas por usuário, separadas da definição do contexto, o que permite varrer perfis distintos na mesma execução.
| Camada | O que configurar | Como validar |
|---|---|---|
| Contexto | Todas as URLs da área logada, com subdomínios de API | Árvore de URLs contém páginas internas |
| Sessão | Cookie, cabeçalho ou script conforme a aplicação | Token persiste nas requisições seguintes |
| Autenticação | Pedido de login com parâmetros de usuário e senha | Reautenticação funciona sem intervenção |
| Verificação | Indicador de sessão ativa e de expiração | Scanner alerta quando a sessão cai |
| Usuários | Contas de teste dedicadas por perfil | Cada varredura usa a conta prevista |
Procedimento passo a passo
- Crie contas de teste dedicadas, com privilégio representativo do usuário real; nunca use credenciais de produção.
- Defina o contexto e inclua todas as URLs da área restrita, inclusive subdomínios de API e recursos próprios.
- Encaminhe o navegador pelo proxy do scanner e execute o login manualmente para registrar o fluxo completo.
- Marque o pedido de login, indique quais parâmetros são usuário e senha e registre tokens anti-CSRF presentes no formulário.
- Selecione o método de gerenciamento de sessão correspondente: cookie, cabeçalho Authorization ou script.
- Defina o indicador de sessão ativa — por exemplo, o link de logout — e o indicador de expiração.
- Rode o spider autenticado e confira na árvore de URLs se as páginas internas apareceram de fato.
- Somente então inicie a varredura ativa, com limites de requisição e, sempre que possível, em ambiente de staging.
Como detectar sessão caída
Três sinais revelam sessão perdida no meio da execução: a árvore de URLs para de crescer logo depois da página de login; todas as respostas passam a devolver o mesmo redirecionamento; o cookie muda a cada requisição porque o servidor reemite tokens anônimos. Ao notar qualquer um deles, interrompa a varredura — continuar produz um relatório que mede a tela de login dezenas de vezes.
Configure a reautenticação por indicador de expiração, e não apenas no início da execução. Sessões com validade curta expiram durante testes ativos demorados, e o scanner sem essa configuração segue varrendo a fachada sem avisar ninguém.
Limites e falsos positivos
Cobertura ampliada não é cobertura completa. Ferramentas genéricas não conhecem o código da sua aplicação: falhas de lógica de negócio, autorização entre perfis e fluxos multiusuário seguem exigindo teste manual dirigido — complemento natural da análise de taint no SAST. E a superfície logada concentra dados reais: falhas em produtos como o Metabase, que expuseram dados de saúde, reforçam por que essa camada exige teste contínuo.
O guia técnico do NIST resume a disciplina necessária: a publicação orienta planejar e conduzir testes técnicos de segurança, analisar os achados e desenvolver estratégias de mitigação, com atenção aos benefícios e limitações de cada técnica. Planejar, aqui, inclui escopo autorizado, ambiente, janela de execução e critério de triagem dos achados.
Limites práticos merecem registro: MFA com senha única quebra reautenticação automática — trate com conta de teste isenta do segundo fator quando a política permitir; varredura ativa em produção pode corromper dados e disparar alertas; e relatórios volumosos exigem triagem, sob pena de um acesso indevido real se perder entre centenas de avisos de cabeçalho.
Ações priorizadas
P1 — esta semana
- Configurar autenticação no DAST das aplicações críticas com área logada e medir a cobertura de URLs internas visitadas.
- Criar contas de teste dedicadas, com registro de responsável, para auditoria e revogação.
- Definir indicadores de sessão ativa e expirada em cada contexto varrido.
P2 — este trimestre
- Agendar varredura autenticada recorrente em staging a cada release relevante.
- Comparar a árvore de URLs entre execuções para identificar novas rotas autenticadas ainda sem teste.
- Reunir achados de DAST e SAST em um único fluxo de triagem, com dono e prazo por item.