Il ne semble pas y avoir de limite sur les caractères utilisable dans un nom d'utilisateur. Cela veut dire qu'il est généralement possible de créer un compte dont le nom est impossible à distinguer de celui d'un autre sans une inspection détaillée.
Par exemple, dans cette capture d'écran, enzo_bricolo et enzo_bricolо sont deux comptes différents. Le dernier "o" du deuxième étant un CYRILLIC SMALL LETTER O (U+043E) : http://cretonnerre.krunch.be/~krunch/pics/enzo.png
Il serait sans doute une bonne idée soit de restreindre les caractères autorisés dans les noms d'utilisateur, soit d'afficher clairement un élément distinctif supplémentaire.
# exemple de commentaire
Posté par Krunch (site web personnel) . Évalué à 3 (+0/-0).
Example pour les commentaires avec le style par défaut : http://cretonnerre.krunch.be/~krunch/pics/fakeenzo.png
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# nomenclature et mitigation
Posté par Krunch (site web personnel) . Évalué à 5 (+0/-0). Dernière modification le 22 août 2022 à 11:38.
C'est une attaque par homoglyphe et l'Unicode TR36 a des recommendations spécifiques : https://unicode.org/reports/tr36/tr36-8.html#Visual_Spoofing_Recommendations
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: nomenclature et mitigation
Posté par Krunch (site web personnel) . Évalué à 5 (+0/-0).
Je pense qu'une mitigation raisonnable serait d'associer chaque compte à un identifiant sur 32 bits et de le représenter en hexadécimal entre parenthèses (8 caractères, 12 en comptant les parenthèses et espaces) partout où le nom / nom d'utilisateur est représenté. Je suggère de ne pas utiliser un identifiant incrémental pour éviter de donner plus de valeur implicite aux comptes les plus anciens.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 26 août 2022 à 08:55.
Merci beaucoup pour le rapport, c'est très bien vu comme attaque !
Je ne connais pas trop le système de compte, je vais regarder.
En vitesse, j'ai vu que l'on a une regexp pour la validation des logins:
On utilise aussi la gem
devise v4.6.2
pour authentifier, mais je ne suis pas sûr que c'est lié.Le login, c'est utilisé pour les URLs (le mien par exemple, c'est trim), mais il faut aussi que je vérifie le nom d'utilisateur (la partie que tu as soulevée, donc Adrien Dorsaz chez moi pour l'instant).
De ce que je vois, la validation impose juste un maximum de 40 caractères, il va donc falloir mettre les mains dans le cambouis :)
[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4 (+0/-0).
Merci pour le lien d'ailleurs, c'est une bonne référence.
D'ailleurs, ils disent qu'il vaut mieux ne pas faire de restriction de caractères, parce que les langues évoluent.
Ils proposent plutôt de remplacer les caractères visuellement proche:
Si je ne me trompe pas, ça doit correspondre à la méthode de normalisation d'UTF-8: https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization
Ah ben oui, c'est bien ça, ils proposent d'appliquer l'algorithme NFKC (2.10.2 > B > 2):
[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4 (+0/-0).
Aïe, je viens de voir qu'il n'y a même pas besoin de faire de "visual spoofing" sur le nom affiché, puisqu'il n'y a même pas de contrainte d'unicité: vous pouvez tous mettre la valeur Adrien Dorsaz si ça vous chante :(
C'est une "fonctionnalité" déjà employée: j'ai déjà vu des utilisateurs réutiliser le même nom affiché quand ils créent un nouveau compte plusieurs mois / années après avoir supprimé leur ancien compte.
[^] # Re: nomenclature et mitigation
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+0/-0). Dernière modification le 26 août 2022 à 10:17.
En même temps si tu t'appelles Pierre Martin comme trois autres personnes du site, tu ne vas pas mettre Kevin Durand juste pour faire plaisir au critère d'unicité des développeurs de LinuxFr.org ? :)
Cela voudrait dire rajouter un élément externe à la déclaration de l'utilisateur (du type "Pierre Martin #1" ou "Pierre Martin 2022/08/14" (date de création du compte) ou "Pierre Martin
<un truc visuel>
" (qui marche sur du texte… pas juste une image), donc le « soit d'afficher clairement un élément distinctif supplémentaire ».[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 26 août 2022 à 12:35.
Tu as tout à fait raison :)
Je suis en train d'essayer d'afficher le login après le nom, puisque lui est unique.
C'est l'occasion de trouver un moyen également pour améliorer la lisibilité de la ligne "Posté par xxx, Édité par yy, zzz, aaa, Modéré par vvvv", parce que ça va vraiment être très long comme texte si on affiche les logins de tout le monde !
Je fais des essais avec la balise HTML
<details>
que je laisserai par défaut fermé sur la liste des articles et ouvert sur l'article lui même.[^] # Re: nomenclature et mitigation
Posté par Krunch (site web personnel) . Évalué à 2 (+0/-0).
Si on veut utiliser le login pour ça, je suggère de supprimer/migrer tous les comptes qui ont des logins en non-ASCII. Si ça n'est pas acceptable, je recommande d'utiliser un nouvel identifiant non séquentiel généré automatiquement. Cf https://linuxfr.org/suivi/falsification-d-identite-par-unicode#comment-1899183
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4 (+0/-0). Dernière modification le 26 août 2022 à 23:21.
J'y ai réfléchis à nouveau et effectivement, on va avoir un problème si on veut pouvoir être protégé du visual spoofing du login: pour pouvoir appliqué facilement la contrainte d'unicité, il faudrait pouvoir normaliser (avec l'algorithme NKFC) les logins.
Mais si on fait ça, alors on change les identifiants de connexion des utilisateurs !
Pour être transparent pour l'utilisateur, Ruby devra normaliser l'identifiant entré avant de le comparer à la base de donnée (mysql ne connaît pas unicode normalize() alors que postgres 13).
Le plus sage serait je pense de passer par une étape intermédiaire:
Si on n'arrive pas à nettoyer les comptes existants, on devra rester comme ça et trouver un autre moyen de contourner le visual spoofing.
On a bien un identifiant unique sur la table
accounts
(ouusers
), mais ça commence à être difficile à identifier.Au final, peut être que le plus simple est de directement afficher le numéro de account à la place du login et de ne pas essayer de normaliser les logins.
Il faut aussi que j'essaie de voir ce que donne le
slug
du user (généré à partir du login) quand on essaie de l'attaquer par visual spoofing.Si jamais, vous voulez tester, utilisez plutôt le site https://alpha.linuxfr.org au lieu de la production svp ;)
[^] # Re: nomenclature et mitigation
Posté par Krunch (site web personnel) . Évalué à 3 (+0/-0).
Je pense qu'une solution de ce style est la plus pratique mais, en admettant que le numéro d'account soit séquentiel, ça risque de donner plus « poids » aux comptes plus anciens qui ont un plus petit numéro. Ce qui rendrait Linuxfr encore moins accueillant pour les nouveaux qu'il ne l'est déjà. Je pense qu'un numéro « aléatoire » serait préférable (même si c'est juste un hash du numéro d'account).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: nomenclature et mitigation
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+0/-0).
Oui on a fait disparaître la plupart des identifiants des 'accounts' et des 'users', ce n'est pas pour les remettre maintenant.
# Contre _o/
Posté par seeschloß (site web personnel) . Évalué à 2 (+0/-0).
Je tiens à préciser que je suis contre la restriction des caractères autorisés dans les noms d'utilisateur, pour des raisons évidentes.
[^] # Re: Contre _o/
Posté par Krunch (site web personnel) . Évalué à 3 (+0/-0).
Pour autant que je sache, ton nom d'utilisateur est entièrement en ASCII. Ton « nom » ou « prénom » dans tes préférences est différent. D'ailleurs cette notion de nom/prénom est problématique et il serait sans doute une bonne idée de laisser un champs unique libre https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
Je suis d'accord que limiter les caractères autorisés (dans le nom d'utilisateur ou le nom affiché) n'est sans doute pas la meilleure solution.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Contre _o/
Posté par seeschloß (site web personnel) . Évalué à 5 (+0/-0).
Mon nom d'utilisateur est seeschloß avec un ß.
L'URL vers mon profil est normalisée en "seeschloss", ce qui aurait pu poser problème si mon ancien utilisateur (seeschloss sans ß) avait encore existé au moment de la migration de l'ancien DLFP sous Templeet vers le nouveau DLFP RoR.
# Je suus Enzo Bricolo
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 5 (+0/-0).
et j'approuve ce message !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.