Mise à jour : Apple iOS 12 et Safari 12 pour macOS, sortis le 17/09/2018, ont corrigé ce problème.
Nous avons vu pas mal d’articles circuler pour vous dire de faire attention (!) si vous utilisiez le navigateur Safari, car des cybercriminels pourraient usurper des URL (!)
Cela ressemble à un problème sérieux, expliquant nos points d’exclamation en gras que nous avons utilisés ci-dessus, et voici pourquoi.
Une URL usurpée signifie qu’au niveau de la barre d’adresse, située en haut de votre navigateur, s’affiche un nom de site web délibérément et trompeusement différent de la page web affichée dans le navigateur lui-même.
Ce n’est pas censé arriver !
Le contenu d’un site web peut afficher à peu près tout ce qu’il veut dans la fenêtre principale du navigateur, y compris du texte malveillant et des logos d’autres personnes, mais la barre d’adresse est censée être une zone intouchable !
En gardant soigneusement la barre d’adresse sous son propre contrôle, votre navigateur a pour but de vous aider à repérer les faux contenus.
Les cybercriminels peuvent, par exemple, vous présenter une fausse page de connexion bancaire, mais ils ne peuvent pas réécrire au niveau de la barre d’adresse, pour affirmer que le site est vraiment celui de votre banque, du moins, ils ne sont pas censés pouvoir le faire !
En fait, si vous examinez attentivement la barre d’adresse avant de saisir des données personnelles, vous serez en mesure de détecter et d’éviter la grande majorité des attaques de phishing, car la barre d’adresse est une zone qui, lors de votre expérience de navigation, ne peut pas facilement être manipulée.
À cause de cela, ces avertissements qui se sont propagés au sujet d’une faille de sécurité non corrigée, concernant une possible usurpation d’URL dans le navigateur Safari, ont piqué notre curiosité et nous avons décidé d’approfondir un peu le sujet.
Le navigateur Safari est sans doute peu utilisé de nos jours au niveau du bureau, en effet il n’est disponible que sur Mac, où il doit faire face à la concurrence de Google Chrome et de Mozilla Firefox, mais il est largement utilisé sur iPhone et iPad, sur lesquels il est le navigateur du système pré-installé par défaut.
Le bug s’avère être très simple et voici comment il fonctionne.
Imaginez que vous ayez une page web simple comme celle-ci, hébergée sur le site ns.example :
Un visiteur verra quelque chose comme ça, avec le nom du site clairement indiqué dans la barre d’adresse :
Si nous ajoutons des scripts, nous pouvons d’abord charger notre contenu, puis demander au navigateur Safari de passer à une nouvelle page à l’aide de la fonction JavaScript location.assign().
Ici, nous redirigeons vers la page web other.test immédiatement après avoir affiché le texte “here is some content” :
Comme vous pouvez le voir, lorsque location.assign se produit, le navigateur Safari met correctement à jour la barre d’adresse avec le nom du nouvel emplacement, other.test :
Mais si nous modifions l’URL, vers laquelle nous avons effectué la redirection, afin de spécifier un port réseau malveillant (les serveurs HTTP utilisent le port 80 par défaut, HTTPS utilise le port 443), le navigateur Safari essaiera de se connecter à un port qui n’est pas en mode “écoute”, et après un délai assez long, il signalera une erreur.
Dans Firefox, par exemple, vous ne verrez rien de suspect pendant que le navigateur Safari attend un retour de location.assign, mais après avoir essayé et échoué, vous verrez le nouvel emplacement dans la barre d’adresse, plus un message d’erreur dans la fenêtre principale :
Jusqu’ici tout va bien !
Mais le bug de Safari est qu’il met à jour la barre d’adresse dès que la tentative de redirection démarre, affichant le nom du nouveau site web, mais laissant l’ancien contenu visible dans la fenêtre principale jusqu’à ce que la redirection échoue.
Par conséquent, pendant une minute ou plus, vous verrez le contenu de ns.example, mais avec un identificateur de barre d’adresse indiquant que le nom du site est other.test :
Il s’avère que le navigateur Safari ne vous laissera pas taper quelque chose dans le formulaire web ci-dessus pendant que la fonction location.assign() essaie de faire la redirection. Ainsi, même si vous pouvez cliquer sur le bouton [Soumettre], vous ne pouvez pas directement faire partir des données en pensant que vous êtes sur un autre site.
Un cybercriminel pourrait toutefois présenter une boîte de dialogue JavaScript qui vous demanderait de saisir des données, telle qu’un mot de passe de connexion, et votre saisie pourrait finir par être envoyée au site web d’origine (ns.example) plutôt qu’au site déclaré dans la barre d’adresse (other.test).
Eh oui, l’usurpation d’URL vient bel et bien d’avoir lieu !
Sur un iPhone, le bug est un peu plus gênant. En effet, pour économiser de l’espace au niveau de l’écran, le navigateur Safari mobile affiche uniquement le nom du site web, sans le texte de traîne : :8000 (ou quel que soit le numéro de port) à la fin :
Bien sûr, vous pourriez ne pas faire attention au numéro de port bidon même s’il était affiché, mais il s’agit d’un indice précieux dans la version de bureau de Safari.
Quoi faire ?
Selon le chercheur qui a signalé cette faille de sécurité, Edge et Safari ont tous les deux ce bug qui “affiche le nom de la nouvelle URL avant que le contenu ne soit prêt”, mais Microsoft a corrigé Edge en août dernier.
Edge se comporte maintenant comme Firefox : alors que le contenu de ns.example est à l’écran, la barre d’adresse affiche ns.example. Seulement après que le navigateur ait essayé et échoué, la nouvelle URL sera affichée, en même temps que le message d’erreur apparaîtra.
Apple n’a cependant pas encore changé le comportement du navigateur Safari (nous nous demandons si la nouvelle version d’iOS, qui sera bientôt disponible, inclura un correctif pour cela ?).
Vous pouvez cependant repérer cette technique d’usurpation, même sur la version mobile de Safari où le numéro de port est supprimé :
- La fine ligne bleue de progression située sous la barre d’adresse s’arrête à mi-chemin. Cela montre que la page nommée dans la barre d’adresse n’a pas encore été chargée, c’est un indicateur utile qui montre que la barre d’adresse indique ce qui reste à venir, pas ce qui est actuellement à l’écran !
- Il n’existe pas de cadenas dans la barre d’adresse. La redirection ne va pas réussir car l’URL ne fonctionne pas, Safari ne peut donc pas afficher un certificat HTTPS car il n’en existe pas et il n’en existera jamais !
Aujourd’hui, vous devriez vraiment être systématiquement à la recherche du cadenas HTTPS, même pour les sites où vous n’avez pas l’intention de vous connecter ou de remplir des formulaires.
Un ancien site HTTP simple est trop facile à usurper pour des cybercriminels. Nous vous recommandons donc de vous tenir à l’écart de tout contenu non HTTPS, une précaution qui vous protégera facilement dans ce cas également.
Billet inspiré de Browser security hole on Macs and iPhones – just how bad is it?, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.