Développer des logiciels sécurisés : mettre en œuvre les 10 contrôles proactifs de l’OWASP

Récemment, je repensais à l’excellente session d’ouverture de la communauté DevSecCon que nous avons organisée l’année dernière, avec nul autre que Jim Manico.

Lors de cette session, Jim nous a présenté la liste des 10 contrôles proactifs de l’OWASP et expliqué comment les intégrer à nos applications web. Rédigé par Manico lui-même, avec Katy Anton et Jim Bird, le document sur les contrôles proactifs offre un aperçu de la sécurité aux développeurs qui souhaitent se lancer dans la sécurité web, comprendre les différentes couches de risques de sécurité et apprendre à s’en protéger.

Si le sujet vous intéresse, poursuivez votre lecture : nous allons passer en revue un à un les 10 contrôles proactifs de l’OWASP !

Les 10 contrôles proactifs de l’OWASP 2020

1. Définir les exigences de sécurité

2. Tirer parti des frameworks et bibliothèques de sécurité

3. Sécuriser l’accès aux bases de données

4. Encoder et échapper les données

5. Valider toutes les entrées

6. Mettre en œuvre l’identité numérique

7. Appliquer les contrôles d’accès

8. Protéger les données partout

9. Mettre en place la journalisation et la surveillance de la sécurité

10. Gérer toutes les erreurs et exceptions

Contrôle proactif 1 de l’OWASP — définir les exigences de sécurité

La création d’un produit sécurisé commence par la définition des exigences de sécurité à prendre en compte. Tout comme les exigences métier contribuent à façonner le produit, les exigences de sécurité nous permettent d’intégrer la sécurité dès le départ.

Un projet phare de l’OWASP, l’Application Security Verification Standard — souvent abrégé en OWASP ASVS — propose plus de 200 exigences pour créer des logiciels d’applications web sécurisés.

Il répertorie des exigences de sécurité concernant notamment les protocoles d’authentification, la gestion des sessions et les normes de sécurité cryptographique. Surtout, l’ASVS propose une approche par étapes qui permet de mettre progressivement en œuvre les exigences de sécurité dès vos premiers pas.

Source : GitHub

Contrôle proactif 2 de l’OWASP — tirer parti des frameworks et bibliothèques de sécurité

De quels outils avez-vous besoin pour créer des logiciels sécurisés ?

La liste est longue : protection contre les attaques par injection, authentification, API cryptographiques sécurisées, stockage des données sensibles, et bien plus encore. Pour répondre à ces enjeux, utilisez des bibliothèques de sécurité conçues à cet effet.

Veillez à suivre l’utilisation des bibliothèques open source et à tenir un inventaire de leurs versions, licences et vulnérabilités, comme les 10 principales vulnérabilités de l’OWASP, à l’aide d’outils tels que OWASP’s Dependency Check ou Snyk.

Contrôle proactif 3 de l’OWASP — sécuriser l’accès aux bases de données

Les bases de données sont souvent des composants essentiels à la création d’applications web riches, lorsque le besoin de conserver un état et de persister les données se fait sentir.

La sécurité des bases de données couvre de nombreux domaines, notamment :

• la protection contre les injections SQL grâce à des techniques comme le paramétrage des requêtes. Il est également essentiel de surveiller les vulnérabilités dans les bibliothèques ORM et SQL que vous utilisez, comme l’a montré la récente découverte d’une faille dans la bibliothèque npm Sequelize ORM, vulnérable aux attaques par injection SQL.

• une authentification sécurisée et robuste à la base de données, ainsi qu’une configuration globale sûre.

• des communications sécurisées entre la base de données et son client.

Vous souhaitez en savoir plus sur les attaques par injection SQL et les risques qu’elles représentent pour la sécurité ? Jim donne quelques conseils sur bobby-tables.com.

Contrôle proactif 4 de l’OWASP — encoder et échapper les données

Considérez toujours les données comme non fiables, car elles peuvent provenir de sources diverses que vous ne connaissez pas toujours.

Les vulnérabilités de Cross-site Scripting (XSS) illustrent parfaitement comment des données peuvent circuler dans un système et finir par déclencher du code malveillant dans le navigateur, comme du JavaScript, qui est alors exécuté et compromet le navigateur.

Les injections de commandes du système d’exploitation (OS) sont un autre exemple de situation nécessitant l’échappement des données : un composant peut exécuter des commandes système provenant d’une entrée utilisateur, avec le risque d’exécuter des commandes malveillantes. injection de commandes

Vous récupérez des données depuis la base de données. Faut-il les échapper ? Un développeur soucieux de la sécurité le fera sans hésiter. Il n’est pas réaliste de suivre et d’étiqueter chaque chaîne de caractères stockée dans une base de données pour savoir si elle est contaminée ou non. Il vaut mieux mettre en place des contrôles adaptés dans la couche de présentation, par exemple dans le navigateur, afin d’échapper toutes les données qui lui sont transmises.

Une exception extrême à cette règle : si vous décidez de créer un ou plusieurs éléments DOM de page web à partir d’une entrée de la base de données. Dans ce cas, vous vous aventurez en terrain dangereux et devez réfléchir attentivement à votre modèle et aux contrôles qui vous permettront d’atténuer les risques associés.

Voici quelques bibliothèques qui peuvent vous aider à assainir les données :

• OWASP Java HTML Sanitizer

• DOMPurify pour JavaScript

À noter : le projet OWASP ESAPI n’est plus activement maintenu. Mieux vaut donc vous tourner vers d’autres solutions.

Enfin, nous avons publié un article sur l’injection de commandes : son fonctionnement, ses risques et les moyens de la prévenir, que je vous recommande vivement de lire ensuite.

Contrôle proactif 5 de l’OWASP — valider toutes les entrées

Tout comme vous pouvez vous appuyer sur un système de typage, tel que TypeScript, pour garantir que les variables transmises dans votre code sont celles attendues et qu’elles sont valides, vous devez également vérifier que les entrées reçues correspondent à vos attentes ou aux modèles définis pour ces données.

Quelques principes généraux :

• Ne vous fiez pas à la validation pour remplacer l’échappement des données : ces mesures de sécurité ne sont pas interchangeables.

• Lors de la validation des données saisies, veillez à imposer des limites de taille à tous les types d’entrées.

Contrôle proactif 6 de l’OWASP — mettre en œuvre l’identité numérique

Comment vérifier l’identité d’un utilisateur ? À l’aide de mesures de sécurité telles que l’authentification, la vérification de l’identité, la gestion des sessions, etc.

Pour chacune de ces décisions, vous pouvez développer votre propre solution : gérer vous-même l’inscription des utilisateurs et le suivi de leurs mots de passe ou de leurs moyens d’authentification. Vous pouvez également opter pour des services gérés et profiter de l’architecture serverless du cloud, avec des services comme Auth0.

Ce sujet est vaste. Si vous devez vérifier qu’une couche d’identité numérique est gérée de manière sécurisée, consultez les recommandations NIST 800-63-3B. Ce document du NIST vous aidera à définir comment gérer la sécurité des mots de passe.

Contrôle proactif 7 de l’OWASP — appliquer les contrôles d’accès

Il est fort probable que les exigences de contrôle d’accès interviennent à plusieurs niveaux de votre application. Par exemple, lorsque vous récupérez des données depuis une base de données dans une application SaaS mutualisée, vous devez veiller à ce qu’elles ne soient pas exposées par inadvertance à d’autres utilisateurs. Autre exemple : déterminer qui est autorisé à appeler les API proposées par votre application web.

Jim conseille notamment d’éviter de coder en dur les règles d’accès en faisant référence, dans le code, aux rôles associés à l’accès aux données. Par exemple, évitez les vérifications du type if (user.role === 'admin'). À la place, une approche fondée sur les capacités, comme le contrôle d’accès basé sur les permissions, n’impose pas la politique elle-même. Par exemple : if (user.canDelete(blogPostId).

Contrôle proactif 8 de l’OWASP — protéger les données partout

Dans l’application Snyk, nous traitons les données de nos utilisateurs et les nôtres. Il est donc essentiel de veiller tout particulièrement à la sécurité et à la confidentialité de notre application, et de les protéger partout où cela est nécessaire.

Voici quelques mesures à prendre lors du traitement des données :

• Protégez les données en transit en utilisant HTTPS avec une configuration adéquate, des protocoles de sécurité à jour comme TLS 1.3 et des algorithmes cryptographiques robustes.

• Utilisez des en-têtes HTTP sécurisés qui tirent parti des fonctionnalités de sécurité du navigateur, comme HTTP Strict Transport Security (HSTS), et définissez une politique de sécurité du contenu (CSP) pour garantir la fiabilité des données.

• Pour toutes vos opérations cryptographiques, utilisez des bibliothèques reconnues et ne développez pas vos propres implémentations.

Contrôle proactif 9 de l’OWASP — mettre en place la journalisation et la surveillance de la sécurité

En tant que développeurs d’applications, nous avons l’habitude de journaliser les données qui nous aident à déboguer et à analyser les problèmes liés à des flux métier incorrects ou à des exceptions. La journalisation axée sur la sécurité est un autre type de journalisation à mettre en place pour créer une piste d’audit qui permettra ensuite de remonter aux violations de sécurité et à d’autres problèmes.

Voici quelques éléments à journaliser pour la sécurité :

• tous les échecs de validation des entrées

• tous les événements d’authentification : mots de passe corrects ou incorrects, connexions et données liées aux sessions

• tous les échecs de contrôle d’accès, notamment les tentatives d’élévation de privilèges

Contrôle proactif 10 de l’OWASP — gérer toutes les erreurs et exceptions

La bonne gestion des erreurs et des exceptions dans les applications web contribue non seulement à leur bon fonctionnement, mais permet aussi d’éviter toute fuite de données sensibles.

Suivez ces recommandations :

• Gérez toutes les exceptions de manière centralisée.

• Veillez à détecter et à gérer correctement les comportements inattendus selon une méthode standardisée dans l’ensemble de l’application.

• Veillez à ce que les données collectées ne contiennent pas d’informations sensibles, telles que des traces de pile ou des codes d’erreur cryptographiques.

Rejoignez la communauté DevSecCon

Je vous invite à rejoindre la communauté DevSecCon et à en apprendre davantage grâce à nos webinaires et à notre communauté en ligne Snyk User Community, qui aident les développeurs à se lancer dans la sécurité et à écrire du code sécurisé !