Quel est le but de @ (symbole at) dans l'URL avant le domaine?
J'ai récemment rencontré une nouvelle attaque de phishing qui utilise un @symbole pour donner à l'URL un aspect légitime. Ça va comme ça:
J'ai un compte chez totally-legit-site.comet l'attaquant crée un site de phishing sur son adresse IP comme 192.168.50.20. Ensuite, il m'envoie un message sur le site, contenant un lien qui ressemble à http://[email protected]/account. Ceci est utilisé pour tromper l'utilisateur en lui faisant croire qu'il s'agit du lien vers le site légitime.
Cependant, cliquer sur ce lien ouvre la page 192.168.50.20/accountdans mon navigateur (Google Chrome). J'ai essayé d'ajouter des éléments aléatoires avec @des domaines aléatoires avant et mon navigateur résout toujours la page correctement, jetant ces éléments avec @. Donc, si j'essaye d'ouvrir http://[email protected], je me retrouve sur la page d'accueil de Google.
Cela m'intéresse vraiment. Je n'ai trouvé aucune information sur les @URL avant le domaine. Comment ça s'appelle? S'agit-il de trucs obsolètes des premiers stades d'Internet? Y a-t-il des serveurs Web qui peuvent traiter cette partie de l'URL (pouvoir modifier mon instance nginx pour renvoyer différents sites en fonction de ce paramètre serait cool)?
Réponses
Cette syntaxe est utilisée pour spécifier les détails d'authentification au niveau du protocole (nom d'utilisateur, parfois aussi mot de passe) pour la connexion à l '«autorité». Voir par exemple la section 3.2.1 de la RFC 3986 .
Lorsqu'elles sont utilisées avec HTTP, les informations d'identification sont envoyées dans l' autorisation HTTP : en- tête ; le format dépend du mécanisme d'authentification demandé par le serveur, mais le plus souvent, l' Basicauthentification est utilisée sans traitement supplémentaire. Voir RFC 7617 ou MDN .
De nombreux serveurs Web peuvent vérifier les informations d'identification par rapport à un fichier 'htpasswd', LDAP, SQL ou d'autres bases de données - par exemple pour Nginx, voir auth_basic ou Apache httpd AuthType Basic .
Alternativement, la vérification peut être effectuée par les applications Web elles-mêmes, car elle est effectuée via des en-têtes HTTP standard et des codes d'état. Voir par exemple PHP (mais pour que cela fonctionne dans Apache, vous devrez peut-être activer CGIPassAuthou utiliser une astuce de réécriture étrange, sinon elle ne transmettra pas l'en-tête Authorization au runtime de l'application.)
L'authentification HTTP intégrée est couramment utilisée pour les API et autres requêtes automatisées, car elle ne nécessite aucune interaction de l'utilisateur, ne nécessite pas de stockage de cookies ou d'un autre état, et ne nécessite pas de savoir comment formater la requête POST "connexion" (que vous besoin d'une authentification basée sur <form>).
C'est également exactement la même méthode d'authentification que celle utilisée par ces invites:
La même syntaxe s'applique également au FTP et à de nombreux autres protocoles qui utilisent une URL et prennent en charge l'authentification - dans tous les cas, le mécanisme intégré de ce protocole est utilisé.
L'attaque ici fonctionne car l'authentification HTTP est facultative et dans la plupart des cas, l'en-tête HTTP supplémentaire est simplement ignoré par le serveur Web et l'application Web. Et vice - versa, les navigateurs ne savent pas si le serveur vous demandera l' authentification jusqu'à ce que , après une requête est envoyée.
Cependant, l'attaque n'est pas nouvelle du tout - il a été autour depuis au moins début des années 2000. (En fait, à un moment donné, les navigateurs ont commencé à vérifier, en faisant d'abord une demande sans authentification pour voir si le serveur répondra avec 401 ou non. Si le serveur ne demande pas d'authentification, Chrome masquera le nom d'utilisateur de la barre d'adresse pour faire le vrai domaine est plus évident, et Firefox avertira en fait que "cela peut être une tentative de vous tromper.")