O link de verificação que chega por e-mail, SMS ou WhatsApp é um jeito simples de levar alguém a provar a identidade fora do seu site: a pessoa toca, a página abre, a verificação começa. Por trás dessa simplicidade há um segredo, o token que diz de quem é aquela verificação. A resposta curta para quem desenha o fluxo: o link é seguro quando o token não vaza no caminho e quando, se vazar, vale pouco. Não vazar depende de onde o token mora na URL: na query ele aparece em log de servidor, em cabeçalho Referer e em prévia de aplicativo; no fragmento, depois do "#", a RFC 3986 diz que ele fica com o navegador. Valer pouco depende do token: aleatório, longo, guardado com segurança, de uso único e com prazo para expirar, como recomenda a OWASP.
Em resumo
- A query da URL vai ao servidor em toda requisição e aparece em log de acesso, proxy, histórico do navegador e, em certas condições, no cabeçalho Referer.
- O fragmento, a parte depois do "#", "is separated from the rest of the URI prior to a dereference", segundo a RFC 3986, e não é enviado ao servidor.
- A OWASP pede que tokens de link sejam aleatórios por algoritmo seguro, longos, guardados com segurança, de uso único e com expiração.
- O link certo também precisa parecer certo: a mensagem diz quem envia e para quê, porque a página de verificação falsa usa o mesmo canal.
Onde o segredo de um link vaza
Um token na query (https://exemplo.com/verificar?t=abc123) viaja na primeira linha da requisição HTTP. Isso quer dizer que ele aparece no log de acesso do servidor, no log de qualquer proxy ou rede de distribuição no caminho e no histórico do navegador. A RFC 9110, que define a semântica do HTTP, trata de outro canal: o cabeçalho Referer, que o navegador pode mandar ao destino quando a pessoa sai da página por um link. A própria RFC reconhece que esse cabeçalho "has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals personal information". A norma restringe o envio entre origens diferentes quando a página veio por protocolo seguro, mas abre a exceção para quando o recurso permite, e o cabeçalho continua indo à mesma origem.
A Folha de Referência de Gestão de Sessão da OWASP resume o risco do segredo em URL: o identificador incluído na URL pode vazar "in web links and logs, web browser history and bookmarks, the Referer header or search engines". A folha de recuperação de senha da mesma organização pede, para a página que recebe um token por URL, a política de Referer "no-referrer", justamente "to avoid referrer leakage".
O fragmento fica com o navegador
A RFC 3986, que define a sintaxe da URI, dá ao fragmento um papel que resolve o vazamento de log e de proxy.
As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme.
Na prática: em https://exemplo.com/v/#vlt_abc123, o navegador pede ao servidor só https://exemplo.com/v/; o token fica na barra de endereço e é lido pelo código da página. Ele não aparece no endereço que os logs de acesso, os proxies e a rede de distribuição registram; quando a página o usa, pode enviá-lo no corpo de uma requisição, fora da URL. A leitura da casa acrescenta uma consequência útil: os aplicativos de mensagem que geram prévia buscam a URL para montar o cartão, e a busca, como qualquer requisição, sai sem o fragmento. A prévia não leva o token, e não consome o link.
| Lugar da exposição | Token na query | Token no fragmento |
|---|---|---|
| Log de acesso do servidor e de proxy | Aparece | Não aparece |
| Cabeçalho Referer para outro site | Pode aparecer, conforme a política | Não aparece, o fragmento não entra no Referer |
| Histórico e favoritos do navegador | Aparece | Aparece |
| Prévia gerada pelo aplicativo de mensagem | A requisição da prévia leva o token | A requisição da prévia sai sem o token |
| Código da própria página | Lê | Lê |
A linha do histórico mostra o limite: o fragmento não protege o aparelho da pessoa. Por isso o token precisa valer pouco mesmo quando alguém o vê.
Leia também Página de verificação falsa, quando o golpe imita o seu onboarding
O que o token precisa ter
A OWASP lista, na folha de recuperação de senha, o que um token entregue por canal externo precisa ter: ser gerado "using a cryptographically safe algorithm", ser "sufficiently long to protect against brute-force attacks", ser "stored securely" e ser "single use and expire after an appropriate period". A mesma folha pede limitação de tentativas contra força bruta e que a URL não seja montada a partir do cabeçalho Host da requisição, para evitar a injeção de cabeçalho.
Para um link de verificação de identidade, isso se traduz em quatro decisões: o token sai de um gerador criptográfico; o servidor guarda só o resumo dele, para que um vazamento do banco não entregue links válidos; o link vale uma vez, e o que nasce do resgate é uma sessão de verificação com prazo próprio; e o link expira sozinho se ninguém usar.
Atenção
Um link seguro tecnicamente ainda pode ser o instrumento de um golpe: o fraudador pede à vítima que faça a "verificação" para ele, e a selfie e o documento da vítima viram a conta do fraudador. A mensagem que leva o link precisa dizer o nome do serviço, para que é a verificação e o que fazer se o pedido não veio de quem a pessoa conhece; o texto sobre o golpe em nome do verificador trata da outra ponta do mesmo problema.
Como a UNIFOKAL faz
O link hospedado da UNIFOKAL, documentado na API REST, segue essas regras: a URL entregue leva o token no fragmento; o token volta em claro uma única vez, porque só o resumo é guardado; o link vive horas e a sessão só nasce no resgate; e a documentação traz um texto sugerido para a mensagem, com o aviso de não continuar se alguém pediu a verificação em nome de outra pessoa. O passo a passo do fluxo está em como funciona.
Fontes citadas
- IETF, RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, seção 3.5, no RFC Editor
- IETF, RFC 9110, HTTP Semantics, seção 10.1.3 (Referer), no RFC Editor
- OWASP, Session Management Cheat Sheet, no OWASP Cheat Sheet Series
- OWASP, Forgot Password Cheat Sheet, no OWASP Cheat Sheet Series