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 Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi falsification d'identité par unicode. É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
slugdu 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 ;)