BURP SUITE AUTORIZE: TESTANDO CONTROLES DE ACESSO E AUTORIZAÇÃO

O Burp Suite Autorize é uma extensão voltada à validação manual de controles de acesso. Ela compara uma requisição feita por um usuário privilegiado com a mesma operação reenviada usando a sessão de um usuário com menos privilégios. Assim, o analista consegue investigar falhas de autorização sem repetir todo o fluxo de navegação.

O que é o Autorize?

Autenticação responde a “quem é o usuário?”. Autorização responde a “o que esse usuário pode fazer?”. O Autorize combina essas duas perspectivas — Authenticate + Authorize — e ajuda a verificar se um endpoint realmente aplica as permissões esperadas.

Em uma aplicação com RBAC mal implementado, Broken Access Control, IDOR ou Forced Browsing, um usuário comum pode conseguir acessar funções destinadas a outro perfil. A extensão não substitui a análise de negócio, mas acelera a comparação entre sessões e evidencia comportamentos que merecem investigação.

Como o Autorize funciona

O fluxo usa dois níveis de acesso. Primeiro, capture uma Request com a sessão do usuário de menor privilégio e forneça ao Autorize o cookie, o header Authorization ou o JWT correspondente. Depois, autentique-se como o usuário privilegiado e navegue até uma função administrativa. Para cada Request capturada, o Autorize substitui a credencial, reenvia a operação e compara as Responses.

O resultado é um sinal de triagem: uma Response muito semelhante à obtida pela sessão privilegiada pode indicar bypass, enquanto uma mensagem de bloqueio consistente sugere que a autorização foi aplicada. Em ambos os casos, a confirmação precisa ser manual.

Instalação e compatibilidade

Na interface do Burp, abra Extensions → BApp Store, pesquise por Autorize e confira os requisitos exibidos pela versão disponível. A referência utilizada neste guia mostra a extensão 1.7 e a configuração do Jython Standalone em Extensions settings → Python Environment. Builds atuais podem alterar ou eliminar essa dependência; siga o requisito mostrado no BApp Store e não reutilize uma configuração antiga sem confirmação.

Interface e configuração

O painel mostra, lado a lado, o que a sessão original recebeu e o que a sessão alternativa recebe no mesmo endpoint. Verde/vermelho na tabela do Autorize é hipótese de quebra de autorização — confirme no corpo da resposta antes de reportar. Filtros e Match/Replace vêm a seguir para reduzir falso positivo.

Após a instalação, a aba Autorize reúne os Request/Response Viewers e a área Configuration. Nos viewers, compare a Request original, a modificada com a credencial alternativa e, quando habilitado, a Request sem autenticação. A leitura conjunta de status, headers e corpo é mais útil do que observar apenas a cor do resultado.

Em Configuration, mantenha a extensão desligada enquanto prepara o cenário. Em seguida, adicione um Temporary header com a identidade do usuário de menor privilégio ou use Fetch Cookies header/Fetch Authorization header para obter o valor da última Request capturada. Trate tokens e cookies como segredos de laboratório e remova-os antes de compartilhar evidências.

Detectores, filtros e Match/Replace

O Enforcement Detector descreve como uma Response bloqueada se parece no laboratório. É possível usar uma característica do corpo, header ou código de status. Se endpoints diferentes retornarem mensagens de bloqueio distintas, crie múltiplos filtros e confirme se a combinação deve operar com AND (todas as condições) ou OR (qualquer condição).

O Detector Unauthenticated faz uma comparação adicional com uma Request sem autenticação. Já os Interception Filters limitam o que será processado: por exemplo, somente itens dentro do escopo e exclusão de extensões de imagem ou Requests do spider. Em Match/Replace, uma regra pode substituir um header ou parâmetro antes do reenvio; mantenha a regra restrita ao laboratório para não alterar tráfego fora do teste.

Resultados, filtros de tabela e falsos positivos

O Table Filter organiza os resultados por estado. A nomenclatura varia entre versões, mas a ideia permanece: Bypassed! (possível falha), Is enforced? ou Is enforced! (resultado inconclusivo ou bloqueio reconhecido) e Enforced! (controle aparentemente aplicado). Use as cores somente como triagem e abra os viewers para entender a diferença.

Um status Bypassed! não é prova automática de vulnerabilidade. Compare a Request original, a modificada e a não autenticada; verifique o status HTTP, o corpo, os headers e a regra de negócio. Um endpoint que retorna 200 para uma página pública, por exemplo, pode parecer bypassado sem conceder qualquer privilégio. Registre a evidência e valide o impacto manualmente.

Quando a investigação terminar, use Save/Restore para salvar ou restaurar os dados filtrados. Se a versão instalada oferecer exportação, preserve o arquivo com cuidado: ele pode conter Requests, Responses, cookies, tokens e metadados. Faça a remoção de segredos antes de anexá-lo a um relatório.

Demonstração em laboratório autorizado

Em um laboratório da PortSwigger Web Security Academy ou aplicação local equivalente, autentique o usuário de menor privilégio e capture sua sessão. Configure o valor no Autorize, ative a extensão e só então faça login com o usuário privilegiado. Ao navegar por uma função administrativa, selecione as Requests sinalizadas e compare os três viewers.

GET /admin HTTP/1.1
Host: lab.example
Cookie: session=<valor-fornecido-pelo-laboratorio>

O exemplo acima é deliberadamente sanitizado: use somente o domínio, a sessão e as credenciais fornecidos pelo laboratório. Se a versão privilegiada produzir conteúdo administrativo mesmo depois da substituição do cookie, investigue o caso como possível falha de autorização. Se a Response for uma página de bloqueio consistente, o controle parece funcionar; ainda assim, teste outros endpoints e métodos HTTP.

Conclusão

O Autorize reduz o trabalho repetitivo de comparar sessões, mas seu papel é acelerar a triagem. A conclusão depende da leitura das Requests e Responses, do entendimento do fluxo de autenticação e da validação da regra de negócio. Com filtros restritos, dados sanitizados e um laboratório autorizado, a extensão se torna uma aliada prática para investigar RBAC, IDOR e outros cenários de Broken Access Control.