Testar bugs web comuns com ajuda de IA

Com uma lista conferida de endpoints de ler o JavaScript, você pode começar a testar bugs de verdade. Este post cobre quatro classes que um iniciante encontra cedo: IDOR, cross-site scripting, server-side request forgery e autenticação quebrada. O modelo ajuda você a ler responses e decidir o próximo teste. Você roda cada request e confirma cada finding na mão. Mantenha todo teste nos hosts que o programa lista, e use uma cópia local do app para qualquer coisa barulhenta.

#Como usar o modelo durante o teste

O modelo é um segundo par de olhos em uma response. Cole um request e a response dele e pergunte o que o servidor parece fazer com a sua entrada, o que um app seguro retornaria no lugar e qual mudança única diria mais. Ele é rápido nisso e às vezes vai estar errado com confiança, então cada resposta é uma hipótese que você testa, não uma conclusão que você reporta. O OWASP Web Security Testing Guide tem o procedimento completo para cada classe abaixo.

Classe	A pergunta que você faz	Como você confirma
IDOR	Consigo alcançar o objeto de outro usuário?	Duas contas, troque o id, compare as responses
XSS	Minha entrada roda como código?	A entrada refletida executa em um browser real
SSRF	O servidor vai buscar uma URL que eu escolho?	Um host que você controla loga o request do servidor
Auth quebrada	Consigo agir sem a sessão certa?	Um request sem token ou com o papel errado funciona

#IDOR: mude o identificador, leia a response

Insecure direct object reference é o bug mais amigável para quem começa. Ache um request com um identificador dentro, como /api/orders/1051, e mude o número. Se você recebe de volta o pedido de outro usuário, o app não está checando quem é o dono. O jeito limpo de provar é com duas contas que você controla: busque o seu próprio objeto, depois tente o identificador da outra conta a partir da sua sessão, e compare. O modelo ajuda você a enxergar quais campos são identificadores e quais responses diferem de um jeito que importa.

#XSS: onde a entrada volta como código

Cross-site scripting acontece quando a entrada que você manda é devolvida a uma página sem ser codificada, então o browser a roda como script. Seu trabalho no teste é achar um lugar onde a entrada reflete na response e checar se ela segue como dado ou vira código. Uma string marcadora inofensiva diz se, e como, a sua entrada é codificada. Cross-site scripting explicado tem o detalhe. O modelo é útil para ler como um valor é refletido e onde falta codificação, mas só um browser real prova execução, então confirme ali.

#SSRF: onde o servidor busca uma URL

Server-side request forgery acontece quando o app pega uma URL de você e o servidor a busca. Procure recursos que puxam um recurso remoto: uma imagem por URL, um webhook, um preview de link. Para testar com segurança, aponte o recurso para um host que você controla e observe os seus próprios logs pelo request do servidor. Se o servidor sai buscando, você confirmou o comportamento, e o impacto depende do que a rede do servidor consegue alcançar. Descreva só o que você provou, e não saia caçando serviços internos além do que o programa permite.

#Autenticação e controle de acesso quebrados

Esta classe cobre requests que deveriam precisar de uma sessão válida ou de um papel específico e não precisam. Pegue um request autenticado, remova o token ou troque por uma conta de menor privilégio, e veja se ainda funciona. Bugs de controle de acesso são comuns, muitas vezes de alto impacto e fáceis de provar com duas contas. O modelo pode ajudar você a enumerar quais ações retentar sem sessão, a partir da lista de endpoints que você montou antes.

#Confirme antes de acreditar

A maior parte do tempo perdido no primeiro mês de um iniciante vai para falso positivo que o modelo incentivou. Três hábitos evitam isso. Reproduza o bug a partir de um estado limpo para saber que é real e não um defeito em cache. Mude uma variável de cada vez para saber o que causou o resultado. Guarde o request e a response exatos que provam, porque é isso que o relatório precisa e o que o triager vai rodar de novo. Se você não reproduz sob demanda, ainda não é um finding.

#A seguir nesta trilha

APIs merecem o próprio método. Teste de API com IA cobre OpenAPI e GraphQL. O OWASP Top 10 e a PortSwigger Web Security Academy são as referências para trabalhar em cada classe.