3 histoires d'horreur de développeur pour Halloween

🎃 J’ai supprimé une base de données en production

Anne avait moins d’un an d’expérience en tant que programmeuse.

Son patron à l’époque gérait plusieurs sites de clients, principalement des pages d’atterrissage. Il était fan de l’hébergement partagé, car toutes les options pour configurer le “serveur” sont disponibles via une interface web et on n’a presque pas besoin d’utiliser le terminal, une grande erreur à long terme à mon avis.

Le patron a partagé les accès à la base de données avec Anne, et comme Anne ne voulait pas utiliser phpMyAdmin qui venait avec Cpanel, elle a utilisé un logiciel Mac cette fois-ci.

Au moment d’ouvrir le programme, elle a fait une liste de toutes les tables sans aucun problème. Elle a exécuté quelques requêtes pour vérifier si la connexion fonctionnait correctement.

Ce jour-là, il n’y a pas eu de problèmes, le pire allait arriver quelques semaines plus tard.

Son patron lui a demandé de supprimer manuellement certains enregistrements de clients. Oui, ils n’utilisaient pas de suppression douce, donc supprimer définitivement les enregistrements de la base de données était la seule option viable.

Parmi les instructions à la base de données qu’elle avait sauvegardées pour son environnement local, elle avait le classique delete purchases from. Elle a copié et collé la requête, mais lorsqu’elle essayait de modifier les paramètres de filtrage, elle a appuyé sur Ctrl + Enter.

5300 enregistrements mis à jour. 30ms

Et c’est là qu’elle s’est rendu compte qu’elle avait fait une erreur. Lorsqu’elle a actualisé la table, tout avait disparu. De plus, c’était une table qui n’avait pas de dépendance sur d’autres, même pas une erreur de clé étrangère n’a pu la sauver.

Elle a procédé à appeler son patron. Il ne s’est pas fâché, mais il lui a dit qu’il supposait que cela pouvait arriver à tout moment. Son patron a utilisé une sauvegarde automatique de la veille et, comme c’était un site peu utilisé, ils ont procédé à utiliser le script SQL pour supprimer, créer et remplir à nouveau la base de données.

Comme elle était junior, elle était très effrayée, pensant que ce serait son dernier jour dans l’entreprise et qu’elle n’était pas née pour être programmeuse dans cette vie.

Mais tout s’est arrangé, et à partir de ce moment, Anne est devenue dix fois plus prudente avec tout script qu’elle devait exécuter dans une base de données.

Mesures de précaution

• Dans toutes les bases de données pour les environnements de production, essayez de créer une connexion en lecture seule. Cela vous aidera à éviter d’exécuter des instructions non désirées par accident.
• Si vous utilisez un logiciel avec interface graphique (GUI) pour vous connecter à une base de données, ajoutez toujours une couleur de fond à vos connexions. Personnellement, j’utilise généralement la gamme de couleurs suivante : vert pour les bases de données locales, jaune pour les versions de staging ou QA et rouge pour les bases de données de production. Si j’ai une version en lecture seule pour la production, j’utilise généralement la couleur orange.
• Essayez toujours d’utiliser des suppressions douces comme mesure de suppression. C’est généralement un champ appelé deleted_at (supprimé_à). La valeur NULL est interprétée comme signifiant que l’enregistrement est actif. S’il est supprimé, il aura une valeur avec la date et l’heure auxquelles la suppression a été effectuée. Cependant, votre logique d’application doit prendre en charge le masquage de ces enregistrements pour l’utilisateur final.

🎃 Un e-commerce piraté

Il y a plusieurs années, un collègue d’un ancien travail a recommandé Max à un client avec un site Wordpress développé par une agence de développement.

L’histoire d’horreur n’était pas seulement que le site avait même le noyau de Wordpress modifié (mon dieu), mais aussi que le code des plugins eux-mêmes était modifié, ce qui rendait impossible l’application d’une future mise à jour sans craindre de tout casser.

Au fil des ans, il a été possible de migrer vers un logiciel sur mesure, réalisé avec un framework. Après la migration, tout s’est bien passé pendant une année entière.

Jusqu’à ce qu’un jour, la propriétaire du site appelle Max.

• Max, on nous a piratés
• Il n’y a pas de piratages, seulement des failles de sécurité du côté de l’utilisateur - a répondu Max, supposant que quelqu’un avait peut-être partagé son mot de passe par erreur.
• Regarde le site web ! Il est rempli d’images en russe !

Et c’était vrai, ils avaient remplacé les images des produits et les bannières d’appel à l’action du site web par un tas de propagande que Max n’a pas comprise ni voulu comprendre.

• Oups - a dit Max en observant les dégâts.

Max a procédé au blocage du site web. Il est entré avec SSH sur le serveur et il n’y avait aucun type de fichier étrange ou codé qui lui faisait soupçonner qu’ils avaient accès à la base de données. Après un moment à continuer de réfléchir par où l’intrus avait pu entrer, il n’est arrivé qu’à une seule conclusion.

“Le panneau d’administration pour télécharger des images”

Et en confirmant avec les employés, il s’est avéré que pour accéder rapidement au panneau d’administration, ils avaient changé le mot de passe pour un simple, comme “test123”.

Aucune image n’a été perdue, car elles étaient téléchargées sur un stockage d’objets (similaire à AWS S3), et lorsque les images sont remplacées, elles ne sont JAMAIS supprimées. Ceci pour émuler la fonctionnalité de versionnage qu’AWS S3 possède.

Max nous envoie également les mesures de solution et les précautions futures pour éviter d’éventuelles défaillances.

Mesures de précaution

• Tous les mots de passe ont été changés pour une version plus compliquée, pour le moment j’ai supprimé l’option de changer le mot de passe pour tous les types d’utilisateurs.
• Ne pas permettre à l’application de supprimer les images une fois utilisées. Toujours stocker les choses en dehors du serveur.
• La base de données était également en dehors du serveur, ce qui a permis de revenir à une version d’il y a 3 heures avant l’incident. Quelques enregistrements de certains achats ont été perdus, mais ils étaient déjà sauvegardés dans un logiciel externe de facturation.
• Divisez les utilisateurs qui peuvent mettre à jour les informations du site avec des rôles et des permissions. Avec cela, les attaquants n’ont pas non plus eu accès aux informations des clients.

🎃 Sans argent, j’ai dû licencier les développeurs

En 2017, Jean avait sous sa responsabilité deux développeurs juniors. Il travaillait à ce moment-là pour une startup. Il avait reçu des fonds de capital-risque et les ventes étaient “ajustées”.

C’est alors qu’il a découvert que, lorsque les entreprises n’obtiennent pas d’argent, il est difficile de maintenir un salaire stable pour tous les travailleurs.

Il est difficile de licencier quelqu’un d’une entreprise. En tant que cofondateurs, nous sommes fiers que nos employés aiment notre entreprise, oubliant qu’ils le font aussi pour subvenir aux besoins d’une famille, payer l’hypothèque d’une maison ou une voiture, etc.

Après une période de plus de 3 mois sans atteindre les ventes attendues, Jean et ses associés ont décidé de licencier les développeurs qui avaient été embauchés pour une période de 6 mois.

Les deux autres cofondateurs ont dit à Jean qu’il serait responsable de communiquer cette décision, car ils n’avaient pas encore de responsable des ressources humaines.

Jean est arrivé un vendredi et a communiqué la nouvelle aux deux développeurs. L’expression des deux était de déception totale. Jean a pu comprendre en partie, car il ignorait les situations difficiles que chacun pouvait traverser.

Le maximum qu’il a pu offrir était de préparer une lettre de recommandation.

Il n’y a pas de mesures de précaution écrites par Jean, mais du côté des affaires, je crois que je me sens libre d’en écrire quelques-unes.

Mesures de précaution

• N’embauchez pas plus que ce que vous pouvez maintenir. Il existe une phrase populaire : “embauchez lentement, licenciez rapidement”.
• Ne faites pas de promesses exagérées aux travailleurs ; montrez du positivisme, pas des mensonges exagérés. Il vaut mieux dire : “Nous sommes une startup, jusqu’où nous irons dépend de nous” au lieu de : “Nous allons être les meilleurs de ce pays, nous allons atteindre la lune”.
• En tant que fondateur, rappelez-vous que confier votre entreprise à vos travailleurs, c’est comme confier le soin de votre enfant à un étranger. Personne ne l’aimera plus que vous.