Posts taggués ‘drupal’



30
Nov

CMS: quelques conseils d’ami

Ce soir billet un peu technique, pour ceux qui ne comprendraient pas tout n’hésitez pas à commenter.

J’ai réalisé quelques audits de code / tests d’intrusion sur des CMS dotés d’extensions faites maison et force est de constater que des Web Agencies sérieuses ne sont pas vraiment au top quand il s’agit de développer de façon sécurisée !

Chers développeurs, chers clients, voici donc cinq conseils  pour que vos applications ne se fassent pas “trop” trouer !

1 – On ne touche pas au coeur du CMS:

Quand on développe pour un CMS, que ce soit Joomla, Typo3, Drupal ou autre, la première règle est de ne JAMAIS modifier le moteur de la solution.

Si cette règle n’est pas respectée votre application ne pourra plus être mise à jour facilement voir ne pourra pas être mise à jour du tout.

Si votre application nécessite un développement spécifique, la bonne pratique veut donc que l’on développe une extension / un module / un plugin !

2 – On met à jour régulièrement:

Un gros paquet de sites se font défacer (ou pire) juste à cause d’un manque de mise à jour.

La plupart des CMS proposent des systèmes de mises à jour internes (dans le backend généralement) pour le moteur et pour les extensions (pour peu qu’elles soient maintenues correctement).

Pensez donc à surveiller régulièrement et à mettre à jour si nécessaire, cela vous évitera de vous faire trouer par un gamin de 15 ans qui aura trouvé un exploit sur le net !

3 – On utilise l’API et on lit la doc:

Tous les CMS fournissent une API pour le développement des extensions… Bien souvent cette API est bien documentée et dotée de fonctions très pratiques…

Pensez donc à RTFM avant de vous jeter tête baissée dans le code, cela vous évitera de réinventer une roue carrée !

Quelques exemples:

  • Les fonctions filter_xss et db_query de Drupal permettent d’éviter les attaques XSS et les injections SQL
  • Typo3 fournit tout une classe pour effectuer les requêtes SQL avec plusieurs fonctions permettant d’éviter les injections SQL également
  • Joomla donne des conseils de “coding style” qui abordent également le sujet des injections SQL

Vous trouverez peut-être que j’insiste un peu trop sur les injections SQL mais cela me semble important tant je croise de développeurs qui n’ont pas été formés sur ces problématiques !

4 – On journalise:

La journalisation n’est pas à prendre à la légère, elle fait partie des problématiques sécurité standard: les critères DICP pour Disponibilité Intégrité Confidentialité et Preuve.

La journalisation entre dans la case preuve, car bien qu’elle serve le plus pour débugger les journaux sont bien pratiques quand il s’agit d’effectuer un audit post-mortem !

Si votre application se fait pirater, les journaux sont indispensables pour identifier les points d’entrées des attaquants et les corriger.

Ils peuvent également servir pour un éventuel dépôt de plainte. Pensez-y, cela n’arrive pas qu’aux autres…

5 – On valide les entrées utilisateurs:

Dernier conseil et pas des moindres car c’est là dessus que repose principalement la sécurité d’une application web: validez les entrées utilisateurs.

Dès que vous fournissez un point d’entrées aux utilisateurs, demandez vous:

  • Quel type de données est attendu
  • Est-ce que j’ai validé le contenu ? Est-il conforme à ce que j’attends ?
  • Est-ce que j’ai encodé le contenu avant de l’afficher ?

Bon dév à tous 🙂

Celadon theme by the Themes Boutique