Gérer la sécurité de son site Drupal

Rodolfo Ripado | Frédéric G. Marand

Nous sommes ...

Rodolfo Ripado (alias gaspaio)Responsable offre DrupalContributeur Drupal

Frédéric Marand (alias fgm)Gérant Mainteneur Drupal Core

Qu'est-ce que la sécurité d'un site ?

" Un site est sécurisé si les données privées restent privées, s'il ne peut pas être dégradé ou déconnecté par un visiteur, si les ressources du site sont utilisées correctement,et si le contenu ne peut être modifié que par des utilisateurs dûment autorisés. "

Greg Knaddison (alias Greggles), Cracking Drupal

Les attaques les plus courantes

Source : http://drupalsecurityreport.org/about-drupal-security-report

Les types de failles

Injection SQLCSRF, ...

XSS

Access BypassAuthentication / Session

Authentification : qui suis-je ?

L'authentification est le processus qui consiste à déterminer si quelqu'un est réellement qui il prétend être.

Par défault :● Authentification par login + mot de passe (salé, sha512)

● Core optionnel: OpenID (D6/D7)

● Pour se protéger davantage : password_policy, flood_control

De nombreuses autres possibilités : LDAP, ...

L'usurpation d'identité

Eavesdropping ou le vol de sessions

● Protection : se connecter en HTTPS

Phishing ou le vol des identifiants personnels

● La meilleure protection : l'éducation des utilisateurs

L'autorisation : que puis-je faire ?

L'autorisation est l'association de droits d'accès à des ressources

Tout affichage, toute action doivent pouvoir être contrôlés !

Les moyens de contrôler l'accès :● Les utilisateurs, les rôles et les permissions

● Le menu system

● Les grants et node_access/entity_access

Les XSSet les moyens de se protégerLe modèle de protection Drupal contre les XSS:

● En entrée : écrire la donnée brute

● En sortie : filtrer en fonction de la destination: l(), [get_|s]t(),placeholders, check_*(), [_]filter_xss*(), drupal_strip_dangerous_protocols(), drupal_attributes()

● La couche de thème○ templates vs template.php / modules○ D8: Twig

● RTFM: http://drupal.org/writing-secure-code

Les CRSFet les moyens de se protégerLe modèle de protection Drupal contre les CSRF:

● Ne jamais déclencher une action modificative sans une confirmation sécurisée○ FormAPI: le jeton caché

● Si GET est nécessaire○ drupal_get_token()

● Impact ○ performances○ expérience utilisateur

Les injectionset les moyens de se protégerLe modèle de protection Drupal contre les injections SQL:● D7/D8: DBTNG● D4/5/6: db_query() / db_placeholders()● Views: les handlers d'arguments

Et contre l'access bypass● Individuel

○ menu loaders○ node_access()/entity_access()

● Listes○ D6: db_rewrite_sq(l()○ D7/D8: addTag('node_access')

Les failles .... et les défenses

Injection SQLCSRF, ...

XSS Text filters

Db Abstraction

AuthenticationMenu system / Node grants

Form API, ...

Access BypassAuthentication / Session

La surface d'attaque est vaste ...

● Unicode invalide: plusieurs SA au fil des ans● Redirections incontrôlées● preg_replace('/e')● L'exploitation des exports

○ Logs○ Backups

● L'accès aux fichiers○ D7/8: les espaces de stockage sur stream wrappers○ D4/5/6: l'accès privé

● La révélation des ids de session● Session vs $_COOKIE

La solution en un mot : formation

● RTFM: Drupal est l'un des projets les mieux documentés du

monde OpenSource

● Suivre les SA-Core|Contrib

● Les livres

● Les formations gratuites: tutr.tv, blogs,

événements communautaires

● Les formations payantes:

○ Traditionnelles

○ Vidéo

Prévenir, trouver, corriger les failles du Code Contrib

Drupal a une commission de sécurité

Une quarantaine de bénévoles qui :● Veillent à la correction des failles rapportées

● Communiquent autour des mises à jour de sécurité

● Eduquent l'ensemble de la communauté

Prévenir, trouver, corriger les failles du Code spécifique

Drupal fournit des outils de protection, encore faut-il les utiliser à

bon escient

Il n'y a pas de recettes, uniquement des principes à respecter :

● Principe des moindres privilèges● Minimiser surface d'attaque● Éviter la sécurité par l'obscurité● Défense en profondeur

Une culture de la sécurité

Il n'y a pas de code parfait ....

● La sécurité ne s'ajoute pas à l'existant ...

● Ce n'est pas qu'une question de technique ...

● Ça concerne toute l'équipe ....

● L'éducation et la formation sont capitales !

C'est le premier jour du reste de sa vie...

● Il faut sécuriser le reste de l'architecture matérielle

● Assurer la maintenance du site

● Se préparer pour le pire

Et quand le site est prêt ...

Héberger Drupal

Les éléments de base ...

Le système de fichiers● Accès en lecture uniquement● Effacer/cacher fichiers non utilisés● Limiter l'accès aux controleurs frontaux

(cron.php, install.php, update.php, xmlrpc.php)● Bien placer son privateLe serveur Web● Nginx / Lighttpd ? -> config spécifiqueLa base de données● Un site : un utilisateur et une base de données dédiés

Au delà de Drupal ...

Drupal n'est qu'un élément de la surface d'attaque de l'application

● Sécuriser le toute la pile technologique (OS, Apache, PHP, serveur SQL, etc ...)

● Minimiser la pile technologie● Sécuriser les autres applications sur le même serveur● "Publier" le moins d'information possible● Logger soigneusement ... tout ... et l'exploiter !

○ D8 : Monolog et extensions○ D6/7: syslog, mongodb_watchdog○ Agrégation: logstash, kibana

La maintenanceLe monde évolue ... et votre application ?

Maintenir un site, c'est :

● Avoir une attitude proactive envers la sécurité

● Étudier et appliquer les MAJ de sécurité○ Drupal core, modules contrib, librairies externes

● Rester exigent et vigilant :○ Respect des bonnes pratiques○ Audits internets et/ou externes

Et un beau jour ...

Se préparer pour le pire ?Si jamais ... il nous faudra :

● Des données à étudier○ Centralisez les logs○ Rendez-les accessibles

● Des responsables de crise○ Pour décider et agir rapidement

● Des sauvegardes ... utilisables !

Mais surtout ... Un Plan !

Merci de votre vigilance