Analisar URL

A separação vem da interface `URL` embutida e não de uma expressão regular escrita à mão. Esse é o ponto em que as ferramentas desse gênero se separam: a especificação da WHATWG é cheia de regras que ninguém suspeita ao montar as suas próprias, e é nessas regras que moram os erros interessantes.

Um exemplo é a normalização do host: o uso de maiúsculas é unificado, um ponto final é removido e os nomes internacionalizados são convertidos para Punycode. Uma expressão regular deixa tudo como está, e então aponta uma diferença entre dois endereços que para qualquer navegador são o mesmo.

Em `https://[email protected]/` o host é `malicioso.example` e não `exemplo.com`: tudo o que vem antes da arroba são credenciais. Está conforme a norma e é a base de uma das técnicas de phishing mais antigas que existem, porque o olho para no primeiro nome conhecido.

Por isso o host tem aqui uma linha só dele. Quem está conferindo um endereço suspeito não precisa contar, só ler para onde ele aponta de verdade. E vem no mesmo pacote: um nome como `exemplo.com.malicioso.example` também é um endereço em `malicioso.example`, porque quem manda é o último par de rótulos.

O endereço é separado, não aberto. Não há requisição ao host, não há prévia e não há resolução de redirecionamento, e isso é uma decisão e não uma função que falta: quem está examinando uma URL suspeita é a última pessoa que quer que a ferramenta a visite.

Visitar ainda entregaria alguma coisa. A requisição sairia de um servidor, o IP e o horário dele ficariam no log do outro lado, e com um endereço de uso único — um link de confirmação, uma redefinição de senha — ela gastaria o link no caminho. Separar é a operação inofensiva, e é a única que acontece aqui.

Um `..` no caminho é resolvido na análise: `/docs/a/../b` vira `/docs/b`. Faz parte da normalização e não é algo que esta ferramenta acrescente — qualquer navegador faz isso antes de disparar a requisição, e um servidor nunca vê a forma original.

Isso importa em tudo que compare caminhos ou decida permissão sobre eles. Quem confere uma regra de acesso contra a string crua em vez de contra o caminho normalizado está conferindo outra coisa, diferente da que vai ser pedida — o buraco conhecido como path traversal há décadas.

Se não houver caminho nenhum, o parser devolve `/`, porque um endereço sem caminho aponta para a raiz. Já `/artigo` e `/artigo/` são dois caminhos diferentes, e cabe ao servidor decidir se eles são o mesmo recurso — a maioria trata como redirecionamento de um para o outro, e alguns entregam as duas coisas.

A consequência aparece em busca e em cache: dois endereços que diferem apenas pela barra final são duas entradas separadas em qualquer coisa que use a URL como chave. Ver a forma normalizada aqui é o jeito mais rápido de descobrir se dois links que parecem iguais são, para as máquinas, dois links.

Se a porta é a habitual do esquema — 443 em https, 80 em http — o parser a omite, porque ela é redundante. `https://exemplo.com:443/` e `https://exemplo.com/` são o mesmo endereço, e a normalização torna isso visível.

É a explicação de sempre para uma comparação entre duas strings de URL falhar mesmo com as duas significando a mesma coisa. Quem compara endereços deveria passar os dois por um parser antes e comparar a forma normalizada, que é justamente a que aparece aqui nas linhas.

Um erro de digitação como `htp://exemplo.com` não é recusado: ele é lido como um endereço com o esquema `htp`. Não é falha do parser — a especificação aceita qualquer esquema, porque existem centenas: `mailto:`, `tel:`, `git+ssh:`, `spotify:`, e nenhum parser pode saber quais são válidos no seu mundo.

Na prática: se aqui aparece um esquema que você não esperava, você encontrou o seu erro de digitação. E isso significa também que uma verificação do tipo «dá para analisar?» não é uma verificação de que o endereço aponta para a web; para isso é preciso conferir o esquema contra uma lista explícita.

A forma `https://usuario:senha@host/` continua existindo, e aparece em scripts antigos, em strings de conexão de banco e em exemplos de documentação. Os navegadores restringiram o uso dela porque era ideal para phishing, mas bibliotecas e ferramentas de linha de comando continuam aceitando.

Aqui o nome de usuário é mostrado e a senha não: no lugar dela aparece a indicação de que existe uma. O motivo é banal e conta do mesmo jeito — esses resultados acabam com frequência numa captura de tela ou num chamado, e uma senha que já se tem não precisa ser impressa de novo.

Um host com cedilha ou com til é convertido para Punycode: `coração.example` vira `xn--corao-dra1a.example`. Essa é a forma que existe de verdade no DNS, porque o sistema de nomes só conhece ASCII; a escrita legível é um auxílio visual do navegador.

Tornar visível o que é consultado de fato tem utilidade de segurança. Os ataques homográficos usam caracteres de outras escritas que se parecem com os latinos; na forma Punycode eles saltam aos olhos, porque no lugar de um nome familiar aparece uma sopa de letras.

Tudo o que vem depois do `#` fica no navegador. Não aparece em nenhuma requisição, não chega a nenhum servidor e não consta em nenhum log de acesso. É uma propriedade do HTTP e não uma função de privacidade.

É útil porque um valor ali não chega ao servidor — historicamente, o motivo de os tokens de OAuth viajarem no fragmento. É incômodo porque ele mesmo assim fica no histórico, na cadeia de referrer de alguns scripts e em qualquer link compartilhado. «Não chega ao servidor» não significa «é privado».

Se o endereço colado tiver um espaço no caminho, o parser o transforma em `%20` sem avisar; um acento vira as sequências de porcentagem correspondentes em UTF-8. A linha do caminho que aparece aqui é, portanto, a forma que seria realmente enviada, e não a que você colou.

Isso é útil e pode confundir. É útil porque mostra o endereço como o servidor vai recebê-lo, que é o que interessa ao comparar com uma linha de log. Confunde quando alguém espera ver de volta exatamente o texto que digitou — e a diferença entre os dois é justamente a normalização que qualquer navegador aplicaria antes de disparar a requisição.

Uma URL colada aqui costuma vir de algum lugar sensível: um log de acesso, um e-mail que alguém achou estranho, um chamado de suporte. Ela carrega junto identificador de sessão, token em parâmetro e, com frequência, um e-mail. Como a separação acontece na página, nada disso é compartilhado conosco.

A ausência de requisição é a segunda metade da mesma garantia. Uma ferramenta que resolvesse o endereço para mostrar uma prévia teria contado ao outro lado que alguém está olhando — o que, com um link de phishing, é exatamente a informação que não convém dar.