Recueil des mauvaises pratiques constatées lors de l'audit de sites Drupal 7

1/66 • Drupal : worst current practice • © OSInet

Drupal : Best Worst current practice

Par Frédéric G. Marand

Drupagora

Paris le 14 novembre 2014

DRUPAGEDDON

CAS D'ÉCOLE : DRUPAGEDDON

LES DONNÉES

https://www.drupal.org/SA-CORE-2014-005

https://www.drupal.org/PSA-2014-003

EN PRODUCTION : un site qui ne suit pas les bonnes pratiques ades difficultés à appliquer la MàJ rapidement• Combien de minutes avant de déployer sur votre site ?• Pourquoi si longtemps ?• Comment améliorer ?• Comment gérer les suites ?

Introduction

OSInet,UN REGARD SPÉCIFIQUE DANS

L’ÉCOSYSTÈME DRUPAL

CONTRIBUTEURS AUX PROJETS LIBRES

OSInet• Contributeurs Drupal depuis

2005 • 100 % de l’effectif est

contributeur Drupal core 8 • Autres contributions depuis 94 :

Apache, Beego, Doctrine ODM,FirebirdSQL, MongoDB,Monolog, Samba, Silex…

Frédéric G. Marand• (Co-)auteur et (co-)correcteur

de plusieurs Security Advisories Drupal

• Mainteneur Drupal 7 core XML-RPC

• Mainteneur des contribs(References…)

http://www.osinet.fr

http://bit.ly/drupalosinet

@OSInet

http://drupal/u/fgm

Introduction

ACTIVITÉ

AUDIT CONSEIL

ARCHITECTURELEAD DÉV

Introduction

L’AUDIT TECHNIQUE DRUPAL

Problèmes récurrents motivant les audits :• Délais• Performance• Sécurité (réponse aux pénétrations)

Les principales erreurs se répètent par ignorance :évitez-les

Introduction

Quand les erreurs sont-ellesconstatées ?

• Durant l’acquisition• Durant la réalisation• Durant le fonctionnement

• Lors des visites anonymes

• Lors de l'utilisation en connecté

• Lors des opérations d'exploitation

Introduction

Quelles sont les erreurs les plusfréquentes ?

• Délais (coûts) excessifs de réalisation• Régressions durant le développement de code• Coûts excessifs en infrastructure• Failles XSS et autres• Performance front insuffisante• Performance back insuffisante

Introduction

Qui est source d’erreurs ?

• L’agence réalisatrice : mauvaises techniques de réalisation• Le studio graphique : maquettes ignorant les spécificités de

build Drupal• L’hébergeur : ignorance des contraintes spécifiques de

Drupal• La communauté Drupal et Open Source en général : peu de

modules / thèmes (aucun ?) ont le même niveau d’exigencequalité que Drupal core

• Le donneur d’ordres : analyse insuffisante des besoins,exigences inappropriées

Introduction

Propriété intellectuelle

Bloquer sur cession de propriété vs concession de licence

• Définition du besoin• Certification de conformité (compliance)

Ignorer l’impact de la viralité de la GPL sur les projetsDrupal• Code source PHP, JS• Assets graphiques• Contenus• Look-and-feel

PS I am nota lawyer.

Le cas des appels d’offres publics

• Difficulté à déclarer un marché infructueux mêmequand il devrait l’être

• Ne pas être à jour sur le CCAG-PI / CCAG-TIC etles circulaires associées

• Définition de l’objet du marché : site vs logiciel• Procédures de recette : spécification vs agilité

Choix des prestataires : principauxproblèmes

Agences de communicationtraditionnelles➔ Pas assez techniques pour

les projets importants

SSII (ESN) / SSLL (ENL)traditionnelles➔ Pas assez créatives pour

les projets importants

Spécialistes AMOA➔ Retour sur coût difficile à

évaluer avant un premieréchec

Drupalshops➔ Pas assez disponibles,

problèmes d’agrémentdans les grands comptes,pas assez deconnaissances autres

Maîtrised'ouvrage

Ne pas savoir choisir sa version core : 6, 7,8 et son type de développement

— Ces temps-ci…

• Projets courts, à courte durée de vie (événementiel, one-off) :

7, build basique

• Projets plus longs, livrés début 2015, destinés à une refonte

assez rapide : 7, build best practice (cf session Best Practice)

• Projets plus longs, livrés mi-2015, destinés à un cycle de vie

plus long : 8, build best practice

• Évoluer les sites bloqués en 6 en mode découplé/composant.

• Ne plus lancer de nouveaux projets en 6

Ne pas savoir définir ses choix en matièrede versions contrib

« STABLE ONLY » : de plus en plus, dans les projetsDrupal, « stable » est synonyme d'« obsolescent »

⇒ coûts de maintenance adaptative

« ANYTHING GOES » : risque que les constructeursutilisent des modules expérimentaux, sans cycle demise à jour disponible, voire non maintenus

⇒ coûts de maintenances corrective et adaptative

Et plus...

• Ne pas réceptionner au fil de l’eau — pendant lesitérations — pour intercepter rapidement lesdivergences (héritage du cycle en V)

• Lors des réceptions d’itération, ne pas vérifier l’état de propreté du site (installation from scratchpossible, absence de doublons fonctionnels, detraces de composants abandonnés...)

Processus dedéveloppement

Ne pas utiliser de gestionnaire de versions

...DU TOUT (dernier en date observé : ce mois-ci !)

...EFFICACEMENT :• code commenté en production au lieu d’être dans

une révision• commentaires de commit inutilisables• commits trop espacés• pas de process de branching réfléchi (eg: git flow,

github flow…)

Créer un site par accumulation demodules contrib à portée limitée

• Souci additionnel de qualité, fragilité, maintenanceet MàJ

• Sauf dans le cas de couverture à 100 % de lafonctionnalité, l’adaptation est à long terme pluscoûteuse qu’un spécifique

Créer un site par accumulation dechangements, sans mécanisme de

déploiement• Génération des fichiers

• Drush Makefile / Composer : – Avantages: dépôt léger, MàJ permanente

– Inconvénients : dépendance sur la disponibilité du réseau, non-compliance,MàJ permanente = risque de casse

• Vendoring : – Avantages : disponibilité, rapidité, compliance

– Inconvénients : défaut de MàJ automatique, dépôt lourd

• Profil(s) d’installation Drupal• Chargement des données par migration (Migrate API)

Hacker core/contrib

• Rarement nécessaire : le plus souvent, c’est unmanque de connaissances

• Si nécessaire, committer les patches de façonreproductible (ex : drush makefile, répertoirepatches …)

Développer en PHP brut, sans passer parles API Drupal

Exemples typiques, souvent sources de problèmesde sécurité :• API de bases de données natives au lieu de DB

API/Schema API (injection SQL)• Accès aux superglobals, notamment $_GET (XSS)• Stockage de données privées dans $_COOKIE au

lieu de $_SESSION (mascarade)• Actions de modification sur GET sans jeton ou

formulaire non protégé (CSRF)

Développer sans visibilité des erreurs auniveau maximal (error_reporting = -1)

• Les notices et warnings s’accumulent durant ledéveloppement

• En fin de projet, on constate des massesd’insertions dans dblog (2014 : 1500 insertionswatchdog/seconde sur un site) et plus le temps decorriger donc on le désactive

• Du coup, plus de suivi des vraies alertes

Tests de recette et montée en charge

Ne pas faire de TMC : toutva bien sur les postes dedéveloppement / recette

Tester sur unenvironnement non iso-prod

Tester depuis un postelocal, notamment le serveurfront

Tester uniquement enanonyme

Négliger la prise en compte des pratiquespermettant l’internationalisation

• Formats en dur (dates, nombres, monnaies) au lieudes API Drupal

• Assemblage de chaînes traduites :exemple t($a) . t($b)

• Chaînes de texte non traduites dans les templateset modules

Hébergement

Confondrehébergement etinfogéranceUn site de production abesoin d’un infogérant (services système) etnon simplement d’unhébergeur (location dematériel etinfrastructure pour leranger)

• Backups• Configuration, MàJ et

monitoring du serveurWeb et ses modules,PHP et ses extensions,bases de données,serveurs de cache,serveur de filed’attentes, etc

Déployer sans cached’opcodes ou sansmonitoring

• PHP 5.3 ou 5.4 : APC,PHP 5.5 : Opcache

• Monitoring : apc.php,ocp, opcache-status, opcache-gui…

Déployer unMemcached sanscomprendre saconfiguration

• settings.php : clusters, bins, préfixe...• extension, persistence, stratégie de

hashing, ucp/tcp, text/binaire…• slab size• Monitoring: phpmemcacheadmin,memcache.php…

• Un memcached mal réglé peut êtrebeaucoup plus lent qu’un cache en basede données

• Typique :• entrées > 1 Mo et slab size par

défaut• multisites sans préfixe,• bins saturés,• mélange chaud/froid, gaspillage

d’allocation• Documenté à partir de Drupal 7.33

Déployer sur unsystème de fichiersinapproprié

• Écritures synchrones :NFS système sansaccélérateur

• lstat() lentsprovoqués pourinclude_once -> tunerealpath cache

Maintenanceapplicative :corrective etadaptative

Ne pas appliquer les MàJ de sécurité dansles délais

Pourquoi ne pas lesappliquer ?

• Rigidités entre mainteneur etinfogérant (procédures dedéploiement)

• Absence de réactivité dumainteneur

• Difficultés de MàJ :typiquement conséquencedes hacks core/contrib

Travailler sanslogger

CAUSES TYPIQUES :• Désactivation de dblog

faute d’avoir codé àerror_reporting élevé, pour faire face auxmasses de notices

• Absence d’utilisation desyslog ou d’un mécanismeplus tolérant commemongodb_watchdog

FRONT :

PERFORMANCE

Gestion decache

Cache de pagesinterne

• Cache interne désactivé(cache enabled :décoché)

• Expiration trop courte :limitation à la scalabilitéinterne (liée à l’infrapropre) et non externe(web scale)

Pages non cachables • Écriture dans $_SESSION ou$_COOKIE pour les anonymes

• démarrage de session quimarque la page non cachable

• génération complète au hitsuivant

• grosse limite de scalabilitéramenant les anonymes à peuprès au niveau des connectés

• Utilisation de Varnish et/ou d’unCDN ou autre reverse proxy,mais émission par le code d’en-têtes de non-cachabilité

• suppression de la scalabilitéexterne

• inutilité complète de ces outils

Désaccord sur ladurée du cache

• Technique → longéditorial → court

• En l’absence d’unestratégie claire, forteprobabilité d’uneabsence de prise encharge technique valide

Agrégation des assets

• Désactivée pour le CSS et/ou le JS• généralement, ce n’est pas un oubli, mais le

prestataire indique que le site ne fonctionne pasavec : c’est le signe d’une erreur de réalisation, leplus souvent pour le code JS

• Simple : il y a des mécanismes d’agrégationavancée plus efficaces, comme le module advagg,notamment si on utilise un CDN avec le moduleCDN

Domain sharding

• ABSENCE :• Les cookies sont émis par les clients sur les

requêtes d’asset

• Avec Varnish ou un autre reverse proxy : nécessiteun VCL spécifique pour permettre de les ignorer etservir quand même de cache

• EXCÈS : multiplication des requêtes DNS pour lesclients

Et tous les problèmes du back office pour les

pages non cachées...

Requêtes sortantes durant le cycle depage

• La durée des pages devient > au temps de réponsede la ressource externe et peut bloquer

• Core:• update (uniquement pour les admins et sur

certaines pages)• aggregator, si poormanscron n’a pas été désactivé

SOLUTION Consommer dans des scripts CLI lancés parcron ou, mieux, depuis un worker de messaging externe(ex : Beanstalkd)

Pic de charge inexpliqué après unelongue durée sans problème

TYPIQUE Utilisation d’un memcached avec l’erreur t($var) et la taille de cache_locale vient de dépasser 1Mo

VARIANTE Sur un site en évolution, une nouvelle version estbeaucoup plus lente en production qu'en développement

CONFIRMATION Déboguer l’utilisation du cache avecHeisencache ou XHprof

SOLUTION À court terme, augmenter la slab size, etrapidement corriger pour revenir à une taille normale

Siteglobalementlent sans picspécifique

Cache de blocs désactivé

CAUSE Typiquement un ou plusieurs modules denode_access

CONFIRMATION Configurer stark pour n’avoir quele bloc contenu, basculer dessus momentanément, etcomparer : il devrait être considérablement plusrapide

SOLUTION 1 Repenser la logique de contrôled’accès aux données

SOLUTION 2 Introduire du cache dans chaque bloc

Cache de données

PROBLÈME 1 Cache désactivé — courant sur lessites construits sur Views et Panels

MALGRÉ le cache intégré de Views (durée) et ViewsContent Cache (invalidation)

ET MALGRÉ Panels Hash Cache

PROBLÈME 2 Utilisé à niveaux multiples

⇒ Cache de données, puis de fragments, puisd’assemblages, puis de rendu, puis de blocs … = n aller-retours vers le serveur de cache là où un seul suffirait

DIAGNOSTIC Heisencache (PerformanceSubscriber)

Too much of agood thing is

wonderful

Cache de variables toujours en MISS

CAUSE TYPIQUE Un variable_set dans un hook du cyclede page : hook_boot / hook_init / hook_exit, functionde shutdown, etc

ORIGINE Confusion entre settings/config/state(formalisés en D8)

DIAGNOSTIC var_dump(debug_backtrace(FALSE)) dans variable_set() et remonter la pile pour trouver lecoupable

VARIANTE Autres caches toujours en MISS

SOLUTION GÉNÉRALE Heisencache (WriteSubscriber)

Trop grand nombre de requêtes SQL

DIAGNOSTIC devel.module ou utiliser lesfonctions de trace de l’API DB

SOLUTION Manuelle

Trop grand nombre d’interventions dehook, notamment sur les nodes

CAUSE TYPIQUE Trop de modules

SOLUTION Réduire le nombre d’implémentationsen repensant la logique fonctionnelle

HACK hook_module_implements_alter() pour supprimer les situations connues comme nepouvant donner lieu à une modification en pratique— difficile et fragile, mais résultats rapides

Autres problèmes courants

Opérations en boucle (node_load, node_view) aulieu d’opérations multiples(node_load_multiple)

CONCLUSION

Conclusion

La clef : compétence

• Compétence du maître d'ouvrage (MOA) :déléguer n’est pas ignorer ⇒ se faire bienentourer et suivre son projet

Conclusion

La clef : compétence

• Compétence du maître d'ouvrage (MOA) :déléguer n’est pas ignorer ⇒ se faire bienentourer et suivre son projet

• Compétences internes ou AMOA• Compétence du maître d'œuvre (MOE)

Mesurer pour agir

Conclusion

• Savoir quoi mesurer• Savoir sur quoi agir

selon la mesure

Adapter

Adapter les pratiques à la taille du projet

En-dessous de quelques milliers de visites/jour,le stack Drupal/LAMP pardonne à peu près toutsauf l’absence de MàJ.

Conclusion

PASSEZ NOUS DIRE BONJOUR !

Frédéric G. Marand (fgm) Outi Munter (outi)

www.osinet.fr

OSInet

www.osinet.frsales@osinet.fr

Recueil des mauvaises pratiques constatées lors de l'audit de sites Drupal 7

Software

Drupagora 2013 : introduction drupal

PhPotes: Drupal

Drupal en bibliothèque (2009)

Drupal Performance

Présentation Drupal Magento

Séminaire Drupal 8

Applications métier avec Drupal

REX gros projets Drupal · REX gros projets Drupal Drupal Camp – Toulouse – Novembre 2011 quentin.delance@gmail.com @qdelance - +qdelance

Présentation de Drupal & Magento

Les CMS & Drupal

Reprise projet Drupal Drupagora2013

Agora cms - Comment Drupal Commerce innove avec Drupal 8

Drupal sso

LES MAUVAISES LECTURES

Drupal 9 pour le futur de Drupal - f.hubspotusercontent00.net

Présentation Drupal - WebFactory Edipresse

Présentation séminaire novembre 2011 - Drupal 7 / Drupal commerce

Drupal 8, symfony

Drupal vs Others

Drupal Par La Pratique