Spoof en Unicode

Vous avez sans doute entendu parler de cette affaire mais j’y reviens parce que j’indique une solution qu’on peut appliquer dans Firefox. Je ne l’ai pas trouvée tout seul mais je vous raconte ça tout de même, ça peut servir. D’abord, de quoi s’agit-il ?

Avec un peu d’astuce et de recherches simples, on peut tromper l’internaute moyen en créant des adresses qui ressemblent comme deux gouttes d’eau à des adresses connues mais pourtant en sont d’autres.
Par exemple l’adresse https://www.аррӏе.com/ a l’air honnête. Notez le https qui inspire confiance. Cliquez dessus et vous verrez que vous n’arriverez pas à l’adresse que vous attendez.

Cet exemple est sans danger, hein ! Vous pouvez faire l’essai, le propriétaire du nom de domaine créé pour ce proof of concept destiné à faire une démonstration du genre d’arnaque qu’on peut faire. Il n’a pas créé un faux site Apple vous demandant vos codes d’accès…

L’astuce est toute simple, les caractères employés sont des caractères existant en caractères UTF-8 (Unicode) et qui peuvent faire illusion si la police utilisée ne leur donne pas un aspect trop bizarre ou si l’internaute ne se munit pas d’une forte loupe. Si cette adresse se trouve en lien dans un mail trompeur, on peut se faire avoir puisque c’est bien chez Apple qu’on croit être arrivé.

La plupart des navigateurs ont opté pour une solution aussi insatisfaisante que radicale : ils affichent l’adresse en caractères ASCII (latins de base sans accents) sans décoder et dans la barre d’adresse de Safari, Opera, Chrome, Chromium on voit :
https://www.xn--80ak6aa92e.com
ce qui est la même adresse dans le code dit Punycode qui est le vrai nom du nom de domaine tel qu’il a été enregistré.

Normalement les navigateurs sont censés traduire le punicode en caractères unicodes et c’est par défaut toujours le cas de Firefox.
Chez moi je vois donc, pour le faux apple :



et pour le vrai :



Je suis franchement incapable de distinguer les deux adresses avec cette police-là. Avec d’autres, le pseudo L a un air un peu drôle mais il faut vraiment y regarder de près.
Il est vrai que sur le vrai, il y a Apple Inc. (US) en vert à côté du cadenas de même couleur mais tout de même, on peut facilement se faire avoir si on ne s’attend pas à cette indication ou si on ne sait même pas qu’elle est censée s’afficher.
Le plus fou dans l’histoire est que le nom de domaine du faux apple est parfaitement légitime ! Il a été acheté spécialement pour la démonstration mais il est tout à fait officiel et donc on le trouve dans tout les bons serveurs DNS du monde.

La solution choisie par la plupart des navigateurs, faute de mieux, de ne pas traduire le punycode en Unicode est bien jolie mais ce n’en est pas vraiment une. C’est favorable pour la sécurité mais pour la lisibilité ce n’est pas fameux !

En effet, les noms de domaine en caractères non ASCII sont autorisés depuis quelques années pour permettre aux sites de pays utilisant autre chose que des caractères latins d’avoir des noms en caractères locaux. Si un site chinois s’affiche avec une suite de code à la gomme en ASCII, pour nous ça ne changera pas grand chose on n’y comprend de toute façon rien dans les deux cas, mais pour un chinois c’est tout de même grotesque.

Firefox n’ayant pas choisi cette demi-solution, on a tout de même la possibilité de lui indiquer de ne pas effectuer la convertion punycode -> unicode. C’est assez simple à mettre en œuvre :

Dans la barre d’adresse, tapez about:config et cherchez la variable network.IDN_show_punycode dont la valeur (si elle n’a pas été modifiée) vaut false.
Faites un double-clic sur ce false qui passera à true et le tour est joué.

Rechargez la page https://www.аррӏе.com/ dont l’adresse, hourra !, s’affiche maintenant en pur charabia…

Je ne sais pas quelle solution finira par être choisie mais en tout cas celle d’afficher une adresse qu’aucun être humain n’est capable de lire n’est pas vraiment tenable à long terme ! D’autant que le but des noms de domaine en Unicode était exactement le contraire…

Je vais faire mon Mosellan de base, les pieds jusqu'aux chevilles dans la glaise du plateau.


Si je clique sur le faux lien apple.com, je vois bien une adresse à la con dans la barre d'adresse et pas apple.com.

Car mon navigateur est Safari 10.1.1.

Car mon navigateur est Opera 46.

Par contre, avec le panda roux obèse…


J'ai donc moins de chances de me faire gruger par un site malintentionné en utilisant un navigateur WebKit-like.


Donc, si je te suis bien, Firefox est sensé être mieux parce qu'il traduit le bidule punycode mais te fait passer des vessies pour des lanternes, un site véreux pour un authentique, avec le cadenas de sécurité qui plus est.




Pour toi la solution choisie par les WebKit-like n'est pas satisfaisante, mais c'est pourtant celle qui maintien en vie.  


Tes deux images sont effrayantes dans tout ce qu'elles impliquent et la leçon que j'en tire est que je ne peux pas faire confiance à ce que m'affiche la barre d'adresse de Firefox.


Maintenant, je ne suis pas d'accord avec ta conclusion car l'adresse xn--80ak6aa92e.com est volontairement illisible, ou plus exactement elle montre ce qui devait être montré et pas apple.com.

La réalité est que lorsque mon navigateur va sur le site apple.com, il affiche bien apple.com. Et lorsqu'il va sur une site contrefait, il affiche la vraie adresse du site contrefait.

Par les temps qui courent, tout ce qui peut induire l'utilisateur en faute doit être écarté. Je ne comprend même pas la logique de geek tordu derrière le comportement de Firefox.

Cela dit, merci pour l'astuce, je vais de ce clic corriger Firefox.


Post Scriptum :

En faisant des recherches, je m'aperçois que le problème a été signalé au mois d'avril et que si Google a bien corrigé Chromium — et donc Chrome et Opera — rien n'a encore été fait du côté de Mozilla.  

En fait, depuis cinq mois, 5 mois, ils en causent, ils en re-causent, en causent, re-causent…  mais surtout ne font rien.

https://bugzilla.mozilla.org/show_bug.cgi?id=1332714



C'est grave.

Safari n'était pas concerné par cette faille. En fait, elle est corrigée depuis… 2005.

Ce que tu dis est à la fois vrai et faux.

C’est généralement vrai pour nos contrées où on peut modifier le réglage de Firefox parce qu’à moins de maîtriser le chinois (par exemple si on est un chinois vivant à Vesoul) voir les noms en UTF-8 est rarement utile. Bien que des noms de domaine avec des accents commencent à apparaître vers chez nous, j’en ai vus (dans Firefox…) mais je n’ai plus d’exemple en tête, un nom avec un accent aigu je crois (1).

C’est faux si on s’intéresse à des sites dont les noms de domaine ne s’écrivent pas en caractères ascii. Pour notre chinois de Vesoul ou son oncle de Pékin, à moins d’utiliser Firefox ou un navigateur d’origine exotique (par rapport à nous), pas moyen de savoir où on est arrivé en navigant puisqu’on ne peut pas lire l’adresse. Ça, rien à faire, on peut tourner ça dans tous les sens c’est bien un vrai problème de ne pas afficher le vrai nom, qui s’écrit avec des idéogrammes, des caractères coréens, cyrilliques, persans ou cherokee.

Ce n’est donc pas Firefox qui a un bug mais les autres qui ne le corrigent pas. Ils n’ont pas tort de ne pas le corriger à cause du risque, mais ils n’ont pas non plus raison pour quelques milliards d’internautes dans le monde qui voient s’afficher une adresse à la gomme alors que le vrai domaine déposé serait lisible pour eux. Et on peut dire exactement la même chose en sens inverse pour Firefox.  Pas aussi simple qu’il y paraît, cette affaire.

Exemple vécu : en fouillant dans un moteur de recherche pour trouver un truc pointu de pingouin, je suis tombé par hasard sur une page en anglais d’un site technique d’un pays d’Extrême-Orient (je n’ai pas su déchiffrer lequel !) et le nom de domaine était bel et bien composée d’idéogrammes et il s’affichait correctement dans Firefox (2). Il s’agit d’un cas réel qui doit être déjà très loin d’être isolé et qui va fatalement se multiplier dans un futur proche. C’est sans doute déjà fait mais vu de chez nous on ne s’en rend pas compte.

Les gens de Firefox n’ayant pas envie, on les comprend, de faire des versions avec et des versions sans traduction de ponycode en fonction du pays où le navigateur va être utilisé (ce qui d’ailleurs ne répondrait pas au besoin de notre chinois de Vesoul), comment résoudre ça ?
Peut-être une option accessible par un utilisateur moyen permettant de basculer ? Beuh…
Une traduction si on survole à la souris mais ceux qui n’auront pas l’idée de le faire le feront-ils ? Ça m’étonnerait.
Au contraire, afficher la traduction mais ajouter un avertissement donnant le vrai nom ? Je ne vois pas trop ça non plus parce qu’il faudrait comprendre .

En fait ce problème est proche de celui des noms de domaines exploitant les fautes de frappe. Par exemple (imaginaire) lesiteleplusbeau.com est authentique alors que lesitteleplusbeau.com ou lesiteleplubeau.com sont deux sites contrefaits pour faire du phishing. Il faut être un lynx pour voir la différence du premier coup d’œil alors qu’on n’a même pas de raison de vérifier puisqu’on croit être arrivé à la bonne adresse, le site étant une contre-façon.
La solution adoptée a été de répertorier les noms de domaine qui pourraient servir à ce genre de mauvaises farces et d’en bloquer l’achat lors d’une demande. C’est une recherche proposée lorsqu’on fait une demande de nom de domaine.

Pour l’usage malhonnête des caractères UTF-8, il devrait être possible d’automatiser cette recherche aussi, par exemple par une méthode de type reconnaissance de caractères. Le vrai et le faux apple.com auraient beau être différents en tant que caractères, ils n’en seraient pas moins identiques par leur lecture, donc détectés comme une sorte d’homophonie visuelle, si on peut dire, et le faux pourrait être bloqué.

-------------------------
(1) D’ailleurs j’ai moi-même deux noms de domaine (l’un en .com et l’autre en .fr) avec des accents mais pour l’instant ils sont renvoyés sur un troisième identique en .fr mais sans accent. Ces noms de domaine avec accent n’apparaissent jamais dans la barre d’adresse puisqu’ils sont instantanément renvoyés mais si un jour ou l’autre j’envisage de les employer différemment, je serai bien ennuyé bien que n’étant pas un chinois d’Alsace…
(2) Pour la petite histoire, je n’ai pas trouvé mon info sur ce site non plus mais j’ai fini par trouver tout seul…

"quelques milliards d'internautes" ???

Arrête ton char.

Le Chinois de Vesoul n'est pas concerné, pas plus que le Chinois de Pékin ou celui de Taiwan.

Le problème porte sur le cyrillique et les alphabets ayant des lettres semblables au latin, ce qui facilite leur substitution.


Il ne s'agit pas d'un bug mais d'une faille de sécurité. Le navigateur trompe l'internaute. Et c'est gravissime !  


Apple a déjà traité le problème en 2005 dans Safari, Google vient de le faire. Vivaldi n'était pas concerné. Ils n'ont pas désactivé la fonction (comme on est obligé de le faire avec FF) mais ajouté des contrôles sur le cyrillique.

Le reste fonctionne normalement. Une page exemple avec nom de domaine en caractères japonais : https://白猫プロジェクト.gamewith.jp/article/show/40508

Comme tu peux le constater, le Japonais de Honfleur n'a pas de problème, idem pour le Coréen de Vierzon et le Chinois de Vesoul.


Mozilla a choisi de ne pas corriger la faille parce que, je cite : This is just another way of making Cyrillic a second-class citizen on the web.  

Ce type, Gervase Markham, est un con. Il peut avoir tout le savoir technique, être un des pontes de Mozilla, il n'en demeure pas moins qu'il est complètement con.

Quand l'idéologie parle à la place de la technique c'est toujours une mauvaise méthode.


Les internautes les moins informés, les plus fragiles, restent à la merci des faussaires parce chez Mozilla certains esprits ont des scrupules. Les autres sont effectivement obligés d'en passer par le punycode (qui porte bien son nom pour le coup) et se priver d'une fonction bien utile.

Merci d'utiliser Firefox !  


Et bien moi, j'en ai souqué de Mozilla, de son navigateur menteur et de ses développeurs idéologues. J'utilise un navigateur pour ce qu'il m'apporte au quotidien en matière de fonctions, de confort et de sécurité, pas pour défendre une cause.

J'ai appliqué ton fix pour FF sur ma session principale de mon Mac principal — encore une fois, merci d'avoir abordé le sujet parce qu'il m'avait échappé. Sur les autres machines, j'ai simplement désinstallé Firefox.

Il m'est d'avis que le Chinois de Vesoul fera de même.

Effectivement, tu as raison ce ne n’est pas l’ensemble des caractères non ascci qui sont bloqués contrairement à ce que j’avais compris mais est-ce que ça veut dire que l’affichage en punycode n’est forcé que si les caractères sont en cyrillique ?

Ça ne peut pas être ça, il y a des montagnes d’autres moyens d’imiter les caractères ascci avec autre chose que du cyrillique, dans Unicode. Ça ne résout rien au problème de se contenter de supprimer un jeu de caractère simplement parce qu’il se prête mieux à ce genre de jeu tordu alors qu’on peut arriver à truander sans. Bref, le problème n’est pas résolu du tout.
Ou alors on supprime l’affichage de tout ce qui n’est pas ascii, comme j’avais cru que c’était le cas.

J’ai fait un exemple vite fait sur le gaz sans trop me fouler et dont j’ai mis une image en dessous. J’ai mis un caractère non ascii dans chaque mot sans prendre aucun caractère cyrillique :

La seconde ligne est normale, uniquement des caractères ascii.

Les faux c de plaᴄe et h de planche sont un peu faiblards dans certaines polices.
Le α de cαbot est de l’autre forme que celle du a habituel et un tout petit peu tordu (comme le v de voici) mais pris isolément dans une adresse du genre www.αpple.com, moi ça ne me choquerait pas en jetant un simple coup d’œil et je n’y ferais probablement pas attention. Mais c’est celui qui marche le moins bien mais pour les autres mots c’est malheureusement assez efficace.
Et surtout en cherchant bien on doit pouvoir faire beaucoup mieux que ça.

Le même exemple en caractères tapés directement ici :
cαbot νoici sοl plancհe fibre plaᴄe effet fleur
cabot voici sol planche fibre place effet fleur

Le résultat est plus ou moins efficace suivant la police utilisée mais avec pas mal de polices bâton que j’ai essayées, ça passe bien si c’est en caractères de petites tailles comme dans une barre d’adresse.

Si on recopie la première ligne dans un traitement de texte, le correcteur soulignera tous les mots sauf fibre, effet et fleur qui seront considérés comme corrects puisque les caractères que j’ai utilisés sont les ligatures pour fi, ff et fl qui sont correctes pour ce qui est de l’orthographe.

La solution parfaite n'existe probablement pas à ce niveau. C'est effectivement en amont qu'il faut prendre le problème, au moment de l'enregistrement des noms de domaine. Toutefois, la situation de Firefox n'est pas acceptable au regard des principes de sécurité.

Pour info, voilà ce qu'Apple avait fait en 2005 : https://support.apple.com/kb/TA22996

Doubleyou a écrit:

La solution parfaite n'existe probablement pas à ce niveau. C'est effectivement en amont qu'il faut prendre le problème, au moment de l'enregistrement des noms de domaine.

Depuis le temps que ça dure, je ne sais pas si les organismes qui gèrent les noms de domaine se sont beaucoup bougé pour régler cette affaire. Pourtant les fausses adresses exploitant les fautes de frappe ont bien été bloquées. Ça ne peut tout de même pas être si dur de faire quelque chose d’équivalent, les possibilités sont loin d’être infinies.

Doubleyou a écrit:

Toutefois, la situation de Firefox n'est pas acceptable au regard des principes de sécurité.

Tel que c’est, oui. Il bien doit exister des solutions moins bancales que le blocage pur et simple et effectivement ils n’ont pas été très efficaces chez Mozilla pour en trouver. Les autres ont paré au plus pressé, ce qui est bien, mais ne se sont pas trop bougé non plus par la suite pour arranger ce qui aurait dû être une rustine temporaire.

Un affichage décodé mais accompagné d’un message d’avertissement (impossible à rater) en cas de mélange de scripts unicode ou d’utilisation exclusive de caractères permettant de tromper l’internaute ne serait pas la mer à boire, comme développement. Ou, comme pour les site frelatés connus, une page d’avertissement avec possibilité de débloquer la page si c’est une fausse alerte ou si on veut savoir ce qui se cache derrière.

En tout cas il y a mieux à faire que de laisser un problème de sécurité ouvert ou de boucher un trou avec une montagne.

Doubleyou a écrit:

Pour info, voilà ce qu'Apple avait fait en 2005 : https://support.apple.com/kb/TA22996

L’adresse du fichier indiqué dans la note a changé, je l’ai trouvé ici :
/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Resources/IDNScriptWhiteList.txt

En fait ce n’est pas un blocage des scripts qui permettent de facilement faire des fausses adresses, c’est une autorisation pour ceux qui sont censés ne pas pouvoir être ambigus.
Donc il y a beaucoup d’autres scripts unicodes qui sont bloqués.