Par mesure de précaution, voici les informations de connexion à la base de données

Un dimanche matin. Il y a quelques semaines. Peu après m’être réveillé, je prends le iPad pour aller lire les nouvelles du jour. Au déverrouillage de la tablette, la page que ma conjointe avait consultée lors de sa dernière visite s’actualise dans cet état.

Ça, c’est ce que l’on appelle une belle séance d’amateurisme professionnelle. Juste pour éviter de me retrouver en justice, j’ai noirci les parties qui identifient la compagnie et le mot de passe utilisé pour la connexion à la base de données.

Avouez-le, en regardant l’image, j’ai senti votre estomac se nouer en sympathie au développeur qui a eu à régler le bobo en urgence un dimanche matin. N’est-ce pas?

La chose qui n’est réellement pas drôle avec ce cas-là c’est qu’une simple défaillance de connexion à la base de données ou, du moins, au mécanisme de connexion à celle-ci a généré une page d’erreur de ce genre. Ce qui fait mal, c’est que cette page permet de déduire certaines informations au sujet de ce site web.

Par exemple:

• Le serveur web ainsi que la base de données sont hébergés sur le même serveur (host=localhost)
• L’utilisateur utilisé pour la connexion à la base de données est « root ». Pour MySQL, il s’agit de l’utilisateur le plus puissant. Il est inutile de mentionner que c’est une très mauvaise idée.
• Si vous regardez un peu, le mot de passe utilisé est de huit caractères. C’est très peu.
• Il s’agit d’un site codé en PHP. Il y a une panoplie de failles de sécurité à essayer d’exploiter.
• L’application utilise un framework nommé Laravel. L’ironie est que le slogan du framework est Love beautiful code? We do too. La page d’erreur est effectivement jolie…
• Le site en question est un site de commerce en ligne. Vous connaissez le mot de passe de la base de données. C’est une très jolie invitation pour un hacker potentiel pour tenter de récupérer des données sur vos clients.

Ce qui rend la chose amusante est que la documentation de Laravel est très claire. Il s’avère que ce message d’erreur est affiché que lorsque la variable d’environnement APP_DEBUG est à la valeur true. Cela veut dire possiblement deux choses (avec une petite réserve parce que là, le PHP, ce n’est pas ma force). Soit qu’un développeur a déployé le fichier config/app.php avec cette configuration hardcodée ou que les déclarations d’environnement de production ont été accidentellement écrasées.

Ce n’est peut-être pas exactement cela qui s’est produit. Ce n’est pas réellement important. La chose réellement fascinante est qu’une simple clé de configuration permet d’afficher tout ou rien.

La chose est un peu différente avec ASP.NET. Le mécanisme de gestion des pages d’erreurs offre une petite option supplémentaire dans ce scénario. L’attribut mode de l’élément customErrors possède trois valeurs : On, Off et RemoteOnly. L’option RemoteOnly est cette activée par défaut. Si vous ne faites rien, vous aurez une page jaune sur votre site avec très peu d’informations sur l’erreur en question.

Dans tous les cas, j’ose croire que des leçons ont été tirées. Je ne sais pas pendant combien de temps cette panne a duré. La seule chose que je sais, c’est que le lundi matin elle était résolue.

Auteur : Pascal Paradis

Je suis les mains et le cerveau derrière http://frenchcoding.com. Je développe des microservices chez @UbisoftMTL. Amateur de Hockey et j'aime la technologie, en général. Voir tous les articles par Pascal Paradis