CR440 – Sécurité Applicative - Cours 5 PDF

Exigences CR440 – Sécurité applicative 1 20 24-09-27  Sommaire ❑Exigences ▪ OWASP ASVS ▪ Assurance qualité ▪ Revue d’architecture ▪ Revue de code ▪ Développement piloté par les tests ▪ Validation : avantages et inconvénients ...

Exigences CR440 – Sécurité applicative 1 20 24-09-27  Sommaire ❑Exigences ▪ OWASP ASVS ▪ Assurance qualité ▪ Revue d’architecture ▪ Revue de code ▪ Développement piloté par les tests ▪ Validation : avantages et inconvénients  ASVS I ❑Le ASVS ou Application Security Verification Standard est un standard de sécurité, il regroupe des exigences de sécurité standard pour l’ensemble des applications web. C’est le point de départ pour bien définir ces exigences. Le ASVS est maintenant à la version 4.0.3. ❑Le ASVS est consultable ici : https://owasp.org/www-project- application-security-verification-standard/ ❑Le ASVS est composé de 3 niveaux. ▪ Le premier niveau est pour des niveaux d’assurance faible. C’est le minimum à mettre en place. ▪ Le deuxième niveau est pour l’ensemble des applications qui contient des données sensibles ▪ Le troisième niveau est pour les applications critiques, pour des niveaux d’assurance haute  ASVS II ❑Un exemple de requis du ASVS ❑Sur l’exigence, il y a plusieurs informations. ▪ La première colonne donne la référence du requis. ▪ Le C9 entre parenthèses fait référence aux Top 10 des contrôles à mettre en place pour la sécurité applicative : https://owasp.org/www-project-proactive- controls/  ASVS III ❑Les niveaux font référence aux niveaux du ASVS. Les niveaux sont additifs. Donc un élément du niveau 1 va se retrouver nécessairement dans le niveau 2 et 3. Depuis la version 4, ils ont ajouté le numéro de catégorie du Common Weakness Enumeration qui fait référence aux vulnérabilités que ce requis vient combattre. Exemple : https://cwe.mitre.org/data/definitions/1009.html  Contenu du ASVS I ❑Les requis sur l’architecture, le design et la modélisation des menaces ▪ Les principes d’architectures du ASVS se focalisent sur les grands objectifs de la sécurité applicative : disponibilité, confidentialité, intégrité, non-répudiation et vie privée ❑Les requis sur l’authentification ▪ Tous les requis sur les mots de passe et l’authentification. ▪ Notamment : 2.1.1 que les mots de passe soit au minimum 12 caractères, 2.1.5 : Que les utilisateurs puissent changer de mots de passe., 2.1.6 que le changement de mot de passe demande le mot de passe courant en plus de celui nouveau. 2.1.7 que les mots de passe soit validés par rapport aux mots de passe qui ont fuité ou communs. etc.  Contenu du ASVS II ❑Gestion de session ▪ Session unique et ne peut être devinée ou partagée ▪ Session supprimée ou invalidée lorsqu’elle n’est plus nécessaire ou après un certain temps. ❑Contrôle d’accès ▪ Les personnes qui accèdent une ressource détiennent une identité valide qui leur permet de le faire ▪ Les utilisateurs ont des rôles et privilèges bien définis ▪ Les métadonnées des rôles et permissions ne peuvent être réutilisées ou altérées. ❑Validation, Nettoyeur et Encodage ▪ Les I/O suivent un flux accepté et utilisé qui prévient les injections ▪ Les données sont typées, validées, vérifiées quant à leur longueur et leur plage, nettoyées ou filtrées  Contenu du ASVS III ▪ Les données de sorties sont encodées ou échappées selon le contexte. C’est fait au niveau le plus près de l’interpréteur possible pour éviter l’altération. ❑Cryptographie ▪ Tous les modules cryptographiques échouent de manière sécurisée et les erreurs sont gérées correctement. ▪ Un générateur de nombres aléatoires approprié est utilisé. ▪ L’accès aux clés est géré de manière sécurisée. ❑Gestion des erreurs et audit ▪ Avoir des audits de qualité ▪ Afficher qu’une erreur s’est produite à l’utilisateur, mais ne pas révéler d’informations techniques à l’utilisateur. ▪ Ne pas collecter ou enregistrer d’informations sensibles, sauf si cela est spécifiquement requis.  Contenu du ASVS IV ▪ S’assurer que toutes les informations enregistrées sont traitées en toute sécurité et protégées conformément à leur classification des données. ▪ S’assurer que les journaux ne sont pas stockés pour toujours, mais ont une durée de vie absolue aussi courte que possible ❑Protection des données ▪ Confidentialité : les données doivent être protégées contre l’observation ou la divulgation non autorisée à la fois en transit et lorsqu’il est stocké. ▪ Intégrité : les données doivent être protégées contre toute création, modification ou suppression malveillante par des personnes non autorisées. ▪ Disponibilité : les données doivent être disponibles pour les utilisateurs autorisés selon les besoins.  Contenu du ASVS V ❑Protection des communications ▪ Le TLS ou cryptage fort est toujours utilisé, quelle que soit la sensibilité des données transmises ▪ Les conseils de configuration les plus récents et les plus avancés sont utilisés pour activer et ordonner les algorithmes et chiffrements ▪ Les algorithmes et les chiffrements faibles ou bientôt obsolètes sont commandés en dernier recours ▪ Les algorithmes et les chiffrements non sécurisés obsolètes ou connus sont désactivés. ❑Code malveillant ▪ Les activités malveillantes sont gérées de manière sécurisée et appropriée pour ne pas affecter le reste de l’application. ▪ N’a pas de bombes à retardement ou d’autres attaques basées sur le temps.  Contenu du ASVS VI ▪ Ne "téléphone pas" vers des destinations malveillantes ou non autorisées. ▪ Ne contient pas de portes dérobées, de Easter Eggs, de rootkits ou de code non autorisé pouvant être contrôlé par un attaquant. ❑Logique métier ▪ Le flux de logique métier est séquentiel, traité dans l’ordre et ne peut pas être contourné. ▪ La logique métier inclut des limites pour détecter et empêcher les attaques automatisées, ex: transfert de fonds continus, ajouter un million d’amis un par un, etc.  Contenu du ASVS VII ▪ Les flux de logique métier de grande valeur ont pris en compte les cas d’abus et les acteurs malveillants, et disposent de protections contre l’usurpation d’identité, la falsification, la répudiation, la divulgation d’informations et les attaques par élévation de privilèges. ❑Fichiers et ressources ▪ Les données de fichiers non fiables doivent être traitées en conséquence et de manière sécurisée. ▪ Les données de fichiers non fiables obtenues à partir de sources non fiables sont stockées en dehors de la racine Web et avec un nombre limité de autorisations ❑API et Services web ▪ Authentification adéquate, gestion de session et autorisation de tous les services Web. ▪ Validation d’entrée de tous les paramètres qui passent d’un niveau de confiance inférieur à supérieur.  Contenu du ASVS VIII ▪ Contrôles de sécurité efficaces pour tous les types d’API, y compris le cloud et l’API sans serveur ❑Configuration ▪ Un environnement de déploiement sécurisé, reproductible et automatisable. ▪ Bibliothèque tierce renforcée, gestion des dépendances et de la configuration telle qu’elle est obsolète ou les composants non sécurisés ne sont pas inclus par l’application. ▪ Une configuration sécurisée par défaut, telle que les administrateurs et les utilisateurs doivent sciemment changer la valeur par défaut afin de diminuer la sécurité offerte.  Assurance qualité, tester les requis et + ❑OWAPS publie un guide du testeur qui permet de tester la sécurité du système ❑https://owasp.org/www-project-web-security-testing-guide/stable/ ❑https://owasp.org/www-project-web-security-testing-guide/stable/3- The_OWASP_Testing_Framework/ ❑https://owasp.org/www-project-web-security-testing-guide/stable/6- Appendix/A-Testing_Tools_Resource.html  Le OTG I ❑Durant un développement, plusieurs éléments doivent être mis en place dont un SDLC. Voici un flux typique d’un DLC :  Le OTG II ❑Le OTG vous accompagne dans ces différentes activités : Regroupé par thème : ▪ Information Gathering ▪ Configuration and Deployment Management Testing ▪ Identity Management Testing ▪ Authentication Testing ▪ Authorization Testing ▪ Session Management Testing ▪ Input Validation Testing ▪ Error Handling ▪ Cryptography ▪ Business Logic Testing ▪ Client-side Testing ▪ API Testing  Le OTG III Les catégories vous disent quelque chose ? C’est normal. Le WSTG permet de vous aider à tester votre implantation de l’ASVS.  La revue d’architecture ❑La revue d’architecture se fait au début en révisant les UML ❑Les documents UML nous permettent de voir les flux d’information et de vérifier que les différentes mesures de sécurité sont bien présentes ❑Un DFD provenant d’une modélisation de menace est aussi un bon point de départ pour identifier les contre-mesures à mettre en place.  Principes de conception ❑Les principes de conception viennent du livre de Adkins, 2020 ❑Afin d’avoir un logiciel sécuritaire, plusieurs principes de base doivent être acquis : ▪ Concevoir pour le moindre privilège. ▪ Concevoir pour que ce soit intelligible ▪ Concevoir pour le changement ▪ Concevoir pour la résilience ▪ Concevoir pour la récupération ▪ Mitiger les DDOS  Le moindre privilège ❑Avoir le minimum d’accès pour les tâches à accomplir. Pas plus, pas moins ❑Tout ce qui vient de l’extérieur n’est pas digne de confiance. ❑Automatiser les tâches. ❑Classifier les accès selon le risque : public, sensible, critique ❑Les données critiques, par exemple, ne devraient pas avoir d’accès permanent. ❑En ayant des petits APIs fonctionnels qui n’ont qu’une responsabilité (e.g. des micro services). Cela permet de garder la sécurité le plus granulaire possible. ▪ Par exemple, l’API d’administration pourrait ne pas être exposé à internet. ❑Il faut tester les accès !  Être intelligible I ❑Permettre aux développeurs de comprendre et d’apprécier ▪ Le comportement voulu du système ▪ Les invariants du système soit la sécurité et la disponibilité ❑Diminue les erreurs applicatives ❑Facilite la réponse efficace à un incident ❑Accrois la confiance des affirmations sur le positionnement d’un système par rapport à sa sécurité. ❑Utilisez les principes du code propre ❑Utilisez les couches logicielles ou le regroupement par composants pour les logiciels complexes ❑Adoptez le principe de : la sécurité par défaut ▪ C’est mieux de tout bloquer et ensuite de permettre certaines actions, que le contraire  Les changements ❑Il faut que les changements soient incrémentaux : petit et indépendant. ❑Documenté : Décrire le comment et le pourquoi ❑Testé : Tests unitaires, tests d’intégration, revues de code, etc. ❑Isolé : Éviter les incompatibilités. ❑Qualifié : Il devrait suivre le court normal de la mise en production ❑Mis en scène : Mis en production, de façon graduelle et maîtrisé.  Changements plus faciles ❑Garder les dépendances à jour et régénérer les solutions fréquemment ❑Utiliser les tests automatisés. ❑Utilisez les conteneurs ❑Étudiez la notion et utilisez les micro-services si possible ❑Utilisez différentes planifications selon l’urgence de la modification : ▪ court-terme (vulnérabilité zero-day) ▪ moyen-terme (amélioration) ▪ long terme (demandes clients)  Résilience I ❑Chacune des couches logicielles doivent être indépendamment résilientes ❑Il faut des frontières nettes dans l’architecture logicielle afin de garder chacune des parties les plus indépendantes possibles ❑Utilisez la redondance afin d’éviter les pannes ❑Automatisez les procédures de résilience le plus possible ❑Validez et tester la résilience du système. ❑Contrôlez la dégradation : Tous les systèmes ont la possibilité d’arrêter : ▪ Exemple : si votre base de données ne répond plus, que faites-vous ? ▪ Vous pourriez garder la demande dans un log pour le traiter manuellement par après  Résilience II ❑Vous pourriez appliquer le changement dans un autre nœud d’une bd distribuée ❑Vous pourriez faire d’autres essais plus tard. ❑Vous pourriez annuler la transaction et inviter l’utilisateur à réessayer. ❑Vous pourriez enregistrer un brouillon de ce que l’utilisateur a en mémoire pour que l’utilisateur décide quoi faire avec après.  La récupération I ❑On récupère de... ▪ Erreurs quelconques ▪ Erreurs accidentelles ▪ Erreurs logicielles ▪ Actions malveillantes ❑Avoir une façon de désactiver, de révoquer, bloquer ou de renouveler : ▪ Certificats, connexion, fonctionnalité, versions, rôles et ACL. ❑Les systèmes doivent être flexible sur la vitesse de déploiement. ❑Les systèmes doivent pouvoir revenir à une version antérieure  DDoS I ❑Éliminer le traffic des attaquants le plus tôt possible dans la chaîne de commandes ❑Utiliser les proxies de cache (cache-control) (les résultats sont stockés en cache sur le serveur) ❑Éviter les appels applicatifs inutiles (ex. des appels à chaque page pour aller chercher le descriptif de l’utilisateur) ❑Limiter la taille possible des requêtes ou les quotas ❑Diminuer les fonctionnalités de façon intelligente : Exemple le site peut devenir un site en lecture seule (sans écriture) pendant une charge trop importante. ❑Avoir un système de détection et de réponse ❑Utilisez CAPTCHA  La conception, une étape cruciale I ❑Les décisions d’architecture ont un impact réel sur la robustesse du logiciel ❑On a vu ici des exemples de décision à prendre pour avoir un logiciel robuste et sécuritaire. ❑Ces décisions ne viennent pas de façon naturelle même lorsqu’on utilise un cadriciel. ❑En plus du ASVS il faut voir quel est l’environnement dans lequel le logiciel évolue. ❑Il faut y penser et y réfléchir. Il faut documenter et il faut notamment rechercher et choisir les éléments qui pourront nous aider dans la sécurité de notre logiciel ▪ L’audit, l’authentification, l’autorisation, les filtres, les limites et quotas  Le parcours du code ► Avant de faire une revue de code, il est important de parcourir le code avec les développeurs pour qu’ils présentent l’ensemble de la structure et des décisions de design avec le testeur. ► Ce n’est pas une nécessité mais ça permet de faire une revue plus efficace.  La revue de code I ▪ La revue de code permet d’identifier des bogues qu’il n’est pas possible d’identifier uniquement avec des outils dynamiques. ▪ Aussi, la revue de code permet d’identifier des flots qui ne sont pas accessibles de l’extérieur (lecture de fichier etc.) ou lié au temps (tâche qui s’exécute chaque nuit). ▪ La revue de code permet aussi d’identifier les ORIGINES d’un bogue. Par exemple, une vulnérabilité qui est inclue dans 1000 pages va donner UN bogue via analyse statique et MILLE bogues via analyse dynamique. ❑Il existe plusieurs approches à la revue de code statique, voici un court résumé : ▪ Basé sur des mots clés : ▪ L’outil d’analyse de code cherche des mots clés et informe le développeur que la méthode est dangereuse.  La revue de code II ▪ Certaines fonctions devraient être utilisées avec des mesures ou contrôles de sécurité. ▪ Ex. : eval, system, exec, strcmp ❑Instrumentation dynamique (Revue de code dynamique aussi) ▪ En langage interprété : il est possible d’évaluer le code pendant l’exécution, en modifiant l’interpréteur ▪ Permets d’identifier les branches de code, les conditions et certaines vulnérabilités. ❑“Taint Based Analysis” ▪ L’analyse via Taint Analysis consiste à analyser l’ensemble du code, d’identifier l’ensemble des flux d’informations. ▪ Pour chaque information, modifier l’information pour voir les répercussions sur les classes subséquentes. ▪ Permets d’essayer L’ENSEMBLE des flux du code.  La revue de code III ❑Fuzzing (Revue de code dynamique aussi) ▪ Permets de tester un logiciel en envoyant différentes entrées et en analysant le comportement à la sortie.  Avantages/Inconvénients I Avantages Inconvénients mots Très rapide. Peu Peu de vrais positifs; clés de faux positif. Portée très limitée ; Nécéssite de l’analyse manuelle à chaque fois  Avantages/Inconvénients II Inst. Beaucoup plus de Uniquement les flux dyna- compréhension des VISITÉS sont évalués. mique flux de données. Nécéssite une Peu de faux positif instrumentation ET un hébergement de serveur etc. Plusieurs vrais positifs inexploitables. Uniquement pour les langages interprétés.  Avantages/Inconvénients III Taint Très peu de faux Requiers de recompiler Based positif dans les l’application dans un Ana- sections analysées language intermédiaire. lysis Analyse l’ensemble Ne peut PAS inspecter des faux positifs. les librairies importées. Permets d’identifier Vrais positifs sans les “vulnérabilités” impacts. Couteux inexploitables  Avantages/Inconvénients IV Fuzzing Assez simple à Identifie toute sorte de automatiser. bogue, pas uniquement Permets de tester la sécurité. Le fuzzing est chaîne complète aussi bon que le fuzzer. (serveur, N’identifie pas l’endroit application, dans le code où le middleware). problème se trouve. (Ne Permets dis pas à quelle ligne, d’identifier des dans quel fichier) bogues qu’on ne peut identifier autrement  Le développement piloté par les tests I ❑Le développement piloté par les tests est une méthode de développement qui permet de faire des incréments beaucoup plus facilement ❑permet, entre autres : ▪ Focus sur la fonctionnalité à développer. ▪ Éviter des effets de bord ▪ Maîtriser les évolutions logicielles ▪ Documenter l’utilisation du code. ▪ Livrer une nouvelle version d’un logiciel avec un haut niveau de confiance ❑Le développement piloté par les tests permet d’être le plus proche des demandes clients et de diminuer les modifications qui n’ont pas rapport au cas étudié. ❑Le principe est simple : on écrit le test de départ qui représente une fonctionnalité AVANT de le coder :  Le développement piloté par les tests II ▪ Ex. En tant qu’utilisateur je veux pouvoir ajouter un commentaire sous un article. ▪ Prepare : ▪ Je crée un commentaire avec les données suivantes : ▪ Id : 0, Auteur:User1, Texte:LoremIpsum, Article:Article1 ▪ J’initialise mon service de données ▪ var service = new CommentService(bd) ▪ Act : ▪ Je crée un commentaire avec mon service web : ▪ var res ult = awa it ser vice.P ost(co mment) ▪ Assert : ▪ Je vérifie qu’il a été créé (le id n’est plus à 0) : ▪ Ass ert.No tEqual s(re sult.i d,0) ; ❑En premier lieu, le test ne fonctionnera pas. C’est normal, on n'a pas encore écrit le code. ❑On écrit le moins de code possible pour que ce test passe au vert : On ajoute la fonction dans l’interface, dans le service, on l’associe à notre ORM, on ajoute les permissions requises. Ça fonctionne, c’est bon.  Le développement piloté par les tests III ❑Mais est-ce fini ? Et bien non, avec des requis de sécurité on aurait d’autres tests : ▪ ex. Le test pour valider que la validation des paramètres est bien effectuée. ▪ ex. Le test pour valider que l’encodage lorsqu’on affiche le commentaire est bien effectué. ▪ etc. ❑On écrit le test, on ajoute le code, on roule l’ensemble des tests pour vérifier qu’il n’y a pas de régression, on passe au test suivant.  Les types de validation I Lorsqu’il faut développer, il peut arriver qu’on ait à faire des choix. Voici un petit tableau des avantages/inconvénients de chacune des approches Type de Pour Contre valida- tion Checklist Permets d’assurer la Très dispendieux et (comme traçabilité d’une difficile à faire pour ASVS) menace les cas “généraux”  Les types de validation II TDD Permets de suivre Plusieurs menaces sont l’évolution et tôt dans le difficile à mettre en cas cycle de vie de tests et difficile à faire pour les cas “généraux” Permets d’identifier Dispendieux, très tard Test des menaces qui dans le cycle de d’intru- n’étaient pas déjà développement sion identifiées Tôt dans le cycle de Trop tôt pour tout Revue développement. Permets attraper. Parfois d’archi- d’identifier les problèmes coûteux lorsqu’un tecture majeurs rapidement projet recommence  Les types de validation III Revue de Très précis, fiable et Très dispendieux, très code on peut le faire tôt longs et présence de dans le cycle de vie. faux positifs. Tests Peu dispendieux Tard dans le cycle de automa- vie. Peut amener des tisés faux positifs. Surtout lors d’un refactoring.