La conception non sécurisée est un des nouveaux arrivants de ce Top 10 de l’OWASP.
Une conception sécurisée repose sur un ensemble de bonnes pratiques de sécurité, ou encore une notion de risque, qui doivent être pensées dès le début de la conception de l’application.
En début d’année 2020, la société CheckPoint a découvert un risque grave pour les utilisateurs du réseau social TikTok, à cause d’un défaut de conception dans la fonction de recherche d’amis. Elle permettait d’accéder aux données d’utilisateurs comme :
leurs données personnelles (date de naissance, email…) ;
leurs posts et contenus.
Mais aussi la possibilité d’effectuer des opérations de suppression, de passer des vidéos de privées à publiques, de changer des vidéos… Ces changements pourraient aboutir à des problématiques de harcèlement moral ou de divulgation de données personnelles, par exemple.
Le problème avec une conception non sécurisée, c’est que par définition, même avec une implémentation parfaite de la solution, celle-ci ne répondra toujours pas aux principes de conception sécurisée. En effet, les différents points de vigilance à apporter, comme des contrôles de sécurité ou des rôles particuliers, n’ont pas été prévus et ne seront potentiellement jamais en place.
Cette conception non sécurisée peut s’appliquer dans toutes les strates d’un produit et de sa mise en place.
Pour l’architecte logiciel ou le développeur, il va s'agir de mettre des politiques en place, ou d’appliquer des règles de développement précises. Bien évidemment, cette sécurisation par la conception va impliquer en amont du projet une réelle phase d’étude et de questionnement pour pouvoir répondre à des réflexions comme :
Mon application utilise-t-elle des services tiers externes ?
À quelles menaces mon application sera-t-elle exposée ?
Mon application communique-t-elle avec des services internes ?
Mon application aura-t-elle différents privilèges ou droits, basés sur différents rôles ?
Peut-on restreindre la surface d’attaque de mon application, en réduisant des points d'entrées ou en restreignant des utilisateurs à certaines parties ?
Pour un acheteur, il va aussi être important de travailler avec la DSI sur la conception de son SI, pour pouvoir accueillir une application externe en toute sécurité. Là encore, de bonnes pratiques comme la réduction de surface d’exposition peuvent être appliquées. L’application la plus sécurisée qui soit ne doit pas être mise en place sur un environnement facilement exploitable.
L’auditeur ou le pentesteur, lui, devra essayer de repérer les défauts de conception provoquant les problématiques de sécurité. Cependant, le rôle de l’auditeur ou du pentesteur venant plutôt sur une fin de projet, dans le cadre de la sécurisation à la conception leur rôle devrait plutôt être celui de conseil. La phase de conception étant terminée, les expositions non anticipées seront beaucoup plus coûteuses à corriger.
Prévenez les failles dues à un défaut de conception
Concrètement, admettons que vous êtes un nouvel architecte, à qui l’on donne en charge un projet d’application web. Voici de bonnes pratiques que vous pourriez mettre en place et des points de vigilance sur lesquels vous pourriez vous focaliser :
Stockage non protégé des informations d’identification : La gestion des identités et des accès utilisateurs (mot de passe ou système de génération de certificats) doit être conçue pour être la plus fiable qu’il soit possible d’être.
Violation des limites de la confiance : Ces violations apparaissent quand des données fiables et non fiables sont stockées, par exemple dans le même data store. Les développeurs n’ont pas toujours connaissance de ce qui sera une donnée fiable ou une donnée non fiable. De plus, le back-end peut aussi permettre un échange non sécurisé de données si l’application ne dispose pas d’un mécanisme de validation des entrées fiables.
Génération de messages d’erreurs comportant des informations sensibles : La majorité des applications sont conçues pour identifier les erreurs et générer un message pour informer l’utilisateur qu’une erreur est survenue. Ces messages d’erreurs sont souvent verbeux, et peuvent contenir des informations sensibles, comme pourraient l’être un identifiant utilisateur, un mot de passe, un environnement ou toute autre donnée permettant à un attaquant de lancer d’autres attaques plus ciblées (injection SQL par exemple).
Isolement ou compartimentation inappropriés : Cette problématique apparaît lorsque les composants ou les utilisateurs qui ont des droits, des privilèges ou des autorisations d’accès différents ne sont pas séparés. De plus, une mauvaise isolation des processus, des ressources et des fonctionnalités de l’application peut provoquer une surface d’attaque bien plus grande.
Critères d'observabilité : L’observabilité est caractérisée par la capacité de déduire l’état d’un système ou d’une application par rapport à ce qu’elle renvoie comme information. Il peut s'agir de journaux produits par exemple ou encore de métriques.
Gestion des rôles : L’architecture d’un système, application comme infrastructure, doit être étudiée en prenant en compte les différents rôles qui seront prévus, ou configurables. Une matrice d’habilitation à placer en fonction des rôles peut être un point de départ à la réflexion.
OK, j’ai bien pris en compte ces vigilances, d’accord, mais comment est-ce que je peux m’en protéger ?
Vous pourriez commencer par suivre les pratiques suivantes :
Mettre en place un cycle de vie de développement : Des frameworks, comme OpenSAMM (en anglais) existent pour formuler des stratégies de sécurité des applications adaptées aux risques spécifiques auxquels elles sont confrontées.
Mettre en place des tests unitaires et d’intégrationautomatisés : Une couverture de code complète, avec des tests automatisés, couplée à une logique de DevSecOps permettent de réduire les risques.
Gérer granulairement des ressources : Lors des phases de récupération des besoins métier, il est important de bien recueillir et évaluer les exigences techniques et fonctionnelles, dont la confidentialité des données de l’application. Ensuite, bien mettre en place et appliquer une gestion sécurisée des droits d’accès.
Séparer les couches systèmes et réseau de l’application : En divisant le déploiement en sous-systèmes modulaires ou en réseaux virtuels, il est plus facile de restreindre le niveau d'accès à des données et des ressources spécifiques. Ainsi, il est difficile pour les pirates d'étendre leur champ d'accès en cas d'attaque.
Vous l’aurez compris, une conception non sécurisée ou mal sécurisée ne peut pas être compensée par une implémentation, aussi parfaite qu'elle soit, que ce soit au niveau du développement ou au niveau SI.
En résumé
Une bonne conception est la base de toute application sécurisée.
Toujours mettre en place des tests unitaires et d’intégration fiables.
La mise en place d’un cycle de vie de développement permet d’anticiper certaines problématiques.
Les défauts de conception peuvent amener à d’autres failles présentes dans le top 10 de l’OWASP.
Dans le prochain chapitre, nous verrons les vulnérabilités dues à des composants non à jour. On y va ?
