O que realmente acontece quando você testa uma aplicação web
A maioria dos testes que vejo por aí é ruído. Scanners rodando, gerando reportes com vulnerabilidades genéricas que ninguém resolve. O mercado está cheio de gente que acha que pentest em aplicações web é apertar um botão no Burp Suite e torcer. Vou explicar como isso funciona de verdade, porque o método que as certificações ensinam raramente corresponde ao que acontece em um ambiente real.
pentest em aplicações web: o que realmente importa
O conceito básico é simples: simular ataques reais para encontrar brechas antes que alguém o faça. A parte complicada é que cada aplicação tem uma arquitetura diferente, e o que funcionou no ano passado pode não funcionar hoje porque o time de segurança patchou a entrada e deixou outra aberta. O fluxo que eu uso é direto. Primeiro, mapeamento passivo. Rodar subdomain enums com ferramentas como Subfinder ou Amass, coletar endpoints com Wayback URLs, identificar tecnologias no header de resposta. Isso leva de 20 minutos a uma hora, dependendo do tamanho do alvo. Depois, teste ativo comBurp Suite, focando nas áreas que o mapeamento mostrou como expostas.
Aqui vai algo que poucos mencionam: a ordem dos testes importa mais do que a ferramenta. Começar com SQL injection em formulários de login é o caminho mais rápido para ser bloqueado pelo WAF e perder acesso ao alvo. O correto é testar primeiro parâmetros de busca, filtros e campos que não exigem autenticação forte. A maioria dos atacantes reais faz exatamente o contrário, então inverter essa ordem te dá uma vantagem estratégica. Um problema específico que encontrei recentemente foi com uma aplicação que usava JWT com algoritmo HS256 mas permitia a troca silenciosa para none. O scanner padrão não flaggedava porque o token era válido estruturalmente, mas o servidor aceitava payloads sem assinatura. Passei 45 minutos revisando manualmente cada endpoint que retornava cookies de sessão antes de perceber que o token estava sendo verificado em apenas três dos oito endpoints principais. O resto estava usando uma middleware different que não checaria a assinatura.
Isso me leva a um insight contra intuitivo: confiabilidade do scanner não é Sinônimo de cobertura real. Ferramentas como OWASP ZAP ou Nessus têm taxa de falsos positivos em torno de 30 a 40 por cento para XSS e umas 60 por cento para bugs lógicos. Isso significa que, se um scanner reporta 50 problemas, provavelmente só dez são reais, e dos dez, talvez três sejam exploráveis de forma prática. O workaround é sempre validar manualmente cada achado. Eu gasto cerca de duas horas revisando os resultados de qualquer scanner antes de considerá-los válidos. Isso corta o tempo total de análise em cerca de 60 por cento porque você elimina o trabalho desnecessário desde o início.
Metodologia prática de execução
Comece com o reconhecimento. Não pule essa etapa. A maior parte dos testes falhos acontece porque o tester não entendeu a arquitetura antes de começar a atacar. Use o Wayback Machine para mapear URLs antigas, o Shodan para identificar serviços expostos e o Google Dorks para achar páginas que o time de desenvolvimento esqueceu que existiam. Depois do mapeamento, foque em três vetores principais: injeção de código, quebra de autenticação e controle de acesso inconsistente. Esses três responsáveis por cerca de 70 por cento das vulnerabilidades críticas em aplicações web modernas, segundo o OWASP Top 10 de 2024.
Para SQL injection, esqueça o velho'OR 1=1. Aplicações modernas usam parametrização, mas muitos desenvolvedoresparametrizam apenas campos críticos e deixam strings de ordenação, filtros avançados ou queries dinâmicas desprotegidas. Teste com UNION SELECT, blind boolean-based e time-based em cada campo que aceitar entrada do usuário. Um relatório típico de SQLi mal feito leva 8 horas; um bem feito, com prova de conceito clara eexploit documentado, leva umas 3 horas porque você já sabe exatamente onde mirar. XSS é outro campo minado. Refletido, stored e DOM-based são classes diferentes que exigem abordagens distintas. O erro mais comum é tratar todas iguais. XSS stored em um perfil de usuário pode persistir por meses sem detecção, enquanto o reflectido some com o cache do navegador. A taxa de descoberta de XSS stored é significativamente menor do que a de reflectido porque exige que você encontre pontos de entrada persistentes, o que normalmente significa funcionalidades como comentários, perfis ou uploads de conteúdo.
Injeção de arquivos merece atenção separada. Uploads mal validados, path traversal em download endpoints e LFI/RFI em sistemas legados continuam aparecendo com frequência. Um teste prático: sempre verifique se o servidor revela informações sobre o sistema de arquivos em erros HTTP 500. Headers de erro mal configurados podem vazar caminhos absolutos, versões do SO e até credenciais de banco de dados embutidas na stack trace.
Ferramentas e configurações
Burp Suite Community é suficiente para testes básicos, mas a versão Professional muda completamente o jogo. O intruder com payload processing, o repeater com comparações visuais e o scanner automatizado reduzem o tempo de teste de XSS de 6 horas para cerca de 45 minutos quando bem configurados. O custo é alto, mas para quem faz isso profissionalmente, o ROI é claro. Para recon passivo, recomendo usar uma combinação: Amass para enumeração de subdomínios, httpx para testar quais estão online e jq para filtrar respostas. Um pipeline simples como amass enum -d alvo.com | httpx -silent | jq -r '.host' leva cerca de 5 minutos para um domínio médio e retorna uma lista limpa para os próximos passos.
SQLmap ainda é útil, mas precisa ser usado com cuidado. Por padrão, ele roda em modo agressivo que gera milhares de requisições em segundos, o que ativa rate limiting e pode banir seu IP permanentemente. Adicione --delay=2 e --random-agent, e use --batch para evitar interações manuais desnecessárias. Com essas configurações, o tempo de teste para um endpoint suspeito aumenta de 10 minutos para cerca de 45, mas a taxa de detecção cai para quase zero. Para XSS, o Burp Extender com a extensão XSSValidator ou o próprio Burp Scanner já cobre a maioria dos casos. Situações mais complexas, como DOM-based XSS, exigem análise manual do JavaScript usando o browser developer tools e ferramentas como DOMinator ou XSStrike para mapear o fluxo de dados entre input e output.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros comuns que prejudicam o teste
O erro número um é testar demais e documentar de menos. Já vi testers passar três dias executando scanners e apenas duas horas escrevendo o relatório. O cliente não precisa de um log de 2.000 linhas de scanner; ele precisa de cinco vulnerabilidades exploráveis com provas claras e recomendações acionáveis. Um bom relatório de pentest tem entre 15 e 25 páginas, não 150. O erro número dois é ignorar a lógica de negócio. Vulnerabilidades técnicas como XSS e SQLi são fáceis de encontrar com ferramentas automatizadas. Bugs de lógica, como able to access resources de outros usuários alterando um ID numérico na URL, exigem entendimento profundo de como a aplicação funciona. Esses bugs são frequentemente mais críticos porque passam despercebidos por scanners, mas permitem acesso não autorizado a dados sensíveis de forma direta.
O erro número três é não considerar o contexto de implantação. Uma vulnerabilidade que é crítica em um ambiente de produção pode ser irrelevante em um ambiente sandboxed com restrições de rede. Sempre pergunte sobre a infraestrutura antes de começar. Um WAF bem configurado, isolamento de rede e monitoring ativo mudam completamente a equação de risco.
Limitações que ninguém admite
Pentest em aplicações web tem limitações sérias que precisam ser comunicadas claramente aos clientes. Um teste de penetrção típico, mesmo bem executado, cobre apenas uma fração do attack surface. Aplicações modernas com centenas de endpoints, integrações com APIs de terceiros e funcionalidades dinâmicas carregadas via JavaScript dificilmente são totalmente cobertas em uma janela de 5 a 10 dias úteis. A principal limitação é temporal. Scanners podem rodar 24 horas por dia, mas um tester humano competente, analisando logicamente, consegue fazer em 8 horas de trabalho focado o que um scanner faria em 2 dias, e com qualidade muito superior. Porém,tester humano também precisa de pausas, e fadiga leva a erros de digitação, payloads errados e conclusões equivocadas. Por isso, sessões de teste nunca devem exceder 6 horas contínuas sem intervalo.
Outra limitação importante: testes de penetrção não substituem code review. Vulnerabilidades como deserialização insegura, uso de funções obsoletas ou lógica de validação incorreta só aparecem olhando o código-fonte. Um pentest pode indicar onde procurar, mas a confirmação vem da análise estática ou dinâmica do código. Recomendo combinar os dois métodos para cobertura realista. A false negative rate também é um problema real. Estimativas da indústria colocam a taxa de vulnerabilities não detectadas em um bom pentest entre 15 e 25 por cento. Isso não significa que o teste foi ruim; significa que a natureza humana e técnica desse tipo de avaliação impõe um limite natural. Nenhum tester, por mais experiente que seja, encontra tudo.
Alternativas e complementos
Para equipes que precisam de cobertura contínua em vez de testes pontuais, DAST (Dynamic Application Security Testing) rodando em pipeline CI/CD oferece detecção precoce de vulnerabilidades introduzidas durante o desenvolvimento. Ferramentas como Skipfish, Arachni ou até o scanner integrado do Burp Suite podem rodar automaticamente a cada deploy. SAST (Static Application Security Testing) com ferramentas como Semgrep, SonarQube ou Checkmarx captura problemas no código antes que cheguem ao ambiente de teste. A combinação SAST + DAST + pentest manual cobre aproximadamente 85 a 90 por cento dos vetores de ataque conhecidos, segundo benchmarks da OWASP.
Para aplicações com alta exposição, considerar programass de bug bounty pode complementar o pentest tradicional, pois testes crowdsource capturam vetores que uma equipe interna poderia perder. O downsides é a falta de controle sobre o escopo e a possibilidade de exposição pública de vulnerabilidades antes da correção.
Checklist mínimo para um teste competente
Antes de iniciar qualquer atividade, tenha autorização por escrito, definindo escopo, horários permitidos e limites de taxa de requisição. Sem isso, você está operando legalmente em área cinzenta. Mapeie todos os endpoints através de crawl automático e coleta manual. Documente tecnologias identificadas, versões e configurações conhecidas. Anote pontos de entrada de dados do usuário, incluindo headers, cookies e parâmetros de URL que costumam ser esquecidos.
Teste cada vetor nas seguintes prioridades: autenticação e autorização, injeção de código, cross-site scripting, file inclusion, server-side request forgery e quebras de lógica de negócio. Para cada vulnerabilidade encontrada, documente passo a passo da exploração, impacto real e recomendação específica. No final, o trabalho não termina quando o scanner para. A qualidade do relatório define o valor do teste. Dados brutos sem contexto não salvam aplicações. Recomendações genéricas como"use prepared statements"não ajudam quando o desenvolvedor já sabe disso mas implementou de forma inconsistente em apenas alguns endpoints. Especificidade é o que separa um relatório útil de um que vai parar na lixeira.
O campo evolve rapidamente. Novas técnicas de evasion aparecem todo trimestre, e framework modernos como Next.js e Svelte criam vetores de ataque diferentes dos tradicionais. Manter-se atualizado não é opcional; é o mínimo para entregar trabalho que não fique obsoleto em seis meses.
