Comment protéger ses données sensibles ? (1/2)

Partie 1 : une reflexion globale

Dans la conception d’application web il existe un grand nombre de vulnérabilités qui ne découlent pas directement des actions de développement. C’est particulièrement vrai lors de l’usage de CMS comme Drupal où un certain nombre de configurations liées à la sécurité d’accès aux données peuvent être réalisées et où le système applicatif natif du CMS peut donner l’illusion d’une sécurité par défaut. Certes c’est le cas nativement, mais dès l’ajout de modules ou simplement dès la mise en place de configurations liées à la sécurité, la vigilance s’impose. En effet, des vulnérabilités existent alors du fait d’inattentions, d’erreur de conception ou même du fait de configurations par défaut trop permissives. Il est important d’adopter une attitude de vigilance vis-à-vis de ce type de problèmes et de s’assurer d’un ensemble de tests suffisamment exhaustifs pour que l’application soit totalement sécurisée.

Protéger les données sensibles

Une défaillance de contrôle d’accès est un cas classique de vulnérabilité découlant, la plupart du temps, d’un manque de vigilance sur les permissions d’accès. Par exemple, le site drupal.org permet de facilement de consulter le profil utilisateur de chaque membre (https://www.drupal.org/user/1). Dans ce cas précis ce comportement est autorisé et souhaité, mais dans d’autres cas on pourrait souhaiter limiter l’accès de ces informations à l’utilisateur concerné uniquement (par exemple si le profil de l’utilisateur expose des données à caractère sensible).

Un tiers mal intentionné aura tôt fait d’essayer de modifier un identifiant dans l’url pour tenter d’accéder à un profil autre que le sien et pourrait, dans ce cas, éventuellement accéder à des données qui ne lui sont pas initialement destinées.

Cela devient plus sensible encore si un utilisateur détient des permissions d’édition qui lui permette de modifier les valeurs d’un profil qui n’est pas le sien en manipulant un identifiant dans l’url d’édition de son compte.

L’exposition de données sensibles est un cas extrêmement fréquent qui se produit la plupart du temps lors de l’affichage d’erreurs techniques. Les rapports d’erreurs sont des informations dont l’affichage doit être contrôlé. Ils ne servent à rien aux utilisateurs finaux et sont même souvent davantage une gêne pour eux. Ils sont utiles aux technicien(ne)s dans leur travail mais sont extrêmement redoutables pour informer les tiers mal intentionnés sur le contexte d’usage de l’application.

Une défaillance d’authentification se produit lorsqu’une application tente de mettre en place des règles de sécurité sur la création de ses mots de passe utilisateurs mais que les règles en question fragilise davantage la sécurité des codes choisis (par exemple des mots de passe de moins de 8 caractères, sans caractères spéciaux, contenant au moins un caractère majuscule, minuscule, pas de copier-coller, etc).

Ces vulnérabilités complètent le lot des défaillances les plus fréquentes que nous avons vu jusqu’ici. Celles-ci sont toutefois moins évidentes à se figurer au quotidien. En effet, les frameworks, CMS et modules/bundles afférents délivrent souvent des comportements par défaut qui peuvent être source de problème. Malheureusement ces éléments ne sont pas toujours vérifiés par une équipe qui souvent se focalise sur le fait d’adresser des problématiques fonctionnelles complexes pour un client et se repose sur ses outils avec confiance. De fait, des erreurs ont tôt fait d’être commises et c’est pourquoi il faut redoubler de vigilance.

1. Défaillance de contrôle d’accès

HTTP est un protocole stateless, il ne stocke aucune information de session pour l’utilisateur qui lance la transaction. Il est donc nécessaire de toujours vérifier les accès utilisateurs qui sont réalisés. Sur Drupal en particulier cela revient au fait de cadrer l’assignation des permissions utilisateurs à la fois en lecture et en édition. Il est également impératif de réfléchir à l’ensemble des entités déployées sur un site qui pourraient être concernées par des notions de sécurité (par défaut toutes le sont). Par exemple définir une politique d’accès pour l’ensemble des vues (views), contenus, termes de taxonomies, autres types d’entités.

En terme de logique d’implémentation un(e) technicien(ne) doit prendre l’habitude de vérifier les possibilités d’accès aux données manipulées le plus tôt possible dans son code afin d’exclure toute forme de traitement malicieux lié à un manque de contrôle d’accès en amont.

Pour les formulaires doivent toujours être protégés au maximum car ils sont un point d’entrée direct à la base de données. Dans le cas de Drupal cela signifie que toute implémentation de formulaire devrait toujours passer par la FormAPI qui gère nativement la sécurisation du formulaire rendu.

Dans le cadre d’implémentations moins cadrées (qui ne sont définitivement pas recommandées avec le CMS Drupal) il est important de définir que toute opération d’écriture en base devrait toujours être réalisée par des formulaires envoyés avec la méthode POST pour assurer un minimum de contrôle sur les données envoyées. De même le formulaire doit disposer d’une protection contre les attaques de type cross-site request forgery (CSRF) qui permettent à un tiers mal intentionné de soumettre un formulaire sans l’avoir préalablement affiché.

Enfin la protection des cookies est également importante pour s’assurer qu’ils ne soient pas utilisés via des attaques de type CSRF ou XSSI (cross-site script inclusion). Cette sécurisation passe par l’usage d’un attribut « SameSite » dans l’en-tête http « Set-Cookie ». La définition de cet attribut en mode « strict » interdira l’envoi du cookie si la requête ne provient pas du même site web.

2. Exposition de données sensibles

Les messages d’erreur et les traces du stack ne doivent en aucun cas être affichés sur les environnements finaux ! Il est nécessaire de considérer leur affichage comme une exception particulière sur les environnements de développement. Toutefois il est important d’en conserver une trace, ceux-ci devraient donc être journalisés comme n’importe quel autre message de l’application. Drupal gère déjà un log des principaux problèmes rencontrés et permet de délivrer nativement un degré d’information adéquat une fois correctement configuré.

Il est également important de prendre l’habitude, en tant que technicien(ne), de mettre en place des error handlers et de lever des exceptions pour ne pas laisser la gestion des erreurs à PHP directement mais bien à la logique du code implémenté pour permettre un traitement efficace des erreurs et limiter leur propagation aux seuls traitements que l’on souhaite pour elles.

Il est important de s’assurer de contrôler tous les headers qui sont délivrés sur les pages, dans les e-mails, etc. Un header qui affiche la version courante de PHP ou bien le fichier qui a généré un mail donne un indice à un tiers mal intentionné sur les failles potentielles qu’il peut utiliser. Il est donc impératif de s’assurer de donner le moins d’indice possible sur l’environnement technologique via ces éléments.

Toute données sensible stockée en base de données devrait être hashée à minima et encryptée au mieux (mots de passe, numéros de carte de crédit, etc). Drupal gère nativement le mot de passe d’un utilisateur mais il est important de garder à l’esprit ce type de considération lors de la conception de l’architecture d’un projet.

Enfin, la moindre des mesures est de toujours utiliser un protocole d’échange sécurisé pour l’ensemble de la navigation, en l’occurrence HTTPS.

3. Défaillance d’authentification

Les règles de gestion de mots de passe évoluent sans cesse face à la puissance toujours plus grande des machines qui permet un crackage toujours plus rapide de ces derniers. Il est donc essentiel de rester vigilant à définir des règles efficaces.

Le fait de forcer une rotation des mots de passe utilisateur n’est plus une bonne recommandation. Les utilisateurs finissent par ajouter un chiffre en fin de mot de passe ou bien par utiliser des mots clés pour se souvenir de leur mot de passe et la politique de sécurité est compromise par le contournement humain de la consigne. Nous disposons aujourd’hui de password managers qui nous permettent de déléguer la mémoire de longs mots de passe complexe à des outils et rendent ce type de rotation caduques.

La longueur des mots de passe doit être correctement établie, aussi bien dans sa limite basse que dans sa limite haute. Une ancienne faille de sécurité de Drupal consistait justement en l’absence de limite haute pour les mots de passe qui résultait en la possibilité d’attaquer les sites avec des mots de passe tellement longs que le hashage de la chaîne provoquait une saturation du serveur. Une taille raisonnable de mot de passe aujourd’hui se situe entre 8 et 72 caractères environ.

Enfin, il est impératif de correctement définir la politique de réinitialisation du mot de passe / de l’identifiant utilisateur. Le formulaire qui permet de réaccéder à son compte si l’on a perdu ses identifiants n’est rien d’autre qu’une backdoor vers la liste des utilisateurs. C’est l’endroit où l’on doit être le plus défensif vis-à-vis des saisies utilisateurs et le plus complet dans les scénarios de comportement possibles pour s’assurer de n’être permissif à aucun endroit.

Conclusion

La sécurité n’est pas uniquement une affaire de code et de qualité des implémentations, c’est une réflexion globale qui doit amener les technicien(ne)s à s’interroger sur des cas d’usage de leur application qui ne sont pas nécessairement des parcours utilisateurs classiques et peuvent aboutir à des divulgations importantes. La méfiance est de rigueur, même l’usage d’API, d’un framework ou d’un CMS ne peut pas être un argument suffisant pour s’abstraire d’une réflexion complète sur le sujet. Il est alors important de connaître les cas d’école classiques pour pouvoir envisager les situations les plus complexes où une donnée pourrait être amenée à fuiter ou à être modifiée par la mauvaise personne.