Um open redirect é uma vulnerabilidade em que uma aplicação web retira um URL de destino de input de usuário não validado - normalmente um parâmetro de consulta como ?next= ou ?url= - e encaminha o navegador para lá sem o verificar. O link começa num domínio em que a vítima confia, por isso passa na inspeção, e depois leva-a silenciosamente para outro sítio. A correção não é parar de redirecionar. É parar de deixar o pedido decidir para onde vai o redirect.
Essa distinção importa porque os redirects estão por toda a parte e a maioria deles está bem. Iniciar sessão e voltar à página que queria, passar para um fornecedor de pagamentos, um callback OAuth - tudo normal, tudo redirects. A falha, catalogada como CWE-601 e agrupada sob controlo de acesso quebrado no OWASP Top 10, é especificamente o caso em que o destino vem de input controlado pelo usuário e nada o valida primeiro. Um atacante fornece o seu próprio URL, o site de confiança encaminha para lá, e a confiança transfere-se com o clique.
Passo os meus dias no caminho do redirect, por isso este é um tema sobre o qual tenho opiniões. Os links curtos são redirects por definição, o que torna "será que um encurtador é apenas um open redirect?" uma pergunta justa - e a resposta, bem feita, é um claro não. Lá chegamos abaixo. Se a mecânica dos redirects é nova para si, tipos de redirects é o guia introdutório, e como funcionam os encurtadores de URL cobre os fundamentos da camada de redirect.
O Que Um Open Redirect é Realmente
Reduza-o ao mecanismo. Uma página aceita um parâmetro que indica para onde ir a seguir, e usa-o num redirect HTTP sem confirmar que aponta para algum lugar permitido.
https://trusted.example/login?next=https://evil.example/fake-login
A vítima vê trusted.example à frente e clica. Após o login, a aplicação lê next e emite um redirect para evil.example. O navegador obedece, porque um redirect é apenas um cabeçalho Location e um estado 3xx - a especificação HTTP define esse comportamento claramente e o navegador não tem forma de saber que este destino em particular é hostil. O usuário, a ver a barra de endereço mudar depois de já ter confiado no link, muitas vezes não repara.
O OWASP descreve o perigo central sem rodeios: o nome do servidor no link modificado é idêntico ao do site original, o que dá credibilidade a um redirect malicioso. A vulnerabilidade não é o site redirecionar. É que um estranho escolheu o destino.
Porque Um Redirect "Inofensivo" é Uma Ameaça Real
O reflexo é encolher os ombros: então envia alguém para outro site, qual é o problema. O problema é a confiança emprestada, e ela escala.
O phishing é o uso de destaque. Um link que começa com um banco, um login de SaaS ou um portal governamental passa pela verificação visual rápida que a maioria das pessoas faz, e por um número surpreendente de filtros automáticos que só inspecionam o domínio inicial. A vítima chega a uma falsificação pixel a pixel da página de login que esperava, num domínio que parecia certo um salto atrás, e escreve a sua palavra-passe. Sem malware, sem payload exótico - apenas um redirect e um clone.
Piora quando os redirects ficam perto da autenticação. Um open redirect num fluxo OAuth pode vazar um código de autorização ou token para um redirect_uri controlado pelo atacante, o que escala uma falha "menor" para apropriação total de conta. É por isso que os open redirects são um elemento básico dos relatórios de bug-bounty em vez de uma nota de rodapé. O mesmo truque também branqueia reputação: spammers e operadores de malware adoram saltar por um domínio de confiança porque passa o seu link real pelas listas de bloqueio. Cobrimos a categoria mais ampla na checklist de segurança de encurtadores de URL, e o ângulo da confiança do lado do visitante em os encurtadores de URL são seguros.
Como Prevenir Open Redirects
Existe uma hierarquia de correções, e o topo dela é a que de fato acaba com o problema. A cheat sheet do OWASP ordena-as, e vale a pena seguir a ordem.
- Não retire de todo um URL do pedido. Faça com que o cliente envie um nome curto, ID ou token, e resolva-o para o destino completo do lado do servidor. O OWASP chama a isto o grau de proteção mais elevado, porque o pedido recebido já não pode nomear um destino arbitrário. Se esse padrão soa familiar, devia: é assim que funciona um encurtador de URL.
- Use lista de permissões, não lista de bloqueio. Quando tiver de aceitar um destino, verifique-o face a uma lista de hosts de confiança ou a uma regex estrita. A lista de permissões falha de forma fechada - qualquer coisa não explicitamente permitida é rejeitada. A lista de bloqueio falha de forma aberta, e os atacantes são pagos para encontrar as entradas que se esqueceu.
- Faça a análise de forma rigorosa. Rejeite URLs relativos ao protocolo (
//evil.example), normalize as barras invertidas, descodifique antes de validar, e trate o host - não apenas o prefixo da string - como a coisa a verificar. A maioria dos contornos de filtros vive numa análise preguiçosa. - Mostre uma página intermédia como salvaguarda. Se um redirect para um site externo for inevitável, encaminhe-o por uma página que nomeie o destino e peça ao usuário para confirmar. É atrito, mas converte um redirect silencioso num informado.
O tema recorrente é que os redirects seguros são decididos pelo servidor, a partir de dados em que o servidor já confia - nunca por qualquer string que chegou na consulta.
Se está integrando redirects num produto e prefere não ser dono deste modo de falha, a plataforma de programadores da Elido mapeia códigos para destinos do lado do servidor por design - comece pelo guia rápido da API e nunca mais improvise um parâmetro ?url=.
Porque os Links Curtos São a Defesa, Não a Falha
Eis a parte que surpreende as pessoas. Um encurtador de URL corretamente construído é a implementação de manual da correção número um de open redirect do OWASP.
Quando um link curto é criado, o seu destino é validado e armazenado do lado do servidor, associado a um código curto. Quando alguém o visita, a camada de redirect procura esse código e encaminha para o destino armazenado. O destino nunca vem do pedido recebido - o visitante não pode acrescentar um ?url= e desviar o link para outro lado, porque não existe tal parâmetro para desviar. É exatamente o mapeamento de token para URL que o OWASP recomenda, a correr em produção milhões de vezes por dia. Arquiteturalmente isto vive na nossa camada de redirect na edge, e o orçamento de latência que isso paga é o assunto de atingir p95 abaixo de 15ms para redirects.
A ressalva honesta: um encurtador ainda pode ser abusado, só que não via open redirect. Se uma plataforma permite que qualquer pessoa crie links para qualquer coisa sem análise ou moderação, os atacantes usarão a sua reputação de domínio para mascarar os seus próprios destinos maliciosos - razão pela qual os encurtadores responsáveis analisam os destinos e aplicam políticas de abuso. Isso é um problema de moderação de conteúdo, distinto da falha de validação de input de que trata este artigo, e que vale a pena não confundir. A prática relacionada de esconder deliberadamente um destino é abordada em cloaking de links e mascaramento de URL explicado, e o primo de engenharia social de tudo isto - códigos QR hostis - em os códigos QR são seguros.
A Conclusão Numa Linha
Se o seu código lê um destino a partir do pedido e redireciona para lá, tem um open redirect à espera de ser encontrado. Mapeie antes um ID para um destino do lado do servidor, use lista de permissões para tudo o que não pode evitar retirar do input, e faça a análise como se esperasse ser atacado. Os redirects não são o risco. Deixar o pedido escolher para onde vão é que é. A diferença entre um 301 e um 302 em 301 vs 302 redirects é uma nota de rodapé ao lado dessa única regra.
Relacionado no Blog
Perguntas frequentes
O que é uma vulnerabilidade de open redirect?
Um open redirect é uma falha em que uma aplicação web envia os utilizadores para um URL de destino retirado de input não validado, normalmente um parâmetro de consulta como ?next= ou ?url=. Como o link começa num domínio de confiança, o navegador da vítima e qualquer filtro de análise de links tratam-no como seguro, mas a aplicação encaminha-os depois para qualquer site que o parâmetro indique - incluindo o de um atacante. É classificado como CWE-601 e enquadra-se em controlo de acesso quebrado no OWASP Top 10. A falha é a verificação em falta, não o redirect em si.
Porque são os open redirects perigosos se só o enviam para outro site?
Porque o perigo é a confiança que o domínio inicial empresta. Um link de phishing que diz https://trusted-bank.example/login?next=evil.example passa no teste visual, sobrevive a muitos filtros de email e leva a vítima a uma página de login falsa convincente - tudo enquanto parece vir do banco verdadeiro. Os open redirects também se encadeiam em ataques maiores: podem vazar códigos de autorização ou tokens OAuth quando o destino do redirect é controlado pelo atacante, transformando uma falha de baixa severidade em apropriação de conta. O redirect é o mecanismo de entrega, não o exploit inteiro.
Os encurtadores de URL são uma vulnerabilidade de open redirect?
Não, não quando construídos corretamente - e a distinção é o ponto. Um open redirect retira um destino arbitrário do input do utilizador no momento do pedido e encaminha para lá sem validação. Um link curto mapeia um código fixo para um destino que foi definido e armazenado do lado do servidor quando o link foi criado; o destino do redirect nunca vem do pedido recebido. Esse mapeamento do lado do servidor é exatamente a defesa que o OWASP recomenda contra open redirects. Um encurtador só se torna um problema se permitir que utilizadores não auditados criem links para qualquer coisa e lhes empreste uma reputação de domínio de que possam abusar - o que é uma questão de abuso e moderação, não uma falha de open redirect.
Como se previnem as vulnerabilidades de open redirect?
A correção mais forte é nunca aceitar de todo um URL de destino a partir do pedido. Faça com que o cliente envie um nome curto, ID ou token, e mapeie-o para o destino completo do lado do servidor - o mesmo modelo que um encurtador de URL usa. Quando tem mesmo de aceitar um URL, valide-o face a uma lista de permissões de hosts de confiança em vez de uma lista de bloqueio de maus, rejeite qualquer coisa que não seja um caminho relativo ou um domínio aprovado, e seja rigoroso na análise para que truques como //evil.example ou barras invertidas não passem. Em último recurso, encaminhe o redirect por uma página intermédia que mostre o destino antes de enviar o utilizador.
Como exploram os atacantes um open redirect?
Encontram um endpoint que reflete um parâmetro de URL num redirect, depois criam um link no domínio de confiança com o seu próprio site nesse parâmetro e distribuem-no por email, anúncio ou mensagem. As variações incluem codificar em URL o payload para contornar filtros fracos, usar URLs relativos ao protocolo como //attacker.example, explorar apenas a porção do host mantendo um caminho de aparência legítima, e abusar do tratamento do redirect_uri do OAuth para capturar tokens. O fio comum é que a vítima vê e confia no primeiro domínio e nunca vê o segundo até ser tarde demais.
Um open redirect é uma vulnerabilidade de severidade alta ou baixa?
Por si só, um open redirect é muitas vezes classificado de baixo a médio, porque não compromete diretamente o servidor - envia os utilizadores para outro lado. Mas a severidade depende daquilo em que se encadeia. Perto de um fluxo de autenticação pode vazar tokens OAuth e levar à apropriação de conta, o que é severidade alta; como auxiliar de phishing pode causar perda real de credenciais que uma pontuação CVSS não capta. Trate-o pelo impacto no contexto, não pelo rótulo base, e corrija-o de qualquer forma: a mitigação é barata e o potencial de abuso não é.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Grátis, sem necessidade de registo · 2 por dia