Sua Primeira Falha Hacker: Open Redirect e Bug Bounty na Prática

O que você vai aprender neste aulão

Se você quer aprender como encontrar sua primeira falha de segurança sem cometer crime, chegou no lugar certo. Nesse aulão eu peguei a vulnerabilidade de Open Redirect — provavelmente a mais amigável para quem está começando — e mostrei do zero como ela funciona, por que empresas pagam recompensa por ela em programas de bug bounty e, acima de tudo, como treinar dentro da lei. Foi um aulão bem prático, com laboratório e desafio ao vivo, e aqui eu transformo tudo isso num material que você lê no seu ritmo.

Antes de qualquer linha técnica, um recado que não é enfeite: testar o sistema dos outros sem permissão é crime no Brasil (o famoso art. 154-A do Código Penal). Tudo o que eu mostro aqui serve para o seu próprio ambiente, para laboratórios feitos para treino e para alvos que estão dentro do escopo de um programa de bug bounty. Combinado? Combinado. Com essa régua clara, dá pra começar a caçar falha de verdade e ainda ser pago por isso.

A lógica de fundo é simples: em vez de decorar ataque, você aprende o pensamento hacker (por que a falha existe, onde ela mora e como ela é abusada) e usa esse raciocínio para reportar e corrigir. Esse é o mesmo caminho que eu segui no Aulão #030 — Bug Bounty, Flipper Zero e os bastidores da equipe, e agora eu aprofundo a parte de encontrar a sua primeira vulnerabilidade paga.

Deixa eu ser honesto sobre o público: esse conteúdo é para quem quer começar no hacking ético, mas é obrigatório para quem programa. Boa parte das aplicações web de hoje tem um redirecionamento em algum canto — depois do login, depois do cadastro, depois de resetar senha. Se você desenvolve, entender essa falha do lado de quem ataca é o atalho para escrever código que não a introduz. Ou seja: o mesmo aulão que forma o caçador de falhas também forma o programador que fecha a porta antes de o caçador chegar.

O que é a falha de Open Redirect (a candidata perfeita para sua primeira falha)

Open Redirect é uma falha em que um site aceita redirecionar o usuário para qualquer endereço, sem validar o destino. O nome assusta mais que o conceito. Deixa eu usar a mesma analogia que eu desenhei ao vivo, porque ela cola na cabeça.

Pensa num app de corrida por aplicativo. No mapa, existe uma área de destinos permitidos — pontos cadastrados, aprovados, dentro da regra. Você toca num deles e o carro te leva. A função por trás é quase isto: uma função enviar que recebe um destino escolhido no clique e leva você até lá. Comportamento padrão, tudo certo.

Mas e se o usuário, em vez de tocar num ponto do mapa, inserir na mão um destino que não estava na lista (digamos, do outro lado do mundo)? Se o app mandar o carro assim mesmo, sem checar, temos o problema. A função assumiu que todo destino viria de um clique confiável e nunca imaginou que alguém fosse inserir um valor por fora. É exatamente isso o Open Redirect: uma função de redirecionamento aberta, que leva a pessoa para qualquer lugar porque confia cegamente no valor recebido.

Na web isso aparece em endereços do tipo site.com/logout?return=/ ou site.com/login?next=/painel. O parâmetro (return, next, url, dest, go_url) guarda o próximo passo do usuário. Por que salvar isso na URL? Porque o HTTP é um protocolo sem memória entre requisições: cada chamada é independente, então, para lembrar que depois do login a pessoa vai ao painel, o valor precisa viajar em algum lugar — e muita gente coloca na URL. Usar parâmetro de redirecionamento não é errado. O erro é a função fazer o que não deveria: aceitar um destino externo sem filtrar. Se quiser entender melhor como um endereço entrega estrutura e comportamento de um sistema, eu destrinchei isso no Aulão #063 — a anatomia de uma URL.

Repare no vocabulário do dia a dia e você vai começar a ver essa função em todo canto. Reset de senha com reset?token=abc&redirect=login. Autenticação com auth?destination=/. Cadastro com signup?success_url=/dashboard. Confirmação de segundo fator com um ?next=/. Nenhum desses é uma falha por si só — são padrões legítimos de fluxo. A vulnerabilidade nasce no momento em que o valor de destino pode ser trocado por um endereço de fora e o sistema obedece. E é justamente por serem tão comuns que esses parâmetros valem o primeiro olhar de quem está começando: você tem onde treinar de sobra dentro de escopo autorizado.

No fundo, uma função é só um bloco de código reutilizável que recebe um valor e devolve um resultado. Se eu escrevo uma função de soma esperando um número e o usuário manda uma letra, o código quebra. Com o redirecionamento é a mesma história: a função espera um caminho interno seguro e recebe um endereço externo malicioso. Quem confia no que chega, aceita o que não deveria. Essa desconfiança saudável com a entrada do usuário é o coração de quase toda vulnerabilidade web.

Como encontrar sua primeira falha sem virar criminoso: escopo e bug bounty

Aqui está a parte que separa o hacker ético do bandido. A técnica é a mesma; o que muda é a autorização. Bug bounty é o acordo em que a empresa publica um programa dizendo: "pode testar estes alvos, destas formas, e eu pago por falha válida". Isso te dá permissão por escrito para procurar vulnerabilidade — e é o jeito certo de começar.

As duas maiores plataformas para isso são o HackerOne e o Bugcrowd. Você cria conta, escolhe um programa, lê o escopo com calma e só testa o que está autorizado. E HackerOne, além de intermediar o pagamento, ainda publica relatórios reais que servem de estudo. E Bugcrowd funciona de forma parecida, com programas para todos os níveis.

O escopo é a lei do jogo. Ele diz quais domínios entram, quais estão de fora, quais tipos de teste são proibidos (nada de negação de serviço, nada de engenharia social contra funcionários, por exemplo) e como reportar. Ler escopo é a habilidade que ninguém elogia e todo mundo precisa. Um alvo fora do escopo, mesmo que você ache uma falha linda, não vale recompensa — e pode te colocar em situação legal ruim. Mapear o que é parte do alvo, incluindo domínios e subdomínios, é meio caminho andado; eu mostrei técnicas disso no Aulão #028 — como encontrar subdomínios escondidos.

Fora do bug bounty, você ainda tem dois campos totalmente legais para treinar: laboratórios feitos para isso (como o que eu montei na live, o meubank.online, um ambiente de mentira só para exercício) e plataformas de treino. Nada de apontar sua curiosidade para o site do vizinho. Vale a pena começar por aqui? Vale, e muito — é onde você erra sem consequência.

Onde essa falha aparece: reconhecendo redirecionamentos abertos

No aulão eu mostrei quatro formas de reconhecer um redirecionamento aberto, e reconhecer é o primeiro passo tanto para reportar quanto para consertar o seu próprio sistema.

A primeira é olhar o link com atenção. Passando o mouse por cima de um botão, o preview do endereço aparece no canto da tela; clicando com o botão direito e copiando o destino, você vê o parâmetro de redirecionamento inteiro. No laboratório, o botão levava para algo como meubank.online/?redirect_url=login. Trocando login por um endereço externo, a página obedecia. Ali está a função aberta, escancarada.

A segunda é inspecionar a página. Abrindo o painel de desenvolvedor do browser (botão direito, inspecionar) e indo na aba Network, você vê cada requisição que a página dispara. Uma dica que eu sempre dou: marque a opção "Preserve log" para não perder o histórico quando a página muda. Assim você flagra redirecionamentos que somem rápido.

Mas nem toda falha aparece na URL. E aqui entra a terceira forma, que é a mais importante para quem quer sair do básico: o redirecionamento por POST. Quando o destino viaja dentro de um formulário (num parâmetro tipo go_url), passar o mouse não mostra nada, copiar o link não mostra nada. A única forma de enxergar é justamente a aba Network, olhando a requisição POST e o valor enviado. Foi esse o cenário que eu deixei no desafio, de propósito, para obrigar o pessoal a usar o console de verdade.

A quarta forma é entender padrões. Programador é humano e repete nomes: return, next, dest, url, redirect, continue, success_url, go_url. Conhecer esse vocabulário é o que transforma busca aleatória em busca dirigida. E existem listas públicas (as chamadas wordlists) que compilam esses nomes justamente para automação em testes autorizados. Reconhecer padrão de nomenclatura também é a base para investigar qualquer site, algo que eu explorei no Aulão #036 — técnicas para investigar sites.

Por que o Open Redirect é perigoso: phishing e abuso de confiança

"Bruno, redirecionar para outro site é tão grave assim?" É, e o motivo é confiança. O perigo não está no redirecionamento em si, e sim em usar a reputação de um domínio legítimo para enganar gente.

Imagina um endereço que começa com o domínio oficial do seu banco, com cadeado, com autoridade, que não cai no spam — e que, por causa de um redirecionamento aberto, joga a vítima numa página de phishing idêntica logo após o login. A pessoa nem percebe que saiu do site verdadeiro. Escala dali para roubo de sessão, captura de credenciais e ataques mais elaborados. Essa é a ponte entre Open Redirect e as fraudes que eu detalhei no Aulão #058 — como se proteger de phishing e engenharia social.

Isso não é teoria. No HackerOne existe um fluxo diário de relatórios de Open Redirect em nomes grandes — companhias aéreas, redes sociais, plataformas de mídia. Um caso clássico que eu mostrei foi o do Flickr: depois de um upgrade, um parâmetro continue permitia usar o domínio da própria empresa para apontar para fora. E Google indexa esses parâmetros aos milhares, o que criminosos exploram para abusar de reputação de domínio em campanhas de spam. No Brasil já rolou onda de sites gov.br de prefeituras e órgãos redirecionando para casas de aposta — pura exploração da confiança de um domínio oficial. Reconhecer esse abuso é o que te faz um defensor melhor, e é por isso que essa falha, apesar de "simples", paga.

Filtros, blacklists e bypass: por que blacklist não é defesa de verdade

Quando o programador percebe o problema, a reação comum é criar uma blacklist: "não pode ter ponto no destino, assim ninguém escreve um domínio externo". No laboratório, foi exatamente o que um dos exemplos fazia — bloqueava o caractere de ponto e devolvia "destino não autorizado".

O problema é que blacklist parte do princípio errado: tentar adivinhar tudo o que é ruim. E a web tem tantas maneiras de representar o mesmo caractere (codificação de URL, codificação dupla, caracteres especiais, formas alternativas de escrever um endereço) que sempre sobra uma brecha. É esse o conceito de bypass: contornar o filtro reescrevendo o valor de um jeito que o sistema não previu. Eu não vou te dar a string pronta aqui — isso é lição de casa dentro de laboratório e de escopo autorizado, nunca contra alvo aleatório. O que interessa para você, como defensor, é a conclusão: se a defesa depende de proibir "o que é ruim", ela vai falhar.

A defesa que funciona é a inversa, e OWASP bate nessa tecla faz tempo. E OWASP recomenda o caminho contrário da blacklist: usar uma allowlist (lista do que é permitido). Na prática, isso vira duas regras diretas:

• Nunca redirecione para um valor cru vindo do usuário — mapeie entradas para destinos internos conhecidos (um índice de rotas, por exemplo).
• Se precisar mesmo aceitar destino dinâmico, valide o host contra uma lista aprovada e aceite apenas caminhos relativos do próprio domínio.

O princípio que amarra tudo é o mais antigo do hacking: nunca confie no valor que o usuário insere, esteja ele na URL, no corpo do POST, no cookie ou em qualquer camada. Nós, do lado ético, existimos justamente para provar que essa confiança cega quebra — e para mostrar como blindar.

Como reportar e ganhar recompensa em bug bounty

Achar a falha é metade do trabalho. A outra metade, a que efetivamente te paga, é reportar bem. Um relatório fraco de uma falha boa some na fila; um relatório claro de uma falha simples é aprovado rápido.

Um bom report de Open Redirect costuma ter estes elementos:

• O endereço afetado e o parâmetro exato onde o redirecionamento acontece.
• Passo a passo curto para reproduzir, com uma prova de conceito que aponte para um destino inofensivo (nada de mandar vítima real para lugar nenhum).
• O impacto explicado em linguagem de negócio: phishing usando o domínio da empresa, abuso de reputação, possível roubo de sessão.
• A recomendação de correção (allowlist de destinos, validação de host, caminhos relativos).
• Evidência visual, como captura de tela ou gravação, mostrando o redirecionamento para um domínio externo controlado por você.

Sobre valores: Open Redirect costuma ser classificado como severidade baixa a média, então não espere as maiores recompensas do programa. Mas é um volume honesto de recompensas menores, ótimo para construir reputação, subir no ranking da plataforma e destravar convites para programas privados (onde mora o dinheiro grande). E a regra de ouro é a divulgação responsável: você reporta, dá tempo para a empresa corrigir e só torna público quando (e se) o programa permitir. Iniciativas como a do disclose.io padronizam essa ética. Quer entender o valor de mapear exposição antes de reportar? Eu mostrei no Aulão #020 — Shodan para achar dispositivos e serviços expostos.

Uma coisa que segura muita gente no começo é o medo de reportar "pouco". Não caia nessa. Dá pra fazer isso em qualquer site? Não — mas dentro de um programa, uma falha pequena bem documentada mostra que você entende impacto, sabe escrever e respeita o escopo. É esse histórico que faz a empresa te chamar para o próximo teste. Eu já vi gente construir carreira inteira em segurança ofensiva começando por uma pilha de Open Redirects reportados com capricho. O primeiro relatório é sempre o mais difícil; o décimo já é rotina. Comece pequeno, seja consistente e trate cada report como um cartão de visita.

Ferramentas para praticar e caçar Open Redirect com autorização

No aulão eu citei os apoios que uso e recomendo. Todos servem para treino em laboratório ou para testes dentro de escopo — nunca para sair atirando. Se você ainda está montando seu ambiente, eu ensino a base no Aulão #015 — Linux para iniciantes, do zero ao servidor.

Ferramenta	Para que serve	Como usar com ética
HackerOne	Plataforma de bug bounty e leitura de relatórios reais	Escolha programas com escopo público e comece pelos alvos permitidos
Bugcrowd	Plataforma de bug bounty com programas para iniciantes	Filtre por programas abertos e leia as regras antes de testar
PortSwigger Web Security Academy	Laboratórios gratuitos de web hacking, incluindo redirecionamento	Treine à vontade: os labs foram feitos para você atacar
Burp Suite	Interceptar e inspecionar requisições HTTP	Use para enxergar redirecionamentos por POST em alvos autorizados
OWASP ZAP	Proxy de segurança open source (o antigo ASP ZAP)	Alternativa gratuita para analisar requisições em treino
ffuf	Fuzzing rápido de parâmetros e caminhos	Automatize testes de parâmetros só em escopo permitido
SecLists	Coleção de wordlists, com listas de parâmetros de redirect	Alimente suas ferramentas com nomes de parâmetros conhecidos
TryHackMe	Trilhas práticas de segurança para começar do zero	Faça as salas guiadas antes de encarar um programa real

Uma observação sobre busca com Google: dá para encontrar parâmetros de redirecionamento com operadores avançados (os Google Dorks), e criminosos abusam disso para achar alvos em massa. Do lado ético, isso serve para reconhecimento apenas dentro do seu escopo. Eu mostrei o poder (e o perigo) desses operadores no Aulão #008 — buscas perigosas com Google Hacking.

Perguntas Frequentes

Open Redirect é uma boa primeira falha para quem está começando?

É uma das melhores. O conceito é intuitivo, ela aparece em muitas aplicações e paga recompensa em bug bounty. Dá pra entender o pensamento por trás dela e aplicar em outras vulnerabilidades depois.

Preciso saber programar para encontrar essa falha?

Não para reconhecer, sim para dominar. Você acha um redirecionamento aberto só olhando a URL e a aba Network. Mas entender a função por trás (ler um pouco de código) te faz reportar melhor e enxergar falhas que ficam escondidas.

É legal testar Open Redirect em qualquer site?

Não. Testar sem autorização é crime pelo art. 154-A do Código Penal. Só teste em laboratórios de treino, em ambientes seus ou em alvos dentro do escopo de um programa de bug bounty.

Quanto paga um Open Redirect em bug bounty?

Costuma ser severidade baixa a média, então a recompensa individual não é a maior do programa. O ganho vem do volume e da reputação: relatórios válidos te destravam convites para programas privados mais bem pagos.

Como eu monto um ambiente para praticar sem risco?

Use laboratórios prontos, como os da PortSwigger Web Security Academy e do TryHackMe, ou suba uma aplicação de teste na sua própria máquina. Foi o que eu fiz na live com o meubank.online, um alvo fictício criado só para exercício.

Qual a diferença entre Open Redirect por GET e por POST?

No GET, o destino viaja na URL e você o vê passando o mouse ou copiando o link. No POST, o destino vai dentro de um formulário e só aparece na aba Network do browser. O segundo é mais fácil de passar despercebido, por isso vale treinar o olho nele.

Referências e Recursos

• OWASP — Unvalidated Redirects and Forwards Cheat Sheet
• PortSwigger — Open redirection (Web Security Academy)
• CWE-601 — URL Redirection to Untrusted Site
• HackerOne — Hacktivity (relatórios públicos)
• Bugcrowd — plataforma de bug bounty
• disclose.io — padrões de divulgação responsável
• Flask — framework usado no laboratório