Audit de sécurité : 4 - Fichiers inutiles

Développé avec le C.M.S. Drupal (dans sa version 7), notre site présente de nombreux fichiers de documentation présents dés son installation : CHANGELOG.txt, INSTALL.mysql.txt, README.txt, etc...

Au fur et à mesure que nous enrichissons le C.M.S. avec de nouvelles fonctionnalités, de nouveaux "modules", cette liste de fichiers inutiles s'allourdit grandement.

Lorsque l'on effectue des recherches d'url sur le site, il est possible de trouver de nombreux fichiers librement accessibles qui ne semblent n'avoir aucun rapport avec le fonctionnement du site en lui-même. Ces fichiers accessibles sans authentification sont, pour la plupart du temps, liés à de la documentation, des fichiers de développements, etc

Ces fichiers sont accessibles sans authentification, ce qui permet à un attaquant de récupérer des informations afin d'identifier de potentielles vulnérabilités.

Il est conseillé de supprimer l'ensemble des fichiers non nécessaires au fonctionnement du site en production.

Il est ensuite conseillé de limiter les accès aux ressources non supprimables pouvant révéler des informations sensibles à des utilisateurs malveillants, par exemple en demandant une authentification de l'utilisateur.

Cette problématique posée par l'audit de sécurité est l'exemple parfait des réflexions que je m'impose sur mon travail et sur la gestion d'un projet web : la maintenabilité !!!

D'un coté, nous avons une préconisation pour la sécurité du site : supprimer certains fichiers (et / ou en limiter l'accès). Et d'un autre coté, nous avons une procédure de mise à jour de Drupal et de ses composants, liée également à la bonne sécurité du site et qui aura pour effet de réimplanter ces fichiers à chaque fois.

Pour répondre à cette problématique, plusieurs solutions possibles :

• Je supprime les fichiers et je ne met pas à jour mon C.M.S. et ses modules.
  Je suis en sécurité, jusqu'à la prochaine mise à jour de sécurité de Drupal ! Le contrat est rempli, mais je risque d'avoir de mauvaises surprises sur mon site dés qu'une faille de sécurité va être révélée. On oublie direct !!!
• Je supprime les fichiers et je met à jour mon C.M.S. et ses modules.
  Je suis en sécurité à 100%. Enfin presque, car il va falloir que je pense à supprimer à nouveaux ces fichiers lors des mises à jour de Drupal et des ses modules. De plus, cela risque d'être couteux niveau temps.Sur le long terme, je risque d'investir trop de temps pour la suppressions de ces fichiers : cela ressemble à de la dette technique déguisée.
• Je ne supprime pas les fichiers et je met à jour mon C.M.S. et ses modules.
  Je ne suis pas en total sécurité. Mais en croisant les doigts et en allumant une bougie à la date anniversaire de la mise en production du site, peut-être qu'il ne se passera jamais rien... Mouais... Nous savons tous que le hasard n'est pas une statistique fiable en sécurité informatique. Pourquoi pas ?

D'ailleurs, je n'ai pas hésité à solliciter la communauté Drupal sur Twitter pour ce sujet...

Au final, il restait une solution non exploitée : celle de restreindre l'accès à ces fichiers via une règle apache.

Cette règle est à placer soit dans le fichier .htaccess de Drupal, soit en amont au niveau du serveur dans une règle plus générale.

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule ^(.*)README\.txt$ - [F]
  RewriteRule ^(.*)README\.md$ - [F]
  RewriteRule ^(.*)README\.markdown$ - [F]
</IfModule>

Dans cet exemple, nous interdisons l'accès aux fichiers suivants :

• README.txt
• README.md
• README.markdown

J'ai réussi à trouver un compromis entre sécurité et maintenabilité.

D'un coté, l'accès aux fichiers est restreint. De l'autre, il reste facile de mettre à jour le CMS sans mettre en péril son bon fonctionnement ou se créer de la dette technique.

La résolution de ce point a donc été peu onéreux et temps : quelques lignes de code ont suffit pour répondre à cette problématique.

Ce choix technique est devenu une bonne pratique à appliquer à l'ensemble de mes projets.