Suivi — Comptes utilisateurs falsification d'identité par unicode

#2035 Posté par  (site web personnel) . État de l’entrée : ouverte. Licence CC By‑SA.
Étiquettes :
6
22
août
2022

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 CY­RIL­LIC SMALL LET­TER 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  (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  (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  (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  (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:

      LOGIN_REGEXP = /\A[\p{Word}.+\-]+\z/

      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  (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:

        Instead, the Consortium recommends processing strings to remove basic equivalences, promoting adequate rendering support, and putting restrictions in place according to script, and restricting by confusable characters. While the ICANN guidelines say "top-level domain registries will […] associate each registered internationalized domain name with one language or set of languages" [ICANN], that guidance is better interpreted as limiting to script rather than language.

        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):

        For equivalence of identifiers, preprocess both strings by applying NFKC and case folding. Display all such identifiers to users in their processed form. (There may be two displays: one in the original and one in the processed form.) An example of this methodology is Nameprep [RFC3491]. Although Nameprep is currently limited to Unicode 3.2, the same methodology can be applied by implementations that need to support more up-to-date versions of Unicode.

        • [^] # Re: nomenclature et mitigation

          Posté par  (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  (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  (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  (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  (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:

                  • on ajoute une nouvelle colone "normalized_login" et on y stock les logins normalizés
                  • dans le contrôleur de Ruby on a joute un validateur qui contrôle l'unicité sur cette colonne à la création du compte
                  • les comptes existants en conflits devront être traités à la main: si on a un email, on peut les contacter pour leur donner un nouveau login; si non, je ne sais pas ce que l'on peut faire.

                  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 (ou users), 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  (site web personnel) . Évalué à 3 (+0/-0).

                    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.

                    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.

  • # Contre _o/

    Posté par  (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  (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  (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  . É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.