Um open redirect é uma vulnerabilidade em que uma aplicação web retira um URL de destino de input de utilizador 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 utilizador 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 utilizador, 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 facto 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 utilizador 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á a integrar 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#
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