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

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

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


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

http://www.osinet.fr/

http://bit.ly/drupalosinet

https://twitter.com/OSInet

http://drupal/u/fgm


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


BUY


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.

Achat


Le cas des appels d’offres publics

Achat

• 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

Achat


BUILD


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

Build


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

Build


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

Build


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…)

Build


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

Build


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)

Build


Hacker core/contrib

Build

• 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)

Build


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

Build

• 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

Build


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

Build


OWN


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

Own


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…

Own


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

Own


Déployer sur unsystème de fichiersinapproprié

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

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

Own


Maintenanceapplicative :corrective etadaptative


Own

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


Own


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

Own


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)

Front


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

Front


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

Front


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

Front


Domain sharding

Front

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


BACK


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)

Back


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

Back


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

Back


Back

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)

Back


Trop grand nombre de requêtes SQL

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

SOLUTION Manuelle

Back


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

Back


Autres problèmes courants

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

Back


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


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

[email protected]

Software

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