Ferramentas de desenvolvedor · Codificador e decodificador URL
Codificando um redirecionamento URL dentro de um parâmetro de consulta sem quebrá-lo
· Como funciona
codificação de URL parâmetros de consulta segurança oauth
Aninhar um URL dentro de outro é o lugar mais comum em que a codificação percentual dá errado. Esta postagem mostra por que os URL internos?, & e = devem ser codificados, como fazer isso e como verificar o resultado.
O link de retorno que eliminou metade de seus parâmetros - um URL interno e engolido pela string de consulta externa
O link de retorno que eliminou metade de seus parâmetros é um padrão de depuração que todo desenvolvedor encontra. Um usuário faz login, o aplicativo tenta redirecionar para ?next=https://example.com/page?id=1&user=alice, e termina em example.com/page?id=1. O e comercial no URL interno foi analisado como um separador entre os parâmetros de consulta externos. Dois URLs com delimitadores diferentes significam que o interno deve ser codificado.
Ao aninhar um URL dentro de outro como parâmetro de consulta, esse endereço interno torna-se um dado opaco para a camada externa. O ponto de interrogação, o e comercial e o sinal de igual não devem ser legíveis como delimitadores estruturais. A codificação percentual os transforma: ? torna-se %3F e torna-se %26, = torna-se %3D. O analisador externo trata então a string codificada como um valor de parâmetro.
Dois URLs, dois conjuntos de delimitadores — por que o URL interno é apenas um valor para o externo
encodeURIComponent no URL interno completo produz proteção total: encodeURIComponent("https://example.com/a?b=1&c=2") retorna "https%3A%2F%2Fexample.com%2Fa%3Fb%3D1%26c%3D2". Cada caractere estrutural se torna %XX para que o analisador externo não possa interpretar mal os delimitadores aninhados. Uma abordagem concorrente como encodeURI deixa barras e pontos de interrogação intactos, reintroduzindo a ambiguidade quando esse resultado se torna um valor de consulta.
O servidor decodifica exatamente uma vez. Depois de extrair o próximo parâmetro, uma única chamada decodeURIComponent restaura o URL interno à sua forma original. Analisar o resultado como uma nova string de consulta vê a estrutura de parâmetros correta. A decodificação dupla é um risco quando o mesmo valor passa por múltiplas camadas; %26 torna-se & após uma decodificação e permanece & após a segunda.
encodeURIComponent em todo o URL interno - o que é codificado, incluindo:, / e ?
A regra básica é simples: qualquer caractere que tenha significado na sintaxe URL, incluindo: /? = & #, deve ser codificado em porcentagem quando aparece em um valor de parâmetro de consulta. Isso garante que o analisador externo veja apenas a estrutura de parâmetros pretendida e não quaisquer delimitadores acidentais ocultos dentro do valor que você está passando. Use encodeURIComponent para lidar com essa codificação de forma completa e confiável.
Teste esta codificação no codificador e decodificador URL: cole o URL interno, codifique-o no modo de valor, observe a saída %XX. Use o modo decodificador para verificar se as correspondências de ida e volta correspondem exatamente. Esta ferramenta demonstra a codificação de ponta a ponta para que você possa copiar os resultados diretamente no código do seu aplicativo com confiança.
Exemplo resolvido: construindo ?next=https://example.com/a?b=1&c=2 corretamente - a string codificada e a decodificação no lado do servidor
Um limite crítico de segurança acompanha a codificação. O servidor deve validar se o destino decodificado é realmente seguro para redirecionamento. A codificação percentual torna a estrutura URL inequívoca; isso não torna URLs arbitrários seguros. Vulnerabilidades de redirecionamento aberto ocorrem quando os aplicativos seguem cegamente URLs fornecidos pelo usuário. A validação requer uma lista de permissões explícita, verificação de domínio ou confirmação do usuário.
A codificação corrige o problema de análise; a validação corrige o problema de segurança. Estas são preocupações separadas em diferentes camadas. O codificador e decodificador URL demonstra a codificação corretamente. Um servidor deve adicionar validação: verificar uma lista, verificar o domínio ou solicitar confirmação. Sem validação, um redirecionamento devidamente codificado para qualquer domínio permanece explorável.
Risco de redirecionamento aberto — por que o servidor deve validar o destino decodificado, e não apenas decodificá-lo
Erros comuns se acumulam aqui. Às vezes, os desenvolvedores codificam apenas a parte da consulta, deixando as barras intactas, o que quebra a estrutura. Outros codificam todo o parâmetro construído, incluindo ?next=, criando codificação dupla. Alguns verificam a validade analisando sem decodificar, interpretando mal a estrutura codificada. Construir com encodeURIComponent garante consistência e correção em todos os casos.
Outro erro comum é confiar que o navegador corrigirá automaticamente um parâmetro malformado. URLs são dados e devem ser tratados precisamente como dados. encodeURIComponent é a ferramenta padrão para este trabalho. O codificador e decodificador URL mantém esse processo local para que você possa verificar os bytes exatos antes de enviar para produção.
Erros comuns – codificar apenas a parte da consulta ou confiar no navegador para corrigi-la
Os parâmetros redirecionamento_uri do OAuth seguem exatamente esse mesmo padrão. O servidor de autorização passa o controle para um cliente em um endereço conhecido, geralmente um URL completo com vários parâmetros. Codificá-lo como um valor único garante que os parâmetros sobrevivam ao transporte e que o cliente seja decodificado uma vez antes do uso. A codificação incorreta em fluxos OAuth faz com que tokens e parâmetros de retorno de chamada desapareçam no meio da transmissão.
Os parâmetros de estado no OAuth usam codificação combinada com assinaturas criptográficas para proteção CSRF. Os identificadores de fragmento permanecem no lado do cliente e nunca viajam para o servidor. Os tokens de portador nunca devem ser colocados em URLs de redirecionamento, independentemente da codificação, porque os URLs aparecem em logs, histórico do navegador e cabeçalhos de referência.
O que isso não cobre — parâmetros de estado OAuth e design de proteção CSRF
Estratégia de teste: construa seu URL interno com parâmetros reais, codifique-o como um valor externo e decodifique-o no código de recebimento. Verifique se o resultado decodificado é byte por byte idêntico ao original. Use o codificador e decodificador URL antes da implantação de produção. Examine o tráfego e os logs da rede para confirmar a chegada correta e nenhum truncamento ou confusão dos dados codificados.
Um erro de digitação como %2e em vez de %2E pode ser decodificado corretamente, mas falhar nas verificações de ida e volta em sistemas secundários que esperam consistência. As incompatibilidades de codificação entre bibliotecas em diferentes plataformas são raras, mas possíveis; testar a viagem completa de ida e volta os detecta antes que causem problemas de produção e reclamações dos clientes.
Conclusão: trate o URL interno como dados - como o modo de valor único do codificador e decodificador URL o codifica completamente e seu decodificador confirma a viagem de ida e volta
O limite de codificação é claro: encodeURIComponent trata sua entrada como dados opacos e escapa de todos os caracteres, exceto pontuação não reservada, tornando seguro aninhar em qualquer camada URL. O limite de validação é separado: após a decodificação, verifique se o destino é para onde o usuário pretendia ir. Use o codificador e decodificador URL para ver a codificação demonstrada de ponta a ponta.
Trate o URL interno como dados desde o início. Codifique-o como um único valor de consulta, decodifique exatamente uma vez quando recebido e aplique a validação antes de redirecionar. O codificador e decodificador URL mostra a codificação percentual de qualquer URL completo como um único valor de consulta e verifica as viagens de ida e volta localmente. Tanto a codificação quanto a validação são essenciais; esta ferramenta lida com a codificação corretamente.