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.

securite-bd

Ç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.

Advertisements

6 avis sur « Par mesure de précaution, voici les informations de connexion à la base de données »

  1. sarrazinc dit :

    OUCH!
    J’ose espérer que ce site ne s’est pas fait hacker par la suite.
    Programmeurs : faites attention à ce que vous déployez en production!

  2. Anonyme dit :

    Bonjour,

    Si vous regardez bien c’est l’implémentation de Connector qui donne ce message d’erreur.
    Il arrive souvent dans des petits sites internet que les développeurs ne désactivent pas certaines options comme le debug, c’est très classique. S’il est vrai que cela donne des infos (notamment le nom des tables) , cela est rare qu’il y ait le mot de passe de base de données. Cela est très classique.
    Sinon rien à signaler, pour un petit site cela n’est pas problématique de mettre la base de données sur le même serveur que le site web (pensez à verouiller les ports).

    Enfin le mot de passe root est celui de root = admin MySql, pas celui de Linux, heureusement. 8 caractères avec des caractères spéciaux, ce n’est pas déconnant (tant que ce n’est pas des mots de passes du dictionnaire).

    Par contre, il y a toujours la faille de mauvaise configuration de phpmyadmin …

    Je pense qu’avant de critiquer le php, qui est éprouvé, vous devriez être plus zen, car cela est plus un problème de config du serveur. Votre serveur web est-il pour autant bien configuré?

    Cordialement

    VGib

    • Effectivement, c’est rarement la faute du langage. Dans ce cas-ci, le framework, en cas d’oubli, ne donne pas de protection supplémentaire. C’est surtout ça qui est à retenir.

  3. elgora dit :

    Ah un clash sur laravel, comme c’est étonnant pour un dev asp.net corrompu par bilou. ;)

  4. sandy666 dit :

    On aime pas php, mais on crée un blog sous worspress. ^^’

  5. […] Le billet que j’ai aimé le plus écrire : Par mesure de précaution, voici les informations de connexion à la base de données […]

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment ce contenu :