Avril 2017, sur une instance de test en debuggant #iTop, j'avais remonté aux devs un truc qui pique les yeux…

Les types ont mis juste 3 putains d'années pour se dire que passer ne paramètres JavaScript tout le nécessaire pour se connecter à la BdD avec des privilèges élevés n'était pas une riche idée… Mon ticket est longtemps resté à l’état le statut "to-be-reviewed" . Et ce matin je reçois une notif par email « C'est résolu »…

https://sourceforge.net/p/itop/tickets/1453/

itop - ITSM & CMDB OpenSource / Tickets / #1453 Security flaw: database's privileged username and password in plaintext, in javaScript variable

Bon au même temps, ça devrait pas m'étonner, c'est les mêmes qui trouvent que c'est une bonne idée
- de d'crire dans leurs donc que leurs appli a besoin de la permission SUPER sur la BdD… sans savoir pourquoi.
- d'avoir un installeur d'appli web qui génère des URL en y mettant en dur
-- Le protocole utilisé lors de l'install en webUI
-- La valeur de SERVER_PORT (variable environnement apache) de la machine qui héberge l'application. ce qui nécessite une bidouille si NGINX

#iTop

Je vous laisse deviner ce qui se passe ne cas de migration HTTP vers HTTPS. Et surtout quand on passe en prod avec du TLS géré par un front…

Le temps qu'ils répondent, je ne gère plus d'instances #iTop (Je suis plus au poste concerné)… Ni accès au password-store pro avec la clé GPG pro-correspondante. Donc plus accès compte source forge crée uniquement pour iTop à mon ancien boulot. Je pourrai pas répondre. Et j'aurai pas la motiv pour me faire un VM juste pour vérifier la modif annoncée…

Si jamais quelqu'un veut qui utilise #iTop veut vérifier la dernière version, si c'est effectivement vérifier, et si y a toujours autant de défauts dans l'installeur…

PS : Je viens de voir que la version depuis la quelle c'est patché d'après la réponse que j'ai eu sur le ticket date du 12 juillet 2018.

Donc ils ont mis pas 3 ans à patcher leurs bordel, mais plus d'un an à le patcher, et plus d'un an à répondre au ticket, pour un total de 3 ans…

Par contre, quand je relis mon ticket, y a des parties où ça sent les typos/moment d’inattention sans relecture/mots manquants… ET je sais plus ce qu'ai voulu dire dans certains passages (qui veulent rien dire dans leurs état actuel… 🤦‍♂️ ) 😆

Par contre l'idée de base reste claire quand même, l'appli avait déjà d'autres mécanismes de récupération de login/pass BdD, moins exposés (sauf aux admins sur serveurs) et pourtant les devs les refoutent dans des variables JS pour se connecter à la BdD… 🤦‍♂️

@devnull
Pour être honnête avec toi, "les typos/moment d’inattention sans relecture/mots manquants" c'est tout le temps. Parfois je comprends rien à ce que tu dis 😅
@devnull
Je travaille pas dans l'informatique, donc ça ne me dit rien du tout

@Nel Donc même s'il y avait pas de typos et/ou mots manquants, ça resterai obscure…

En gros, les devs d'une appli web stockant des données parfois sensibles ont mis tous les paramètres de connexion à la base de données, avec des droits élèves (export et écrasement de toute la base… ) en clair, lisible depuis l'iface web, dans le code source accessible depuis le navigateur web (afficher le code source)

Sachant que doc d'install réclame plus de droits d'accès sur la bdd que vraiment nécessaire…

@devnull faudrait peut-être le renommer iPasTop.

Enfin, c’est pas grave, ce n’est pas comme ci des gens l’utilisaient 😏

🤔

@DaD Y a moyen de changer le code source pour le renommer 😆

Je te laisse deviner pour qui je bossait au moment où j'ai remonté ça 😆