Você não pode simplesmente acessar publicamente links privados e seguros, pode?
URLs que funcionam como “links privados” — endereços longos e impossíveis de adivinhar, com tokens ou senhas embutidos — estão sendo cada vez mais expostas por scanners de e-mail, plataformas de mensagens, CDNs e sistemas de registro, mostrando que a obscuridade por si só não é um mecanismo confiável de controle de acesso. Os comentaristas ponderam os benefícios de usabilidade de links de um clique para coisas como compartilhamento de arquivos e redefinição de senha contra os riscos de tokens reutilizáveis e de longa duração, e apontam mitigadores como tempos de expiração curtos, códigos de uso único, mover segredos para fora de strings de consulta e usar autenticação adequada em vez disso. A conclusão mais ampla é que a infraestrutura e as ferramentas da web geralmente tratam URLs como dados não sensíveis, então qualquer coisa realmente privada precisa de controles de acesso explícitos, em vez de depender de um endereço “secreto”.
Modelo de segurança de links “privados”
- Muitos comentaristas argumentam que links com tokens impossíveis de adivinhar, mas sem controle de acesso, são apenas “segurança por obscuridade”. Eles não são inerentemente privados; são apenas difíceis de forçar por tentativa e erro.
- Outros enfatizam que a obscuridade pode ser aceitável como uma camada em “segurança com obscuridade”, mas não deve ser a única proteção.
Por que segredos em URLs vazam
- URLs são registradas no histórico do navegador, logs de acesso do servidor, proxies reversos, CDNs, logs de firewall/IDS e scanners de links. Campos de senha e corpos de POST muitas vezes não são.
- Plataformas de mensagens e e-mail, gateways de segurança e serviços de varredura de URLs buscam automaticamente links para pré-visualizações ou verificações de malware, expondo inadvertidamente “magic links” e até arquivos baixados.
- Canais sem E2EE significam que a plataforma vê todos os links; muitas vezes os usuários não percebem isso.
Comparando links vs senhas
- Teoricamente, um token de URL longo e aleatório pode ter muito mais entropia do que uma senha e ser efetivamente impossível de forçar por tentativa e erro.
- Na prática, senhas são tratadas como sensíveis por ferramentas e usuários; URLs são rotineiramente armazenadas, compartilhadas e indexadas.
- Links são “algo que você tem” e são facilmente copiados; senhas são “algo que você sabe”, ao menos em princípio.
Usos legítimos de tokens em URLs
- Tokens de curta duração e uso único para redefinição de senha, verificação de e-mail, URLs pré-assinadas do S3 e fluxos semelhantes são amplamente aceitos.
- Alguns padrões de acesso a mídia (imagens hospedadas em CDNs, WebSockets sem cookies, caches binários) frequentemente dependem de tokens em URL por necessidade ou conveniência.
Mitigações e padrões melhores
- Mitigações recomendadas: expiração muito curta, uso único, tokens por usuário, revogação, limitação de taxa e evitar magic links “de uso infinito” de longa duração.
- Prefira autenticação em cabeçalhos/cookies ou corpos de POST; evite segredos persistentes em strings de consulta ou caminhos.
- Usar fragmentos de URL para segredos os mantém fora da rede, mas só funciona com lógica do lado do cliente e ainda arrisca exfiltração por JS e vazamento no histórico do navegador.
- Alguns sugerem esquemas ou cabeçalhos para marcar URLs como “privadas”, mas outros observam que invasores e alguns scanners simplesmente ignorariam essas marcações.
Ferramentas de varredura, UX e responsabilidade
- Há debate sobre de quem é a responsabilidade: serviços que indexam publicamente URLs escaneadas, plataformas de e-mail/mensagens que enviam links automaticamente, ou desenvolvedores que codificam autenticação em URLs.
- Vários apontam para uma UX ruim: ferramentas de varredura que, por padrão, publicam resultados sem avisar claramente os usuários, ou rótulos ambíguos como “public scan” e “report”.