CR440 – Sécurité Applicative Cours 1 PDF 2024

CR440 – Sécurité applicative Automne 2024 – Cours 1 20 24-08-30  Sommaire ❑Préambule ▪ Présentation du chargé de cours ▪ Le plan de cours ▪ Critères d’évaluation ❑Introduction à la cybersécurité applicati...

CR440 – Sécurité applicative Automne 2024 – Cours 1 20 24-08-30  Sommaire ❑Préambule ▪ Présentation du chargé de cours ▪ Le plan de cours ▪ Critères d’évaluation ❑Introduction à la cybersécurité applicative ▪ Vulnérabilités célèbres ▪ Erreurs applicatives, pourquoi ça arrive ? ▪ Les exigences ▪ Concepts de base ▪ Vecteurs d’attaque, vulnérabilité et impact ❑Menaces ▪ L’objectif CID ▪ Les types de menaces ▪ Les contres-mesures ▪ Trouver et modéliser les menaces potentielles ▪ Comparaison des autres méthodes 2 20 24-08-30  Sani Chabi Yo ❑Expérience professionnelle de 18 ans en technologie: ▪ Innovation & Emerging Tech ▪ Cybersécurité ▪ Architecture d’entreprise ▪ Prévente ▪ Développent logiciel ❑Bac en Génie logiciel et Maitrise en Ingénierie ❑Chargé de cours du CR440 depuis Hiver 2024 ❑Chargé de cours du CF100 en 2023 3 20 24-08-30  Photo 4 20 24-08-30  Comment me rejoindre Courriel ❑En indiquant le sigle du cours, [email protected] Linkedin ❑linkedin.com/in/sani-chabi-yo-m-eng-cissp-b589813 Sur Teams ❑Sur le MS Teams de la polytechnique 5 20 24-08-30  Quelques explications Travaux Les devoirs et travaux sont remis via le site Moodle du cours. Aucun document imprimé ne sera accepté. Le travail remis doit répondre aux exigences énoncées dans l’énoncé du travail à faire Environnement Vous devez avoir accès à une machine Windows. 6 20 24-08-30  Sommaire ❑Préambule ▪ Présentation du chargé de cours ▪ Le plan de cours ▪ Critères d’évaluation ❑Introduction à la cybersécurité applicative ▪ Vulnérabilités célèbres ▪ Erreurs applicatives, pourquoi ça arrive ? ▪ Les exigences ▪ Concepts de base ▪ Vecteurs d’attaque, vulnérabilité et impact ❑Menaces ▪ L’objectif CID ▪ Les types de menaces ▪ Les contres-mesures ▪ Trouver et modéliser les menaces potentielles ▪ Comparaison des autres méthodes 7 20 24-08-30  Vulnérabilités célèbres - EternalBlue 1. Utilisé de façon régulière par la NSA jusqu’en 2017 2. Rendu public en 2017 3. Utilise une faille de sécurité présente dans le protocole SMB (partage de fichiers) 4. La vulnérabilité a été utilisée par WannaCry pour se propager, un rançongiciel 5. Permets l’exécution du code à distance 6. Voici la notice de Microsoft ❑ La mise à jour de sécurité corrige les vulnérabilités en modifiant la manière dont SMBv1 traite les requêtes spécialement conçues. 8 20 24-08-30  Vulnérabilités célèbres - ShellShock I 1. Une vulnérabilité qui impacterait Windows, Linux, Mac OS X, découvert en 2014 2. Elle autorise un attaquant à prendre contrôle d’une machine 3. Cette vulnérabilité affecte le programme de ligne de commande. 4. Beaucoup de Dénis de service ont été observés à cause de cette vulnérabilité et de la lenteur desmises à jour. L’impact a été énorme. 5. Le CVE-2014-6271 a amené la découverte d’autres vulnérabilités. 6. C’est ainsi que du premier signalement, CVE-2014-6277, CVE-2014- 6278, CVE-2014-7169, CVE-2014-7186 et CVE-2014-7187 ont par la suite été découverts. 9 20 24-08-30  Vulnérabilités célèbres - ShellShock II 7. Bash a été écrit initialement en 1989. 8. On peut essayer cette vulnérabilité avec Metasploit2 10 20 24-08-30  Vulnérabilités célèbres - Heartbleed 1. Découvert en 2012 2. Permets la lecture de portion de mémoire du serveur qui devrait être protégé. 3. Une mauvaise implémentation du protocole TLS. 4. Introduite par erreur après un correctif. 5. Les mobiles sous Android 4.1.1 sont toujours vulnérables. 6. Vous pouvez aller voir plus d’information sur https://heartbleed.com/ 11 20 24-08-30  Vulnérabilités célèbres - Poodle 1. Padding Oracle on Downgraded Legacy Encryption 2. Permets de déchiffrer les informations transmises via SSL 3.0 3. Vulnérables aux attaques MITM 1 4. On doit maintenant utiliser TLS. 1. Men in the middle 12 20 24-08-30  Vulnérabilités célèbres - Dirty COW 1. Vulnérabilité du noyau linux 2. Permets une élévation des privilèges 3. Notamment avoir accès en écriture un fichier normalement en lecture seule. 4. La gestion incorrecte d’une fonctionnalité de gestion de mémoire est à l’origine du problème. 13 20 24-08-30  Vulnérabilités célèbres - Meltdown 1. Les processeurs intel impactés (la majorité des processeurs intel entre 1995 et 2018) 2. Vulnérabilité matérielle 3. Avoir un accès privilégié à la mémoire par un processus non autorisé 4. CVE-2017-5754 14 20 24-08-30  Vulnérabilités célèbres – Therac-25 1. Entre 1985 et 1987, Therac-25, une machine de radiothérapie manquait de contrôles appropriés au niveau des niveaux de flux d’électrons. En effet, une erreur applicative a fortement irradié de nombreux patients. Therac-25 a été associé à plus de 5 accidents. 2. La faute réside dans le fait que la compagnie a réutilisé du code d’un ancien modèle qui avait des contrôles matériels. 3. Therac-25 en était malheureusement dépourvu ! Il aurait fallu qu’ils mettent ces contrôles dans leurs implantations du logiciel de contrôle. 4. Un oubli dramatique. 15 20 24-08-30  Erreur applicative ❑Une erreur applicative est un dysfonctionnement d’une application. ▪ On s’attend à un résultat, mais ça n’arrive pas. ❑Une erreur applicative arrive via des exceptions, des erreurs système ou des erreurs de logique. ❑Une erreur applicative arrive dans un logiciel qui n’a pas une gestion des erreurs adéquates ❑Une erreur applicative arrive si l’implantation d’une exigence possède une logique erronée. ❑Une erreur applicative arrive si les dépendances ne sont pas bien gérées ❑Une erreur application arrive si les exigences n’ont pas été bien définies notamment les exigences de sécurité ❑Une erreur applicative peut représenter une faille de sécurité. 16 20 24-08-30  Les exigences ❑Une exigence c’est une nécessité qui permet de savoir si oui ou non on accepte un développement comme terminé. ❑Selon l’IEEE, les exigences doivent répondre à certains critères. ▪ Nécessaire : Sans l’exigence, il y aurait un problème avec le projet. ▪ Non ambiguë : On sait de quoi vous parler. ▪ Concise : Communique l’essence de ce qui est exigé. ▪ Cohérente : Évite les contradictions ▪ Complète : Pas d’annexe pour les exigences ! ▪ Précise : Avoir une mesure lorsque nécessaire (ça facilite les tests !) ▪ Vérifiable : On peut savoir si c’est atteint ou non... 17 20 24-08-30  Les exigences de la sécurité I ❑Lors d’un développement logiciel, nous avons différentes exigences de sécurité. ❑On les spécifie souvent en termes de Assurance Le système se comporte comme attendu (jugé conforme à la spécification) Identification/Authentification Les parties communicantes doivent s’identifier entre eux. Il faut que chacun sache avec qui il communique. Responsabilité/Audit La capacité de savoir qui a fait quoi, quand et où. Contrôle d’accès L’accès à des ressources spécifiques peut être limité à certaines entités ou certains rôles. 18 20 24-08-30  Les exigences de la sécurité II Réutilisation d’objet Les objets employés par un processus ne peuvent pas être réutilisés par un autre processus. Exactitude Les objets sont exacts et complets. Échange de données sécurisé Confidentialité, intégrité, authentification, non répudiation Fiabilité de service Les données et les services essentiels sont disponibles quand nécessaires Nous verrons au cours 5 une liste de spécifications déjà monté pour nous quant aux exigences de sécurité. 19 20 24-08-30  La sécurité applicative Définition La sécurité applicative est la science qui permet d’établir les requis de sécurité d’une application, d’évaluer l’efficacité des contrôles en place, d’identifier les défaillances applicatives et d’intégrer la sécurité dans le cycle de vie d’une application. 20 20 24-08-30  Être un développeur informé ❑Connaître la valeur des informations et des processus ❑Faire ou obtenir l’inventaire des vulnérabilités et des menaces ❑Juger les impacts des menaces ❑Analyser les risques sur l’environnement actuel ❑Mettre en œuvre un ensemble approprié de contre-mesures. ❑Connaître les risques et la politique de sécurité de l’entreprise. ❑Être simple : si la sécurité est compliquée, elle sera probablement inefficace et coûteuse ❑Être logique : il est préférable d’avoir un niveau minimal dans l’ensemble des systèmes que d’avoir des systèmes fortement protégés et d’autres largement ouverts ❑Respecter les standards si possible : facilitent le choix, facilite l’évaluation des systèmes 21 20 24-08-30  Coût de la sécurité I ❑Le coût d’une vulnérabilité explose selon le moment où il est trouvé : C’est exponentiel. ❑Ce graphique (aucunement scientifique) illustre ce phénomène. 22 20 24-08-30  Coût de la sécurité II Il est donc important de prendre en charge la sécurité tout au long du cycle de développement d’un produit. 23 20 24-08-30  Se préparer ❑Chaque entreprise doit définir les solutions à adopter en fonction ▪ des éléments à protéger, et contre qui. ▪ de la valeur de ces éléments ou de leurs reconstructions ▪ de la probabilité d’occurrence ▪ de la perte potentielle ▪ des coûts de protection ou de non-protection associés. 24 20 24-08-30  Des règles du gros bon sens I ❑Les contrôles doivent toujours être faits du côté serveur et ils doivent être implantés. ▪ Les contrôles au niveau client servent seulement à éviter des appels et ne font pas office de sécurité. ❑La sécurité par l’obscurité n’est pas de la sécurité. ❑Ne jamais faire confiance aux données extérieures (entrées par un client, entrées par un autre système, etc.) ❑Gérez l’ensemble des exceptions ❑La technologie n’est pas la panacée : La solution n’est pas toujours technologique. ❑Même si vous avez une sécurité solide, si votre mot de passe est faible, votre sécurité devient faible. : Utilisez des mots de passe complexe 25 20 24-08-30  Des règles du gros bon sens II ❑Un système est sécuritaire que si son administrateur est de confiance ❑Une donnée cryptée ne peut être plus sécuritaire que la complexité de sa clé de décryptage. Évitez les Test123Test123.... 26 20 24-08-30  Vecteur d’attaque ❑Le vecteur d’attaque est le moyen par lequel un pirate réussi à accéder à votre ordinateur ou serveur dans un but malveillant. ❑Le courriel contenant une pièce jointe pourrait par exemple être un vecteur d’attaque. ❑Dans la typologie des vecteurs, on en rencontre 4 principaux : ▪ réseaux : les failles dans une configuration réseau, ▪ logiciels : les failles logicielles ▪ humains : Attaque consistant à exploiter et manipuler un individu. ▪ physique : équipements physiques permettant une attaque informatique. 27 20 24-08-30  Vulnérabilité ❑Une vulnérabilité est une faiblesse qui peut servir de cible facile face aux attaques ennemies (ici nos amis les pirates) ❑Chacune des vulnérabilités logicielles publiées est référencée dans le CVE maintenu par l’organisme MITRE. ❑Le CVE est un dictionnaire des informations publiques relatives aux vulnérabilités de sécurité. ❑Le CVE contient un identifiant de ce format : CVE-ANNEE- CODE_UNIQUE. ❑Le CVE-2014-6271 en est un exemple. ❑Si on consulte le dictionnaire, on obtient le nom et un descriptif de la problématique. ❑Les CVE sont référencés ici : https://cve.mitre.org/index.html ❑Un autre site intéressant est celui-ci : https://www.cvedetails.com/ 28 20 24-08-30  Impact ❑L’impact de l’exploitation d’une vulnérabilité peut devenir extrêmement grave et coûteux. ▪ La survie de la compagnie même peut être mise en cause. ▪ L’impact permet de trouver la sévérité d’une vulnérabilité. ▪ L’impact peut être monétaire ou en temps. Qualitatif ou quantitatif. ▪ On connaît l’impact en connaissant l’enjeu et la valeur des données qui peuvent être subtilisées. ▪ Associé au CVE, on a un CVSS, une cote de sévérité qui tient en compte le vecteur d’attaque, la probabilité et l’impact pour faire sa cote. ▪ Ces normes utilisent des échelles linéaires de "aucun impact" à "beaucoup d’impacts" ▪ On verra le CVSS plus tard dans la session. 29 20 24-08-30  Sommaire ❑Préambule ▪ Présentation du chargé de cours ▪ Le plan de cours ▪ Critères d’évaluation ❑Introduction à la cybersécurité applicative ▪ Vulnérabilités célèbres ▪ Erreurs applicatives, pourquoi ça arrive ? ▪ Les exigences ▪ Concepts de base ▪ Vecteurs d’attaque, vulnérabilité et impact ❑Menaces ▪ L’objectif CID ▪ Les types de menaces ▪ Les contres-mesures ▪ Trouver et modéliser les menaces potentielles ▪ Comparaison des autres méthodes 30 20 24-08-30  Les objectifs C.I.D. En sécurité, nous avons de grands objectifs de base pour nos applications. Les menaces viennent atteindre l’un ou l’autre de ces objectifs de base. 31 20 24-08-30  Les types de menaces I Les menaces viennent mettre des bâtons dans les roues dans l’atteinte des objectifs C.I.D. Objectifs Type de Définition menaces Confidentialité Divulgation L’information est divulguée à des d’informa- personnes non autorisées Intégrité Altération Altérer ou modifier une des données donnée, le code Disponibilité Deni de service Rendre indisponible ou diminuer la qualité de performance d’un service 32 20 24-08-30  Les types de menaces II Authentification Usurpation Se faire passer pour d’identité quelqu’un d’autre Autorisation Élévation Obtenir des privilèges sans des autorisation privilèges Non- Répudiation Prétendre ne pas avoir fait répudiation une action 33 20 24-08-30  Les contre-mesures ou mitigation I Pour chacun des types de menaces, on peut mettre des mesures afin d’atténuer la menace. Voici des exemples : Objectifs Type de Mitigation menaces Confidentialité Divulgation Encryption, liste de contrôle d’informa- d’accès (ACL), etc. tions Intégrité Altération Le Mandatory Integrity des données Control (MIC) de Microsoft, liste decontrôle d’accès (ACL), signatures digitales, etc. 34 20 24-08-30  Les contre-mesures ou mitigation I Disponibilité Deni de liste de contrôle d’accès services (ACL), Filtres, Quotas (limites), etc. Authentification Usurpation Authentifier le client : cookie, d’identité kerberos, systèmes PKI (SSL/TLS), signatures digitales, etc. Autorisation Élévation liste decontrôle d’accès (ACL), des Utilisation des rôles ou groupes, privilèges validations desentrées, propriétaire des privilèges, etc. Non- Répudiation Un logging sécuritaire, répudiation signatures digitales, etc. 35 20 24-08-30  Pourquoi modéliser ? Dans un cahier de charge, on peut trouver... Sécurité : La solution de paiement doit être sécuritaire, c’est à dire protéger l’utilisateur, l’application ainsi que les serveurs associés. Performance : L’application doit avoir un temps de chargement en deçà de 500 ms. L’application doit répondre en moins de 250 ms. 36 20 24-08-30  Le problème Il existe plusieurs exigences fonctionnelles faciles à décrire : 1. Temps de réponse 2. Nombre d’usagers concurrents 3. Nombre de fichiers traités/heure 4. Volume de téléchargement. Mais comment quantifier et décrire la sécurité? 37 20 24-08-30  Microsoft Depuis 2003, Microsoft a démarré le « Trusted Computing Initiative », un projet visant à augmenter la sécurité de ses projets. Depuis ce temps, Microsoft est un chef de file en matière d’innovation en matière de développement sécuritaire. Un des aspects importants est le SDL, c’est à dire le Secure Development LifeCycle. Dans ce cycle, la modélisation des menaces est l’une des premières étapes d’architecture de sécurité. 38 20 24-08-30  Référence du domaine La référence sur la modélisation de menaces est “Threat Modeling” par Adam Shostack. Cependant, pour vous éviter une dépense, OWASP, une organisation sans but lucratif en sécurité, a produit un excellent guide disponible ici. 39 20 24-08-30  Qu’est-ce que la modélisation de menaces ? La modélisation de menace est un processus qui consiste à évaluer les failles susceptibles d’affecter une application, ou son environnement. ❑ En identifiant les failles potentielles d’une application, il est possible d’en découler des requis de sécurité, ainsi que des éléments de validation en assurance qualité. 40 20 24-08-30  Pourquoi utiliser la modélisation de menaces ? Plus les failles sont découvertes tôt, moins elles sont coûteuses à corriger. ❑Selon le NIST, une faille découverte au moment de l’architecture coûte 30 fois moins à corriger que si cette faille est découverte une fois le produit livré. https://www.nist.gov/system/files/documents/director/pla nning/report02-3.pdf 41 20 24-08-30  Le processus de modélisation 42 20 24-08-30  Autres méthodes I ❑Il est certain qu’il y a d’autres méthodes que le SDL de Microsoft qui amène une modélisation de menace. La modélisation de menaces est une activité qui fait partie intégrante de plusieurs cadres de travail. La grande différence dans les méthodes est la perspective utilisée. Nous avons : ▪ PASTA (Process for Attack Simulation and Threat Analysis) : centrée sur l’attaquant et les actifs ▪ OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) : centré sur l’attaquant et les actifs ▪ TRIKE (n’est plus mis à jour) : centrée sur les actifs ▪ LINDDUN : centré sur les risques ▪ VAST (Visual, Agile, and Simple Threat modeling methodology) : Centré sur l’infrastructure 43 20 24-08-30  Autres méthodes II ❑Puisqu’on doit en choisir une, on a choisi celle de Microsoft qui est beaucoup utilisée dans le domaine. La modélisation de menaces nous permet d’identifier les menaces possibles pour notre application. On utilise une classification pour nous aider. Cette classification s’appelle STRIDE. On verra dans les prochaines diapositives pourquoi. Cette modélisation est centrée sur l’application. C’est aussi l’une des plus intuitives. ❑Si vous voulez en apprendre plus sur les autres méthodes, je vous invite à aller voir l’excellent article de geeksforgeeks : https://www.geeksforgeeks.org/threat- modelling/ 44 20 24-08-30  Prochain cours... La modélisation de la menace! 45 20 24-08-30  CR440 – Sécurité applicative Automne 2024 – Cours 2 1 20 24-09-06  Sommaire ❑Considérations ▪ Gestion des risques ❑Faire la modélisation ▪ Modélisations : les vraies questions ▪ Méthodologie STRIDE ▪ Modéliser avec un DFD ▪ Définir la liste des menaces ▪ Prioriser la liste des menaces ▪ Valider l’efficacité des mesures ▪ STRIDE en exemple... ❑Modélisation en pratique 2 20 24-09-06  Évaluation des risques : Attaque ❑Selon Adkins, 2020. ▪ Vous ne réalisez peut-être pas que vous êtes la cible ▪ L’attaque complexe n’est pas nécessairement celle que votre attaquant va utiliser ▪ Il ne faut, cependant, surtout pas sous-estimer vos adversaires ▪ L’attribution d’une attaque est difficile ▪ Les attaquants n’ont pas toujours peur d’être découverts 3 20 24-09-06  Évaluation des risques : Profil ❑Les attaquants peuvent avoir de multiples profils. ▪ Amateur ▪ Chercheurs ▪ Gouvernements : Agence de renseignements, agences militaires, police locale, etc. ▪ Activistes ▪ Criminels ▪ Intelligence artificielle ou des procédés automatiques ▪ Personnel interne : employés, stagiaires, directeurs, contracteurs, vendeurs, amis, familles, colocataires, etc. 4 20 24-09-06  Évaluation des risques : Motivation ❑La motivation d’une attaque peut être variée : ▪ Ça peut être un accident tout bête ▪ Ça peut être une négligence d’une personne ▪ Ça peut venir d’une personne qui veut compromettre une entreprise ▪ Ça peut venir d’une personne qui a des objectifs pécuniaires ▪ Ça peut venir d’une personne qui attaque par idéologie ▪ Ça peut venir d’une personne qui veut se venger ou riposter ▪ Ça peut être tout simplement par vanité 5 20 24-09-06  Les attaquants utilisent les vulnérabilités ❑Afin qu’une attaque ait lieu, il faut une faille dans le système. ❑Cette faille peut être inconnu des personnes qui ont créé le système. ❑Habituellement, les failles sont inconnus soit par manque de perspective, d’audit, d’expérience ou de considération des risques. ❑Modéliser les vulnérabilités permet d’identifier les failles possibles du système lorsqu’il communique avec d’autres systèmes. ❑Les DFD ou les diagrammes de flux de données permettent l’identification des portes d’entrées et de sorties des données. 6 20 24-09-06  Faire une liste de vulnérabilités ❑La liste des vulnérabilités vous permettra d’agir : ▪ Mitiger la menace ▪ Éliminer la menace ▪ Transférer la menace ▪ Accepter la menace ▪ Jamais l’ignorer ! ! ! 7 20 24-09-06  Sommaire ❑Considérations ▪ Gestion des risques ❑Faire la modélisation ▪ Modélisations : les vraies questions ▪ Méthodologie STRIDE ▪ Modéliser avec un DFD ▪ Définir la liste des menaces ▪ Prioriser la liste des menaces ▪ Valider l’efficacité des mesures ▪ STRIDE en exemple... ❑Modélisation en pratique 8 20 24-09-06  Les questions à ce poser. 1. Qu’est-ce que vous construisez ? 2. Qu’est-ce qui peut mal fonctionner ? 3. Que devez-vous faire avec ce qui peut mal fonctionner ? 4. Est-ce que l’analyse est suffisante ? 9 20 24-09-06  Connaître les processus : Exemple un site web I ❑Si on prend un site web, on va avoir un navigateur qui fait des appels à un serveur web et qui communique avec un SQL. ❑On pourrait les présenter avec des blocs et des liens entre ces blocs : 10 20 24-09-06  Connaître les processus : Exemple un site web II ❑C’est ce qu’on construit ! ❑Bien, maintenant qu’on a les blocs, on se demande... Qu’est-ce qui peut mal fonctionner ? ▪ Qu’est-ce qui arriverait si la personne qui utilise le navigateur n’est pas celle prétendue ? ▪ Qu’est-ce qui arriverait si les données qui passent de la base de données au serveur sont altérées ? ▪ Qu’est-ce qui arriverait si la requête qui part du serveur web à la base de données est altérée ? ❑Est-ce qu’on a bien analysé cependant ? ▪ Chacun des processus pourrait être sur des processus séparés, par exemple, entre le navigateur et le serveur web, il y a l’internet, et entre le serveur web et le SQL, il y a le réseau interne. ▪ Puis on se demande, si on met la base de données sur un serveur externe qu’est-ce qui arriverait à mon diagramme ? 11 20 24-09-06  Connaître les processus : Exemple un site web II ▪ On se demande, où sont mes fichiers de configuration, comment mon application va journaliser les évènements, etc. ❑Le diagramme évolue : 12 20 24-09-06  Méthodologie STRI DE I ❑La méthodologie de Microsoft est appelée STRIDE par abus de langage. En effet, STRIDE représente les initiales des types de menaces qu’on a vues au précédent cours. ❑C’est une aide pour aider à identifier les vulnérabilités. Pour chacun des éléments du diagramme, on peut se demander : ▪ Est-ce qu’on peut usurper l’identité du serveur ? ▪ Est-ce qu’on peut altérer les données de la base de données ? ▪ etc. 13 20 24-09-06  Méthodologie STRIDE II En anglais En français S Spoofing Usurpation d’identité T Tempering Altération des données R Repudiation Répudiation I Information disclosure Divulgation d’informations D Denial of service Deni de services E Elevation of privilege Élévation des privilèges 14 20 24-09-06  Étapes pour modéliser I ❑C’est de la modélisation, donc prenez de quoi noter. ❑Faire un survol global du projet ▪ Les données stockées ▪ Les processus ▪ Les flux de données ▪ Les acteurs externes ▪ Les frontières ❑Faire un DFD 2 ❑Faire des scénarios, des suppositions, des hypothèses ❑Trouver les menaces potentielles en utilisant STRIDE ❑Prioriser ces menaces ❑Apporter des mesures de mitigation face à ces menaces ❑Vérifier le tout ❑Communiquer ces mesures à vos équipes 2. un data flow diagram ou un diagramme des flux de donnée 15 20 24-09-06  Faire un DFD I ❑Le DFD est composé de plusieurs éléments que voici : ▪ Process : Le processus est tout processus applicatif unique. Une solution pourrait avoir par exemple un serveur web, un service de messagerie, un service de log. ▪ Store : Un stockage de données que ce soit des fichiers, une base de données, un registre, une mémoire partagée, une liste d’attente ▪ Actor : Les éléments externes à notre solution. Souvent les utilisateurs ou systèmes externes (exemple l’API de google maps) 16 20 24-09-06  Faire un DFD II ❑Le DFD est composé de plusieurs éléments que voici : ▪ Data Flow : Un flux de données. C’est une transmission de donnée d’un élément à un autre. ▪ Trust Boundary : Les frontières de confiance. Que ce soit d’un processus à un autre ou d’une machine à un autre. 17 20 24-09-06  La liste des menaces Éléments Menaces possibles Process S,T,R,I,D,E Store T,R,I,D Actor S,R Data Flow T,I,D 18 20 24-09-06  Identifier les menaces ❑Commencer par les entités externes. ❑Ayez un focus sur les menaces faisables ❑N’ignorez aucune menace ❑Pour chacun des éléments du diagramme, faites le tour des menaces que vous trouvez : S.T.R.I.D.E. 19 20 24-09-06  Priorisation ❑Pour prioriser les menaces, il faut se poser les questions suivantes : ▪ Qu’est-ce qui ferait le plus de dommage ? ▪ Est-ce que c’est probable d’arriver ? ▪ Ceux qui ont une grande probabilité et un plus grand impact devraient être adressés en premier. 20 20 24-09-06  Petit outil : D.R.E.A.D. ❑On peut prioriser en se demandant sur une échelle de 1 à 10, comment la vulnérabilité se comporte : ▪ Dommage potentiel ▪ Reproductibilité ▪ Exploitabilité ▪ Affecte quels/combien d’utilisateurs ▪ Découverte facile ❑Le résultat c’est la moyenne des côtes. 21 20 24-09-06  Valider l’ensemble ❑Pour valider : ▪ Les menaces décrivent : ▪ Rigoureusement l’attaque ▪ Le contexte ▪ L’impact ▪ La mitigation ▪ Cible la menace réelle ▪ Décrit la mesure de mitigation 22 20 24-09-06  STRIDE en exemple... Un fichier... ❑Spoofing : Créer un fichier dans un dossier local : ex. un petit script qui envoie du spam sur un serveur apache. ❑Tempering : Modifier un fichier que vous utilisez ou que vous possédez : Exemple le logo de la compagnie, un xml qui contient la configuration, etc. ❑Repudiation : Modifier les métadonnées du fichier pour cacher qui a modifié ou créé le fichier. ❑Information Disclosure : Contourner le ACL pour voir le fichier. Le charger avec les en-têtes XML ❑Denial of Service : Rendre illisible un fichier (ex. un fichier de configuration) ❑Elevation of Privilege : ? ? 23 20 24-09-06  STRIDE en exemple... Un processus... ❑Spoofing : Renommer un processus ❑Tempering : Faire de l’injection de code ❑Repudiation : Utiliser un compte d’une autre personne ❑Information Disclosure : Trouver des secrets dans des messages d’erreurs ❑Denial of Service : Utiliser la mémoire/processus/espaces disques/amplifier la demande artificiellement. Faire planter le programme complètement avec une erreur (ex. chaîne EICAR sur un QR Code) ❑Elevation of Privilege : Envoi d’une entrée qu’un processus ne valide pas correctement. 24 20 24-09-06  Sommaire ❑Considérations ▪ Gestion des risques ❑Faire la modélisation ▪ Modélisations : les vraies questions ▪ Méthodologie STRIDE ▪ Modéliser avec un DFD ▪ Définir la liste des menaces ▪ Prioriser la liste des menaces ▪ Valider l’efficacité des mesures ▪ STRIDE en exemple... ❑Modélisation en pratique 25 20 24-09-06  Essayons avec un exemple ❑Pour l’exemple nous utiliserons Microsoft Threat Modeling Tool ❑Il est disponible ici : https://www.microsoft.com/en- us/securityengineering/sdl/threatmodeling ❑Voici la fonctionnalité «Création d’usager» de CourrielPro : 1. L’usager visite le site web courrielpro.poly 2. L’usager entre ses informations et mots de passe sur le système. 3. Le système notifie via un courriel à l’administrateur. 4. L’administrateur se connecte au système et s’authentifie. 5. L’administrateur approuve le compte 6. Le système envoie un courriel à l’usager, avec un lien unique qui active le compte. 7. L’usager visite le lien et active son compte 8. L’usager se connecte au système 26 20 24-09-06  Essayons avec un exemple ❑Faisons le démo ensemble... 27 20 24-09-06  Le diagramme 28 20 24-09-06  Devoir 1 ❑L’énoncé est sur Moodle ❑25%, remise le 27 Septembre 2024 29 20 24-09-06  CR440 – Sécurité applicative Automne 2024 – Cours 3 1 20 24-09-14  ❑OWASP ▪ Qui est OWASP ? ▪ Le projet OWASP TOP 10 ❑OWASP TOP 10 2021, 5 premiers ▪ A1 Contrôles d’accès défaillants ▪ A2 Défaillances cryptographiques ▪ A3 Injection ▪ A4 Conception non sécuritaire ▪ A5 Mauvaise configuration de sécurité 2 20 24-09-14  OWASP ❑OWASP veut dire Open Web Application Security Project. C’est une communauté en ligne qui a pour but de donner des éléments, informations et solutions, aux développeurs pour prendre des décisions en matière de sécurisation de leurs applications Web. ❑OWASP c’est un ensemble de projets qui se focus sur un thème : la cybersécurité. ❑Il compte 262 projets à l’heure actuelle : des outils, de la documentation, du code et... des podcasts 3 20 24-09-14  Le projet TOP 10 ❑OWASP maintient une liste des 10 vulnérabilités (ou risques) : les plus sévères et communes qu’on retrouve au niveau applicatif. ❑Afin de faire cette liste, OWASP utilise les statistiques disponibles et sonde les professionnels pour faire cette sélection. ❑La nouvelle mouture du projet TOP 10 est disponible depuis fin 2021 : https://www.owasptopten.org/ ❑L’ancienne version que vous retrouverez peut-être dans l’industrie est celle de 2017. Vous pouvez aller voir le détail de cette ancienne version dans ce guide : https://owasp.org/www-project-top-ten/2017/ ❑D’autre projets peuvent être complémentaire à celui-ci dont le API Security Top 10 , le Mobile Top 10 et le Top 10 Proactive Controls ❑Pour rappel, une vulnérabilité est toute faiblesse qui permet à un acteur malveillant de causer des dommages et des pertes aux parties prenantes d’une application 4 20 24-09-14  Les CWE ❑Sous chacun des risques déterminés par le OWASP TOP 10, nous avons une série de CWE. ❑Le CWE est une bibliothèque de vulnérabilités observés dans les applications. Une banque de connaissances. ❑Chacun des TOP10 contiennent une dizaine voir trente de ces CWE qui sont associés à la catégorie. ❑Il peut être intéressant d’aller voir le détail car il explique un aspect du risque présenté. ❑Si on prend le Path Transversal par exemple nous avons le CWE- 22,23 et 35 qui en parlent pour 3 aspects différents de la même problématique. ❑Vous pouvez allez le voir directement sur le site https://cwe.mitre.org/data/definitions/22.html ❑Vous pouvez aussi aller sur les liens qui sont fournis par OWASP https://owasp.org/Top10/A01_2021- Broken_Access_Control/ 5 20 24-09-14  Le détail ❑Lorsque vous allez faire un peu de développement il peut être intéressant d’aller voir ce site. Le détail du CWE vous permet d’obtenir ▪ Une description exhaustive de la vulnérabilité. ▪ Les synonymes utilisés pour la vulnérabilité. ▪ Les vecteurs d’attaque, les plateformes visés ▪ Les conséquences habituelles ▪ Est-ce que c’est probable ? C’est quoi l’impact ▪ Des exemples ▪ Comment on le mitige, et ce, par phase de développement. ▪ Comment on le détecte ▪ Des références ▪ Des exemples de produits qui ont eu cette vulnérabilité 6 20 24-09-14  ❑OWASP ▪ Qui est OWASP ? ▪ Le projet OWASP TOP 10 ❑OWASP TOP 10 2021, 5 premiers ▪ A1 Contrôles d’accès défaillants ▪ A2 Défaillances cryptographiques ▪ A3 Injection ▪ A4 Conception non sécuritaire ▪ A5 Mauvaise configuration de sécurité 7 20 24-09-14  A1 Contrôles d’accès défaillants I Propriétés Valeur Applications testées et vulnérables (2021) 94% Exploitabilité 69% Impact 59% 8 20 24-09-14  A1 Contrôles d’accès défaillants II Description ❑Afin de contrôler ce que les utilisateurs peuvent ou ne peuvent pas faire dans une application, on leur donne des permissions. ❑Ces permissions sont accordées en utilisant un système de contrôle d’accès. ❑Un contrôle défaillant signifie donc que certaines permissions ne sont pas bien implantées, pensées ou appliquées. Cible ❑Données ou service Types d’attaque ❑Parcours de répertoire (Path Traversal) ❑Élévation de privilège ❑Accès aux comptes d’autre utilisateur ❑Etc. 9 20 24-09-14  A1 Contrôles d’accès défaillants I II Vulnérabilités courantes ❑Être trop permissif : ne pas suivre le principe du moindre privilège ou il est dit que les fonctions devraient être inaccessibles par défaut. ❑Altérer paramètres, url ou contenu d’une requête pour outrepasser les contrôles d’accès. ❑Permettre une élévation de privilège grâce à une erreur logicielle ou un défaut de conception ❑Altérer les métadonnées dont les jetons de connexion ❑Forcer la navigation pour accéder à des pages privilégiées (ex. monsite.com/wp-admin, monsite.com/admin_GetAppInfo, monsite.com/settings, etc.). ❑Ne pas se soucier de l’origine des ressources ❑Permettre des modification/insertion/suppression sans contrôle d’accès. 10 20 24-09-14  Exemple de référence non sécuritaire Qu’est-ce qui arrive si on essaie 512515? 11 20 24-09-14  A1 Contrôles d’accès défaillants I V Mesures de protection ❑À l’exception des ressources publique, refuser tous les accès par défaut ❑Module d’autorisation flexible et réutilisable ❑Contrôle d’accès par rôle (RBAC) ❑Désactiver les listes de dossiers ❑Journalisation des accès bloqués ❑Limiter le nombre de requêtes aux API ❑Supprimez tous les comptes inactifs ou inutiles ❑Utiliser l’authentification multi facteur à tous les points d’accès ❑Fermez les points d’accès inutiles ❑Appliquer le principe du moindre privilège ❑Éliminer les services qui ne sont pas nécessaires sur votre serveur ❑Path Traversal ▪ Encodage des entrées 12 20 24-09-14  A2 Défaillances cryptographiques I Propriétés Valeur Applications testées et vulnérables (2021) 79% Exploitabilité 73% Impact 68% 13 20 24-09-14  A2 Défaillances cryptographiques II Description ❑Accès à des données sensibles due à : ▪ L’absence de chiffrement ▪ Un bris des mécanismes cryptographiques ❑Problème ou absence de cryptographie Cible ❑Données en repos ❑Données en transit Cause ❑Transmission ou stockage de données sensibles en clair notamment directement dans le code. ❑Fonctions vulnérables ❑Protocoles inappropriés ❑Clés trop petites ❑Ne pas valider adéquatement le certificat, la signature ou la chaîne de confiance 14 20 24-09-14  Chiffrement symétrique vs asymétrique I Symétrique ❑ Clé de déchiffrement == clé de chiffrement ❑ La clé doit toujours être gardée secrète ❑ Plusieurs moyens de transmission de clé ❑ Chiffrement par bloc et flux Asymétrique ❑ Deux clés différentes ▪ Clé publique ▪ Clé privée ❑ Lorsque généré correctement, il n’est pas possible d’obtenir la clé privée à partir de la clé publique ❑ Facilite la gestion de clés ❑ Permets plusieurs autres applications au-delà du chiffrement 15 20 24-09-14  TLS I Il faut zoom er ☺ 16 20 24-09-14  Choisir les algorithmes ❑TLS est un ensemble de concepts. On veut une cryptographie symétrique afin que les échanges soient rapides. Mais on veut une cryptographie asymétrique afin d’échanger la clé de la cryptographie symétrique. ❑Dans un serveur IIS (serveur web Windows), on a l’ensemble de ces cases cochés 17 20 24-09-14  ❑ Il est important de désactiver les protocoles et les fonctions non utilisés comme dans l'exemple ci-haut. ❑ Les clients vont utiliser les fonctions et protocoles disponibles sur le serveur. Il faut donc les choisir préalablement. ❑ Cipher veut dire chiffrer (algorithme d’encryption). ❑ Si vous désactiver les SSL par exemple vous vous assurez que le serveur ne permette pas à un client d'utiliser ce protocole. 18 20 24-09-14  Fonctions de hachage ❑Objectif premier : intégrité ❑Propriétés d’une fonction de hachage cryptographique ▪ Pour un message X, h(X) est toujours identique ▪ Pour tous messages X, h(X) a toujours la même taille ▪ Il est extrêmement difficile de retrouver X à partir de h(X). ▪ Pour tous messages X, il est extrêmement difficile de trouver un message Y pour que h(X) = h(Y) ▪ Pour tous changements de X, aussi minime soit-il, h(X) et h(X’) ne se ressemble pas 19 20 24-09-14  Diffie-Hellman I Objectifs ❑Confidentialité ❑Valide les interlocuteurs en vérifiant le secret Inconvénient ❑Vulnérable aux attaques MITM ❑Diffie-Helman ne permet de chiffrer un message. Donc, insuffisant pour assurer une communication sécurisée. 20 20 24-09-14  Diffie-Hellman II 21 20 24-09-14  Diffie-Hellman III 22 20 24-09-14  Fonctions de dérivation de clés ❑Pour stocker les mots de passe, nous avons plusieurs fonctions qui se base sur SHA-512 ▪ PBKDF2, bcrypt, scrypt, Argon2 ▪ Hachage cryptographique (SHA-512) + salt ▪ Utilisation de clé 23 20 24-09-14  Un Salt I ❑Combiner le mot de passe et le « salt » (salage) ▪ Le « salt » peut être sauvegardé en texte clair auprès du mot de passe ou le sauvegardé en binaire avec le code de hachage (ex. les 8 premiers octets, c’est le salt, et le reste, le code de hachage) ▪ Aléatoire ❑Objectif ▪ Augmenter la protection des mots de passe ▪ Combattre les « rainbow table » ou attaque de dictionnaire ❑Erreurs d’utilisation ▪ Réutilisation ▪ Trop petite taille ▪ Prédictible 24 20 24-09-14  Mesures de protection I ❑Classer les données traitées, stockées ou transmises ❑Mettre en place des contrôles de sécurité en fonction de la classification des données ❑Garder uniquement les données nécessaires ❑Assurez-vous que des algorithmes, protocoles et clés fortes sont en places ▪ Gestion des clés ❑Pour les mots de passe ▪ PBKDF2/bcrypt/scrypt/Argon2 ❑Chiffrer toutes les données sensibles au repos ❑Utiliser un générateur de nombre aléatoire qui est fiable ❑Utiliser du chiffrement (TLS) pour toutes les communications ▪ Externe et interne 25 20 24-09-14  Mesures de protection II ❑Ne pas combiner HTTP et HTTPS (contenu mixte) ❑HTTPS « stripping » avec sslstrip ❑Ne pas offrir de page non chiffrée pour du contenu sécuritaire ❑Utiliser HSTS (HTTP Strict Transport Security) ❑Désactiver la mise en cache pour les réponses contenant des données sensibles ❑Utiliser des protocoles de chiffrement existants NB : Ne pas développer votre propre chiffrement  A3 Injections I Propriétés Valeur Applications testées et vulnérables (2021) 94% Exploitabilité 73% Impact 72% Causes A3 Injections II Description ❑Modification de la logique des requêtes ❑Causé par l’absence ou la mauvaise utilisation de mesure de validation Types d’injections ❑Injection SQL (SQL Injection) ❑Injection de XPath ❑Injection de LDAP Langage ❑Interaction avec des bases de données Cible ❑Le contenu des bases de données  A3 Injections III Causes ❑Données utilisateurs non validées, filtrées ou épurées. ❑Utilisation de requêtes dynamiques au lieu d’être paramétrées, ❑Les données externes sont utilisées telles quelles.  SQL I ❑ SQL (sigle de Structured Query Language, en français langage de requête structurée) est un langage informatique normalisé servant à exploiter des bases de données relationnelles. ❑ Une base de données SQL contient : ▪ Des tables ▪ Des attributs (colonnes) ▪ Des valeurs ❑ Exemple : Le mot de passe de l’utilisateur admin est contenu dans la table users de la base de données website sous l’attribut password. ❑ Les principales actions exécutées sur une base de données : ▪ INSERT ▪ UPDATE ▪ SELECT ▪ DELETE  La syntaxe est la suivante : SQL II Chaînes de caractère : 1 SELECT * FROM [ dbo ].[ USERS ] WHERE username = 'admin' AND password = 'oiuewr8767ewrjk' Valeurs numériques : 1 SELECT * FROM [ dbo ].[ LOG ] where id = 10 Les fonctions et procédures stockées : 1 SELECT COUNT (1) from [ USERS ] 2 exec [ dbo ].[ sp UserList] ' managers '  Les opérateurs booléens : SQL III 1 AND , OR , && , || Les commentaires 1 SELECT * FROM [ dbo ].[ LOG ] 2 SELECT * FROM [ dbo ].[ LOG ] -- Retourne tous les logs 3 SELECT * FROM [ dbo ].[ LOG ] # Retourne tous les logs  Les conditions SQL IV 1 IF( CONDITION , VALEUR , VALEUR ) 2 CASE WHEN IsAdmin =1 THEN 'Administrateur' ELSE 'Utilisateur' END Les opérateurs de comparaison 1 =, , >, =, valeur (des grands dictionnaires) ▪ clé>document ▪ graphes ▪ Tuples. ❑La permission se fera souvent sur le chemin d’accès. Clés avec tels textes, permettez le Select.  Distribué et infonuagique I ❑pour un SQL, on a la notion de Master > Slave. La Master traite les mises à jour, les slave les lectures. ❑pour un NoSQL, les partitions sont sur plusieurs machines et répliqués. Ils utilisent le protocole LWW (celui qui écrit le dernier gagne) ❑Pour une BD infonuagique, il est important de bien définir les rôles et valider qui a accès le défaut a tendance à être trop permissif. ❑Prendre le temps de faire les utilisateurs et mettre les informations de connexion dans la voûte du cloud. ❑Les bases de données infonuagiques font habituellement parties d’un groupe de ressources avec qui ils peuvent interagir. ❑Si votre BD n’a pas besoin d’avoir un accès externe, n’en mettez pas. On donne un accès qui va expirer dans le temps.  Démo SQL ❑Installation d’un SQL et MS SQL Management Studio ❑MS SQL Management Studio : les grandes lignes de l’interface ❑Restauration d’une BD ❑Ajout de SQL Login et d’utilisateur ❑Ajout de rôle. ❑Faire des sélections ❑Faire des JOIN ❑Activer l’audit ❑Lire l’audit. 31 11/4/2022  CR440 – Sécurité applicative SQL, partie 2 1  Sommaire qObjectif : Protéger vos données § Stratégies de stockage § Chiffrements des données dans une base de données § Utilisation des fonctions de hachage § Protection des données personnelles § Protéger les configurations, faire des sauvegardes, activer les audits § Les rôles, les groupes, les utilisateurs. 2  Stratégies gagnantes qNe stockez pas ce que vous n’avez pas de besoin. Faites une diète de données qCryptez les données sensibles qUtilisez le principe du moindre privilège dans vos rôles qActivez https et utilisez-le en tout temps qActivez l’encryption qUtilisez le code de hachage pour les mots de passe. SHA- 256 au minimum qUtilisez des voutes pour les clés et identifiants qFaites des backups. 1) localement, 2) ailleurs dans l’établissement, 3) dans le cloud. 3  Activer TLS I q Pour activer TLS. Il nous faut un certificat. q Habituellement, on acheter un certificat : https://docs.microsoft.com/fr-fr/sql/database- engine/configure-windows/enable-encrypted-connections- to- the-database-engine?view=sql-server-ver15 q Il faut faire attention d’avoir les bonnes TextExtension. q Pour les besoins du cours, on créera nous-même notre certificat. q La commande suivante permet de le faire. 4  Activer TLS II 1 New-SelfSignedCertificate -Type SSLServerAuthentication -Subject "CN=$env:COMPUTERNAME" -FriendlyName 'SQL Server SELF-SIGNED' -DnsName "$env:COMPUTERNAME",'localhost.' -KeyAlgorithm 'RSA' -KeyLength 2048 -Hash 'SHA256' - TextExtension '2.5.29.37={text}1.3.6.1.5.5.7.3.1' -NotAfter (Get-Date).AddMonths(36) -KeySpec KeyExchange -Provider 'Microsoft RSA Schannel Cryptographic Provider' -CertStoreLocation Cert:\LocalMachine\My 5  Activer TLS III qPour la suite, il faut connaître le service qui fait rouler votre SQL. Pout se faire, rechercher l’application « Gestion de l’ordinateur » 6  Activer TLS IV qAllez sur « Services et applications » puis sur « SQL Server Configuration » puis sur « SQL Server Services » Sélectionnez le SQL Server que vous avez installé et regarder la colonne Log On As. 7  Activer TLS V qCette colonne vous indique le nom du service qui roule le SQL. Elle sera utile lorsqu’on assignera le certificat. De mon côté c’est NT Service\MSSQL$CRSECURITEAPPLI habituellement, le défaut est le NT Service\MSSQLSERVER. Retenez ce nom 8  Activer TLS VI q Cherchez dans le menu démarrer Certificat. Vous allez trouver l’outil "Gérer les certificats de l’ordinateur" q Ajoutez le service SQL (que vous avez retenu) comme lecteur du certificat. 9  Activer TLS VII q Ensuite réouvrez Gestion de l’ordinateur et forcez l’encryption pour votre SQL qSélectionner le certificat que vous avez créé et faites ok. 10  Activer T L S VIII 11  Schémas I qLes schémas nous donne une façon de regrouper des objets de façon sémantique. qÇa simplifie l’ajout de sécurité car on peut donner une permission sur les objets d’un schéma qLe schéma par défaut est 1 [dbo] qOn crée des schémas en faisant 1 CREATE SCHEMA [MonSuperSchema] qOn peut changer de contexte de sécurité en utilisant un execute as... 12  Schémas II 1 Execute AS User='MonSuperUtilisateur' qC’est intéressant si on a des requêtes qui demandent des permissions que normalement on n’a pas. qCelui qui crée la procédure doit avoir la permission : 1 IMPERSONATE 13  Sécurité par enregistrement I qLes politiques de sécurité sur SQL sont intéressant car il permette une sécurité granulaire à l’administrateur. qEx. Si on avait des soft delete pour la table [Blogger].[Article] mais que pour les utilisateurs, on ne voudrait pas que les enregistrements apparaissent si on a IsDeleted=1 : Bien, on peut le faire ! 1 CREATE FUNCTION dbo.fn_securityreadonly(@IsDeleted bit) 2 RETURNS TABLE WITH 3 SCHEMABINDING AS 4 RETURN SELECT 1 AS fn_securitypredicate_result where 5 @IsDeleted=0; qPuis on ajoute la politique 14  Sécurité par enregistrement II 1 CREATE SECURITY POLICY dbo.OnlyUndeletedArticles 2 ADD FILTER PREDICATE dbo.fn_securityreadonly(IsDeleted) ON Blogger.Articles WITH (STATE=ON,SCHEMABINDING=ON); qVoir ici : https://docs.microsoft.com/fr-ca/sql/relational- databases/security/row-level-security?view=sql-server- ver15 15  Les masques dynamiques I qLes masques permets de cacher des valeurs comme le début d’une carte de crédit par exemple 1 ALTER TABLE FINANCEDATA 2 ALTER COLUMN CardNumber ADD MASKED WITH (FUNCTION='partial(0,"XXXX-XXXX-XXXX-",4)'); qPour afficher le numéro, il faut la permission UNMASK qCelui qui fera un select aura comme résultat le XXXX- XXXX-XXXX-1234 qIl y a des fonctions automatique comme email() pour faire [email protected] 16  Les masques dynamiques II qVoir la doc pour plus d’info : https://docs.microsoft.com/fr-ca/sql/relational- databases/security/dynamic-data-masking?view=sql- server-ver15 17  Le Service Master Key I qLa clé de service est la clé de base qui sert à encrypter tout le reste incluant les autres clés. Elle utilise le AES256 et est une clé symétrique. qUne bonne pratique est de sauvegarder cette clé et de la mettre en voute (on verra au prochain cours). Si un désastre surviendrait, il est nécessaire d’avoir cette clé pour décrypter les bases de données systèmes et retrouver les clés pour décrypter les bases de données. 1 BACKUP SERVICE MASTER KEY TO FILE = 'c:\keys\service_master_key' ENCRYPTION BY PASSWORD = 'fdsklj543@ekl!' NB : Il faut que le dossier existe! 18  Le Service Master Key II 1 RESTORE SERVICE MASTER KEY FROM FILE = 'c:\keys\service_master_key' DECRYPTION BY PASSWORD = 'fdsklj543@ekl!' 19  Encryption simple I qOn peut utiliser ENCRYPTBYPASSPHRASE(MOT_DE_PASSE,valeur,0) et DECRYPTBYPASSPHRASE(MOT_DE_PASSE,valeur,0) qOn peut imaginez avoir un mot de passe statique qMais aussi on pourrait imaginez que vous avez un utilisateur qui a un mot de passe. Lorsqu’il enregistre la donnée pour la première fois, on encrypte des données avec son mot de passe. qLorsqu’il a besoin des informations, il fournit son mot de passe. qLorsqu’il change sont mot de passe, l’ancien mot de passe sert à décrypter et le nouveau mot de passe sert à réencrypter. 20  Encryption simple II 1 SELECT ENCRYPTBYPASSPHRASE('ldksrj#!e432','Ma chaîne sécuritaire',0) 1 SELECT cast(DECRYPTBYPASSPHRASE('ldksrj#!e432', ENCRYPTBYPASSPHRASE('ldksrj#!e432','Ma chaîne sécuritaire',0),0) as varchar(max)) 21  Encryption plus complexe qLe Always Encrypted permet d’avoir une clé pour l’ensemble des colonnes à encrypter. C’est donc plus simple à mettre en place. qhttps://docs.microsoft.com/fr-ca/sql/relational- databases/security/encryption/always-encrypted-database- engine?view=sql-server-ver15 qL’une des limitations est qu’il faut un client compatible qui pourra aller chercher la clé de décryption. Voici un exemple avec ASP.NET Core § https://khaledelsheikh.medium.com/configuring-always- encrypted-on-azure-sql-by-using-azure-key-vault-and- entity-framework-core-aae687ff2c63 22  Encrypter une BD I qSql permet l’encryption des données. On peut encrypter des bases de données directement à l’aide d’un certificat. use MASTER CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'fdslkjh45932084!'; CREATE CERTIFICATE MyCertificate WITH SUBJECT = 'DB Certificate' USE ProductDatabase CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE MyCertificate; ALTER DATABASE ProductDatabase SET ENCRYPTION ON 23  Encrypter une BD II qOn peut sauvegarder le certificat 1 USE MASTER 2 BACKUP CERTIFICATE MyCertificate 3 TO FILE ='C:\Cert\DbServerCert.cer' 4 WITH PRIVATE KEY ( FILE = 'C:\Cert\DbServerCert.prvk', ENCRYPTION BY PASSWORD = 'fdslkjh45932084!' ); 5 Attention : Les données sont cryptées dans le fichier de données (donc si on récupère le.mdf). Elles sont décryptées lorsqu’une application lit les données de façon transparente. 24  Encrypter une colonne... I qPour encrypter une colonne, on fait le même processus mais au niveau de la BD CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'SQLShack@1'; CREATE CERTIFICATE Certificate_test WITH SUBJECT = 'Protect my data'; CREATE SYMMETRIC KEY SymKey_test WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE Certificate_test ; qDisons qu’on a une table comme ceci : 25  Encrypter une colonne... II qLe NAS devrait être minimalement encrypter ! § Voici comment on fait : ALTER TABLE sales.Customers ADD nas_encrypt varbinary(MAX ) OPEN SYMMETRIC KEY SymKey_test DECRYPTION BY CERTIFICATE Certificate_test ; UPDATE sales.Customers SET nas_encrypt = EncryptByKey(Key_GUID('SymKey_test'), nas) FROM sales.Customers; CLOSE SYMMETRIC KEY SymKey_test; 26  Encrypter une colonne... III qça nous donne : qEnsuite, on supprime l’ancienne colonne et on renomme celle qu’on vient d’ajouter pour nas. Et le tour est joué. 27  Permissions pour encrypter ou décrypter I qOn ne veut pas que tout le monde puisse utiliser nos clés. Seulement une petite portion des utilisateurs. On peut donc donner ces permissions sur une clé spécifique pour un utilisateur. GRANT VIEW DEFINITION ON SYMMETRIC KEY::SymKey_test TO SQLShack; GO GRANT VIEW DEFINITION ON Certificate::[Certificate_test] TO SQLShack; GO GRANT CONTROL ON Certificate::[Certificate_test] TO SQLShack; 28  Pour décrypter... I OPEN SYMMETRIC KEY SymKey_test DECRYPTION BY CERTIFICATE Certificate_test; SELECT TOP (1000) [customer_id],[first_name],[last_name], convert( varchar, DecryptByKey([nas_encrypt])) as NAS_DECRYPT FROM [sales].[customers] CLOSE SYMMETRIC KEY SymKey_test; 29  Pour décrypter... II NB : On pourrait utiliser des clés asymétriques.... Mais ça diminuerait beaucoup la performance. 30  Pourquoi encrypter une colonne ? qSi un hacker est capable de lire la colonne, il ne trouvera pas de données utiles. qIl lui faut le certificat pour pouvoir décrypter ce qui se trouve dans l’enregistrement. qOn évite au administrateur de pouvoir voir les données sensibles facilement. 31  Encryptez une colonne façon Always Encrypted I qAlways Encrypted permet d’utiliser le magasin de secret de windows. Ce qui est bien. Cependant, il faut que l’application qui utilise la bd supporte Always Encrypted ce qui n’est pas toujours le cas. Il suffit de sélectionner la colonne voulue et de suivre les étapes du tutoriel pour avoir l’encryption de la colonne : 32  Encryptez une colonne façon Always Encrypted II qLe certificat va s’ajouter ici par défaut : 33  Encryptez une colonne façon Always Encrypted III qVous pouvez voir comment vos applications vont voir vos colonnes. Il suffit de l’activer. 34  Encryptez une colonne façon Always Encrypted IV qDerrière, le type de la colonne a un ajout de certains paramètres: qLors des étapes de l’assistant, on vous demande si vous voulez une encryption déterministe ou non. Déterministe, veut dire que le résultat pour une même valeur sera pareil. L’aléatoire : non. Si on a besoin de cette donnée pour faire des jointures, index ou regroupement : on va utiliser déterministe, sinon aléatoire. Est-ce que j’ai choisi le bon? (oui, parce que j’ai besoin d’un index pour valider l’unicité) 35  Faire des sauvegardes I qOn peut faire des sauvegardes planifiés avec les tâches de l’agent SQL. qSur SMSS, on appelle ça des Plan de maintenance. qSi vous avez SQL Express, vous pouvez le faire avec des tâches planifiées windows et un simple powershell. qManuellement, c’est aussi simple que faire un clic droit > Tâches > Sauvegardes... qIl ne faut pas oublier d’encrypter la sauvegarde ! 36  Faire des sauvegardes II 37  Faire des sauvegardes III BACKUP DATABASE SQLTestDB TO DISK = 'c:\tmp\SQLTestDB.bak' WITH FORMAT, MEDIANAME = 'SQLServerBackups', NAME = 'Full Backup of SQLTestDB ', ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = MyCertificate ); 38  Fonctions de hachage qLes 2 fonctions de hachage que vous pouvez utiliser et qui sont assez fortes en ce moment sur sql sont : § SHA2_256 § SHA2_512 qOn les utilise comme ça : 1 SELECT HashBytes('SHA2_256','Hello World!') 39  Authentification I qLe stockage de mot de passe peut se faire avec un Hash mais aussi avec un salage. qUn sel (salt) permet de complexifier artificiellement un mot de passe pour l’attaquant qui reçoit les hash. qUn sel est des caractères autogénérés : qPrenons le mot de passe password. qPrenons un sel OBLpGpYkDjKdxy. qCe qu’on hash c’est donc : passwordOBLpGpYkDjKdxy qIl est donc plus complexe. Cependant, si une fonction de dérivation de clé est disponible sur votre application, utilisez-la au lieu du hachage directement dans la base de données. qPour les mots de passe, il est important d’avoir les caractéristiques habituelles : 40  Authentification II q Mot de passe minimum de 8 q Mot de passe maximum de 64 q Utilisation de tous les caractères Unicode q Utilisez Https dans un contexte web. q Souhaitable T L S 1.3 : version la plus récente et sécuritaire q Message d’erreur peu explicite. q Ne dites pas que c’est le mot de passe qui ne fonctionne pas pour pas que l’attaquant sache qu’il a trouvé le bon nom d’utilisateur ! q Utilisez une librairie qui testent vraiment la robustesse. Exemple : zxcvbn 41  Définitions Permissions, privilèges ou droits Ce sont des droits d’accès (Lecture, écriture, suppression, etc) aux données del’organisation qui sont donnéesà des utilisateurs ou groupes. Groupe Ensemble d’utilisateurs qui participent à une même tâche et donc devraient avoir les mêmes accès. Ex :Admins de l’entreprise. Nous assignerons ensuite un rôle avec les permissions appropriées à ce groupe. Rôle Un rôle est souvent un département ou une tâche dans une organisation. Ex : Finances ou Commis de bureau. Le contrôle d’accès basé sur les rôles vous aide à gérer qui a accès aux ressources de votre organisation et ce qu’il peut faire avec ces ressources. Utilisateur Correspond à une personne physique ou un service dans l’organisation à qui l’on peut donner 42  Relation entre structure organisationnelle, rôles et permissions I qLa gestion des accès est un processus complexe qui intègre différentes règles, procédures et technologies. qDe ce fait, elle nécessite la contribution de l’ensemble des entités administratives de l’organisme. qCette gestion doit répondre à quatre questions : 1. Qui a accès à quelle information ? 2. Qui a approuvé l’accès ? 3. L’accès est-il adapté aux tâches à accomplir ? 4. L’accès et les opérations en découlant sont-ils correctement surveillés, consignés et enregistrés ? 43  Relation entre structure organisationnelle, rôles et permissions II qRisques associés à une mauvaise gestion des accès § Accès non autorisé : Un accès non autorisé peut mettre en péril la disponibilité, l’intégrité ou la confidentialité de l’information qu’une organisation détient dans l’exercice de ses fonctions. Il pourra ainsi causer des dommages importants, voire irréversibles, à l’organisation. § Altération ou destruction de données : L’altération ou la destruction de données peut engendrer des résultats inexacts ou incomplets, voire un ralentissement ou une interruption des services offerts. À titre d’exemple : une altération avec intention de fraude. 44  Relation entre structure organisationnelle, rôles et permissions III § Divulgation de l’information ou vol de données La divulgation de l’information ou le vol de données est susceptible d’avoir des impacts de diverses natures : atteinte à l’image de marque de l’organisation, atteinte au droit des citoyens à la protection des renseignements personnels qui les concernent et à leur vie privée, baisse de confiance à l’égard de l’État, pertes financières, etc. § Attribution trop élevée de privilèges. L’usurpation de privilèges permet à une personne non autorisée d’accéder à de l’information sensible, voire de prendre le contrôle d’applications critiques pour l’organisation. Elle pourra ainsi causer des dommages importants, voire irréversibles, à l’organisation. 45  Créer un rôle qComme on l’a vu, la première étape est de définir un rôle. Par exemple une manager pourrait pouvoir créer des éléments dans la BD. Un autre pourrait la lire. 1 CREATE ROLE manager; qUne fois le rôle créé, on peut utiliser GRANT pour ajouter des permission : 1 GRANT create table, create view TO manager; 46  Exemple de structure (NASA) I qChaque personne comme chaque application doit avoir § un rôle spécifique : § Une application du Ingénieur chef ne devrait pas avoir accès aux performances financières par exemple. qChaque département pourrait être un rôle : § Exploration Systems, Space Operations, Science, etc qChacun de ces rôles aurait certaines permissions : § À certains serveurs À certaines applications Pour certaines postes Pour certaines tables 47  Astuces I qLes rôles doivent avoir le minimum de sécurité qu’il a de besoin avec le minimum de table qu’il a de besoin. qUtiliser les schémas. On peut appliquer des autorisations sur les schémas qNe pas utiliser les rôles par défaut SQL : datareader, system admin, etc. Ce ne sont pas des rôles que vous devriez utiliser. qLimitez les personnes qui connaissent le SA qUtiliser un mot de passe complexes pour SA 48  Rôle I qLe définition des rôles se fait avec la notion du moindre privilège derrière qUne des stratégies de rôles serait d’avoir un rôle pour un département, affichant les tables communes. en lecture. qUn autre rôle pour avoir les accès en édition et création qUn autre rôle en suppression. qPuis ça peut se faire sur certaines parties. Ces parties sont définis selon votre classification. On aurait donc un rôle supplémentaire qui permettrait de sélectionner les données qui sont hautement confidentielle. qEn exemple, on a des départements, chacun des départements devrait avoir un accès à certaines tables seulement.... et ce en lecture... ce sont les tables privées. ex RH  Rôle II qEn écriture (création/édition), un autre rôle pourrait être ajouté. ex. RH_Recruteur qEn suppression on peut avoir un autre rôle en plus. ex. RH_Admin qPuis, il faut regrouper les tables selon leurs classifications pour ajouter des rôles et leur associer les tables plus confidentielles. De telle sorte que si un processus a besoin de voir les historiques de paies, on n’a pas nécessairement besoin du NAS et si c’est absolument nécessaire, bien il faut lui donner le rôle correspondant : ex. RH_TaxReportManager  Vues I On peut se fier aux exemples ici (surtout la première exemple) : https://docs.microsoft.com/en-us/sql/t- sql/statements/create-view-transact-sql?view=sql-server- ver15#examples Ces vues permettent de sélectionner seulement des attributs qu’on veut montrer : 1 CREATE VIEW HumanResources.hiredate_view AS 2 SELECT p. FirstName, p.LastName, e.BusinessEntityID, 3 e.HireDate FROM HumanResources.Employee e 4 JOIN Person.Person p 5 ON e.BusinessEntityID = p.BusinessEntityID;  Vues II qL’utilisation des vues est indiquée pour permettre à des rôles de voir seulement certaines informations qui normalement serait disponible avec la sélection de l’ensemble de la table.  Classification des données I q La classification des données nous donne un aperçu de la sensibilité et de l’impact des données sur l’utilisateur q Principes fondamentales : § On classe les informations selon leur contenu et leur sensibilité § Certains points permettront de classifier ce contenu § Risques pour la personne § Risques pour les activités d‘une organisation § Risques pour les actifs ou les intérêts commerciaux d’une organisation § Risques pour la sécurité nationale, l’ordre public ou les relations étrangères q Papier blanc de l‘OAS et de AWS : https://www.oas.org/fr/ssm/cicte/docs/FRA- Classification-Des-Donnees.pdf  Classification des données II qVous devez allez sur votre BD et faire qLe panneau Data Classification va vous permettre de sélectionner les tables et colonnes que vous voulez classer: 54  Classification des données III 55  Classification des données IV qOn ajoute la classification et on enregistre! 56  Classification des données V qLe rapport… 57  CR440 Sécurité applicative Cours 11 1  Sommaire ❑Sécuriser les données traitées par l’application ▪ Voute ▪ Gestion des exceptions et des erreurs ▪ Obfuscation du code source ▪ Validation des données ▪ Encodage, caractères d’échappement, filtres des données ▪ Authentification 2  Une voute ❑Permet de garder les secrets afin d’éviter de les éparpiller un peu partout dans votre réseau et que ça devienne ingérable ❑Permet la gestion des secrets, l’accès ainsi que des rôles, la rotation de clés, l’encryption et l’audit. 3  Des exemples de voute ❑Une voute est un système spécialisé dans le stockage d’information encryptée : des secrets ❑Azure a son produit : Azure Key Vault ❑Amazon, AWS secrets manager : ❑https://aws.amazon.com/fr/secrets-manager/ ❑Google, Cloud Secret Manager : ❑https://cloud.google.com/secret-manager ❑Votre entreprise pourrait mettre en place un tel service interne comme le HashiCorp Vault 4  Protéger les configurations ❑L’utilisation des voutes est l’une des meilleures façons de protéger les configurations puisqu’un admin système peut gérer l’ensemble des clés et elles ne sont pas éparpillées un peu partout. Elles sont cryptées et on peut révoquer les accès facilement. ❑Si on a besoin d’utiliser des fichiers de configuration, il faut les encrypter s’ils contiennent des secrets. ❑On peut aussi utiliser des Variables d’environnement, mais le contenu n’est pas crypté et les personnes qui ont accès à l’ordinateur ont accès aux variables d’environnement ❑Ne jamais mettre des clés dans le code source. ❑Éviter de les mettre dans les fichiers de configuration ❑Éviter de les logger. ❑Faites une rotation régulière des clés. Ex. à chaque 30 jours 5  Cas HashiCorp Vault : Comment ça fonctionne I ❑Habituellement on va avoir un serveur de voute encrypté. ❑La clé pour décrypter les secrets est divisée en plusieurs parties (habituellement 5) afin d’avoir la possibilité de diviser la responsabilité du décryptage. ❑Cette procédure du décryptage est faite à chaque fois que la voute est (re)démarrée : Un utilisateur donne sa clé, un autre puis un autre sur un total de 5 possibles. ❑Les secrets qui sont ainsi décryptés afin de le fournir aux applications sont gardés dans une mémoire volatile telle que la mémoire vive. Il utilise la fonction mlock de le système d‘exploitation pour éviter que les clés se retrouvent sur le disque. ❑Le serveur utilise TLS 1.3 6  Voute : Comment ça fonctionne II ❑Chaque service a un token qu’il peut utiliser. Il a une durée de vie plus ou moins longue et doit être renouvelé. ❑Le token identifie le service et donc on peut lui associer un rôle (AppRole) dans lequel il a accès à certain secret et fichier seulement. ❑Voyons une démo. 7  Utilisation d’une voute I ❑ Si on prend comme exemple le Azure Key Vault ❑ Une fois déployé dans le cloud de Azure, on peut ajouter des politiques d’accès qui nous permet d’ajouter des permissions : 1 az keyvault set-policy --name "" --object-id "" --secret-permissions get list …puis, on peut l’utiliser 8  Utilisation d’une voute II Demo avec hashicorp vault 9  Les exceptions I 1 public async string GetSomeInfo(int repeatNumber=5){ 2 try { 3 4 var result = await GetMyAwesomeValueAsync(); 5 return result; 6 7 } catch (NoInternetException e){ 8 9 log (e); 10 11 if (repeatNumber == 0){ 12 throw new NeedToManuallyRepeatException (); 13 // ou throw ; 14 // Traitez l'exception à l'appelant. Afficher à l'utilisateur : Problème de connexion , réassayer. 10  Les exceptions II 15 } 16 17 return await GetSomeInfo((--repeatNumber)) 18 19 } catch (Exception e){ 20 21 log (e); 22 // Traiter l'exception 23 24 } 25 } ❑ Des stratégies doivent être mises en place pour l’ensemble des exceptions pour avoir un logiciel robuste : par exemple : ▪ Un serveur sql n’est plus disponible 11  Les exceptions III ▪ Un serveur d’envoie de courriel n’est pas disponible ▪ Il y a des erreurs temporaires (des transients) ▪ Il y a des erreurs de données ▪ Le stockage de l’ordinateur est trop plein ▪ Etc. ❑Les logs devraient être centralisés afin qu’ils puissent être traités. ❑Lorsqu’on a une exception non gérée, elle devrait être aussi attrapée. 12  Les exceptions IV ❑Par exemple : 1 app.UseExceptionHandler(errorApp => 2 { 3 errorApp.Run ( async context => 4 { 5 //... log it , do something 6 }); 7 }); 13  Obfuscation I ❑L’obfuscation est l’art de rendre illisible un code source. 1 // Paste your Java Script code here 2 function hi() { console. log (" 3 Hello World !"); 4 } 5 hi(); Devient... 14  Obfuscation II (function(_0x45f22f,_0x1273ce){var _0x56d91b=_0x59b1,_0x264caa=_0x45f22f();while(!![]){tr y{var _0x28470b=parseInt(_0x56d91b(0x16a))/0x1*(parseInt(_0x 56d91b(0x167))/0x2)+parseInt(_0x56d91b(0x16c))/0x3+- parseInt(_0x56d91b(0x163))/0x4*(- parseInt(_0x56d91b(0x166))/0x5)+parseInt(_0x56d91b(0x1 69))/0x6*(- parseInt(_0x56d91b(0x164))/0x7)+parseInt(_0x56d91b(0x1 62))/0x8+-parseInt(_0x56d91b(0x16b))/0x9*(- parseInt(_0x56d91b(0x160))/0xa)+parseInt(_0x56d91b(0x1 65))/0xb*(- parseInt(_0x56d91b(0x168))/0xc);if(_0x28470b===_0x1273 ce)break;else _0x264caa['push'](_0x264caa['shift']());}catch(_0x5de3 b7){_0x264caa['push'](_0x264caa['shift']());}}}(_0x48c 15 4,0x2e09e));function hi(){var  Obfuscation III ❑Il y a certainement un peu de perte de performance dans un langage interprété ❑Mais ça prévient le vol de code source lorsqu’on publie l’application 16  Validation de données : Les bonnes pratiques I ❑Utilisez une librairie de validation. Toutes les librairies d’accès aux données en ont une. ❑Les seules validations qui nous aident à sécuriser l’information sont les validations au niveau serveur. ❑Il faut valider les entrées mais aussi les sorties. ❑Centraliser vos validations ❑Standardisez les entrées : ex : 514 655 3243 vs (514) 655- 3245 vs 1-514-655-3243 vs 51.46.55.32.45 ❑Une erreur de validation = rejet de l’action ❑Valider AVANT d’agir ❑Validez types, limites, maximum, minimum, ❑Utilisez les listes blanches [A-Za-z0-9@] au lieu des listes noires [^.,*] 17  Validation de données : Les bonnes pratiques II ❑On préfère bloquer et accepter ce qu’on veut par rapport à tout accepter et limiter pour évidemment garder le système le plus hermétique possible ❑Ayez une attention particulière pour éviter les injections de code à l’aide des caractères utilisés dans les différents langages : ex. ▪ XML : < > " ▪ SQL : ' % ▪ Conditions : ( ) & + ▪ Échappements : \ \’ \” ▪ Vérifiez : null, retour à la ligne, les../ et les..\ ❑La validation ▪ Dépends de la donnée ! ▪ Dépends de ce que vous voulez stocker. ▪ N’est pas fait en une seule étape. ▪ Plusieurs éléments doivent être valider ! 18  Validation de données : Les bonnes pratiques ❑Selon Microsoft : (suite) ❑https://docs.microsoft.com/fr-ca/sql/relational- databases/security/sql-injection?view=sql-server-ver15 ▪ Ne présumez pas la taille, le type, le contenu d’une donnée ▪ Testez la taille et le type de données. Appliquez des limites. ▪ Acceptez uniquement les valeurs attendues ▪ Validez le schéma du XML et les entrées lorsque vous utilisez du XML ▪ Implanter plusieurs niveaux de validations ▪ Utilisez les paramètres SQL de type sécurisé sur toutes commandes SQL. ▪ Filtrez les données préalablement (utiliser la sécurité par enregistrement) ▪ Limitez les entrées à la limite de la variable. Ex. QUOTENAME() possède une limite de 128 caractères. 19  Sécuriser les données I ❑Dois-je les stocker ? ❑Est-ce qu’on en a vraiment besoin dans le système ? ❑Où dois-je les stocker ? ❑Base de données, fichier ? ❑Est-ce que j’ai besoin de la valeur ? ▪ ex. Mot de passe ❑Qui a accès ? Qui a vraiment accès ? ❑Est-ce que le type est adapté (varchar(max) vs nvarchar(255), Int ? ▪ Possibilité de submerger la BD. ▪ Chance de corrompre les données. ▪ Chance de stocker une donnée dans un mauvais format ! ❑Ma donnée est-elle légitime ? ❑Est-ce que la valeur est celle qu’on s’attend ? 20  Analyser les données I ❑On veut valider que ce qu’on envoie au client est bien ce qui est attendu : ▪ Utiliser un regex. ▪ Faire des remplacements de caractères spéciaux ▪ Utiliser une liste blanche ❑Mais aussi, ▪ Encoder/décoder les données ▪ Utiliser les caractères d’échappements ou les entités de remplacement. ▪ dans le jargon des librairies on appelle ces différentes actions un Sanitizer (un désinfectant) ▪ Encoder/décoder les paramètres ❑Ex. Une url formée d’un nom d’entreprise sans encodage pourrait ressembler à ceci. ▪ https://monsupersite.com/Transactions/List?EnterpriseName=Pratt & Whitney 21  Analyser les données II ❑Combien de paramètres à votre avis ? 1 ? Et non ! Votre site va recevoir ces 2 ❑On encode, pour éviter d’avoir ce genre de mauvais comportement ▪ https://monsupersite.com/Transactions/List?EnerpriseNam e=Pratt%20%26%20Whitney 22  Caractères d’échappement I ❑Disons que nous avons un système avec des tables créées dynamiquement : on a les champs prénom, nom et références : ❑select prenom, nom, references from dbo.people ❑Le problème ici c’est que references est un mot reservé. Si on utilise les caractères d’échapements : ❑select [prenom], [nom], [references] from dbo.people ❑Ça évite un bris de logique ! ❑Le même principe s’applique dans les attaques XSS. ❑On va vouloir remplacer: 23  Multi-facteurs I ❑L’une des bonnes pratiques en authentification est d’ajouter la possibilité d’utiliser le multi-facteur. ▪ Objectif : diminuer les risques qu’une personne non autorisée accède à un compte. ▪ Deux façons : ▪ À l’aide d’un code d’authentification généré et envoyé par message texte ou courriel. ▪ Le hacker doit hacker ces deux systèmes pour entrer dans un compte ▪ À l’aide d’une application authentifiée sur un autre appareil (ex. Windows Authenticator) qui reçoit les demandes d’authentification et attend que l’utilisateur accepte sur cet autre appareil. ▪ Le hacker doit avoir accès à cet autre appareil ou se faire passer pour cet appareil. 24  Les rôles dans le domaine applicatif I ❑Dans une application, on utilise le même principe de rôles que dans un système de fichier ou un système de gestion de base de données. ▪ Il faut ajouter ces rôles de façons déclaratives. ❑Les rôles sont définis par le développeur. ❑La grande différence avec les rôles système c’est qu’on voit souvent... ▪ Des rôles spécifiques à une permission donnée Exemple : CanViewPosts,CanHidePosts, CanDeletePosts, CanEditPosts, etc. ❑Oui ce sont des groupes d’utilisateurs, mais les rôles sont utilisés d’une façon beaucoup plus granulaire. En effet, la notion de permissions sur une ressource existe rarement dans les Framework de développement au niveau des modèles. 25  Session, profil, cookie I ❑Une session : démarre durant l’ensemble d’une communication entre un client et un service. ❑En web, la session est identifiée par un cookie habituellement contenant l’identifiant de la session encrypté. ❑Vous pouvez essayer, aller sur Facebook, supprimer vos cookies, Vous serez déconnecté. ❑Un cookie est un fichier texte contenant... du texte. Il est transmis à chaque requête et peut rester sur l’ordinateur durant un temps défini. ❑On s’en sert pour identifier l’utilisateur et la session. ❑On s’en sert aussi pour garder des préférences ou des informations clients 26  Session, profil, cookie II ► Un profil utilisateur, ce sont toutes les métadonnées descriptives d’un utilisateur (ex. une bio, son numéro de téléphone, etc.). ► On parle aussi de scope utilisateur. ► Habituellement, ce profil est stocké en Base de données. ► Il arrive qu’on stocke des informations avec les jetons (tokens) d’authentification pour y avoir accès. (ex. rôles, date de connexion, etc.) 27  Les jetons d’authentification I ❑Vous identifie ! ❑Nécessité d’être sous TLS (préférablement 1.3) ❑Un jeton d’authentification, c’est le chiffrement (habituellement) d’un ticket d’authentification. ❑Il contient le chiffrement d’un dictionnaire clé-valeur de : nom d’utilisateur, date de fin de validation du jeton, les rôles et le profil ❑Le déchiffrement du jeton est fait à chaque requête qui demande authentification. ❑Pour se déconnecter, on supprime l’endroit où est stocké le jeton 28  Les jetons d’authentification II Source : https://docs.microsoft.com/en-us/azure/active- directory/develop/v2-oauth-ropc ❑ La sécurité d’un jeton d’authentification réside dans le fait que ce jeton n’est transmis qu’au navigateur et qu’au serveur. Il faut donc s’assurer d’avoir du HTTPS sécuritaire (TLS 1.3). 29  Les jetons d’authentification III ❑On l’utilise en le mettant dans l’en-tête des appels sous Authorization Format : (exemple ici, un token de type Bearer) Authorization : Bearer eyJhbGciOi... ou simplement dans un cookie (c’est dépendant du framework) ❑Les informations contenues dans le jeton sont souvent gardées au niveau serveur. (Jamais décrypté sur le client...) ❑Si on a besoin de ces informations, on va utiliser un JWT. 30  Les jetons d’authentification IV ❑ Le JWT contient aussi les informations utilisateurs mais elles sont partagées. ❑ Direction ici : https://jwt.io/ ❑ Exemple d’un token HS256 (symétrique) : eyJhbGciOi- JIUzM4NCIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkw ❑ Base64(algo utilisé). contenu. signature ❑ Il permet de valider via la signature le contenu. ❑ L’authentification se base sur la signature au lieu du message crypté. ❑ Intéressant car le client peut avoir le contenu et voir l’information car il n’est pas crypté. 31  La tokenisation ❑ Permet de remplacer une donnée sensible par un élément équivalent qui n’aura aucune valeur intrinsèque. ❑ Un système de log qui détecte qu’un mot de passe a été fourni pourrait le remplacer par ***** avant la sauvegarde. ❑ Un autre aspect de la tokenisation serait de permettre les achats en ligne : ❑ Un exemple de ça est Apple Pay. Lorsqu’on lie la carte à notre application, le numéro de la carte n’est pas stocké. Mais plutôt un numéro généré par le service de carte de crédit qui est facilement révocable, qui peut avoir une rotation de clé et qui a une limite dans le temps. ❑ Obtenir ce numéro n’aide pas l’attaquant puisqu’il n’est pas utilisable sans ton compte et ton téléphone (l’autorité). 32  Sérialisation ❑Désactiver les formats que vous n’utilisez pas. ❑Souvent les APIs vont activer JSON et XML par défaut. Si vous n’utilisez pas XML, désactivez-le. ❑Les sérialiseurs ont différentes configurations de sécurité. Valider ces configurations. ❑Vérifier que votre analyseur de code vérifie la qualité et surtout les règles de sécurité : https://docs.microsoft.com/en- us/dotnet/fundamentals/code-analysis/quality- rules/security-warnings ❑Utilisez des types spécifiques. JsonConvert.DeserializeObject(json) n’est pas sécuritaire ! 33  Questions 34  CR440 – Sécurité applicative Cours 12 – SSDL, WAF et log 1  Sommaire I ❑Cycle de vie de développement sécuritaire ▪ Un SDL ▪ NIST SSDF ▪ Préparer l’organisation