Qual é a finalidade de @ (arroba) no URL antes do domínio?
Recentemente, descobri um novo ataque de phishing que usa um @símbolo para fazer o URL parecer legítimo. É assim:
Eu tenho uma conta em totally-legit-site.come o invasor configura um site de phishing em seu IP como 192.168.50.20. Em seguida, ele me manda uma mensagem no site, contendo link que se parece com http://[email protected]/account. Isso é usado para enganar o usuário, fazendo-o pensar que esse é o link para o site legítimo.
Clicar neste link, no entanto, abre a página 192.168.50.20/accountno meu navegador (Google Chrome). Tentei adicionar coisas aleatórias com @antes de domínios aleatórios e meu navegador sempre resolve a página corretamente, jogando essas coisas @fora. Então, se tento abrir http://[email protected], acabo na página inicial do Google.
Isso realmente me interessa. Não consegui encontrar nenhuma informação sobre @em URLs antes do domínio. Como isso é chamado? São coisas obsoletas dos primeiros estágios da Internet? Existem alguns servidores da web que podem processar essa parte da URL (seria legal poder modificar minha instância do nginx para retornar sites diferentes com base neste parâmetro)?
Respostas
Esta sintaxe é usada para especificar detalhes de autenticação em nível de protocolo (nome de usuário, ocasionalmente também senha) para conexão com a 'autoridade'. Veja por exemplo RFC 3986 seção 3.2.1 .
Quando utilizado com HTTP, as credenciais são enviadas na HTTP Autorização: cabeçalho ; o formato depende do mecanismo de autenticação solicitado pelo servidor, mas mais comumente a Basicautenticação é usada sem processamento adicional. Consulte RFC 7617 ou MDN .
Muitos servidores da web podem verificar as credenciais em um arquivo 'htpasswd', LDAP, SQL ou outros bancos de dados - por exemplo, para Nginx, consulte auth_basic ou Apache httpd AuthType Basic .
Como alternativa, a verificação pode ser feita pelos próprios aplicativos da web, já que é feita por meio de cabeçalhos HTTP padrão e códigos de status. Veja, por exemplo, PHP (mas para fazer isso funcionar no Apache, você pode precisar ativar CGIPassAuthou usar um truque de reescrita estranho, caso contrário, ele não encaminhará o cabeçalho de autorização para o tempo de execução do aplicativo.)
A autenticação HTTP embutida é comumente usada para APIs e outras solicitações automatizadas, uma vez que não requer interação do usuário, não requer armazenamento de cookies ou outro estado e não requer saber como formatar a solicitação POST de "login" (que você precisaria de autenticação baseada em <form>).
Este também é exatamente o mesmo método de autenticação usado por estes prompts:
A mesma sintaxe também se aplica ao FTP e a muitos outros protocolos que usam uma URL e oferecem suporte à autenticação - em todos os casos, o mecanismo interno desse protocolo é usado.
O ataque aqui funciona porque a autenticação HTTP é opcional e, na maioria dos casos, o cabeçalho HTTP extra é simplesmente ignorado pelo servidor da web e pelo aplicativo da web. E vice-versa, os navegadores não sei se o servidor irá pedir para autenticação até que após uma solicitação é enviada.
No entanto, o ataque não é novo em tudo - tem sido em torno desde a início de 2000 pelo menos. (Na verdade, em algum ponto os navegadores começaram a verificar, primeiro fazendo uma solicitação sem autenticação para ver se o servidor responderá com 401 ou não. Se o servidor não solicitar autenticação, o Chrome irá ocultar o nome de usuário da barra de endereço para fazer o domínio real é mais óbvio, e o Firefox irá realmente avisar que "Isso pode ser uma tentativa de enganar você.")