Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Fiches pédagogiques sur la sécurité des logiciels CyberEdu Ce document pédagogi

Fiches pédagogiques sur la sécurité des logiciels CyberEdu Ce document pédagogique a été rédigé par un consortium regroupant des enseignants-chercheurs et des professionnels du secteur de la cybersécurité. Il est mis à disposition par l’ANSSI sous licence Creative Commons Attribution 3.0 France. Version 1.3 — Février 2017 CyberEdu version 1.3 Table des matières 1 Fiche 1 : Vulnérabilités logicielles standard 5 2 Fiche 2 : Sécurité intrinsèque des diﬀérents langages de programmation 9 3 Fiche 3 : Pratiques et méthodologies pour le développement sécurisé 15 4 Fiche 4 : Outils d’analyse de vulnérabilités 19 Fiches pédagogiques sur la sécurité des logiciels Page 2/24 CyberEdu version 1.3 Introduction Les ﬁches pédagogiques présentées dans ce guide ont pour objectif de mettre en avant les éléments fondamentaux de la sécurité du développement logiciel qui peuvent être présentés à des étudiants de l’enseignement supérieur non-spécialistes du domaine. Les ﬁches apportent à l’enseignant des repères pédagogiques mais ne peuvent constituer à elles seules un support d’apprentissage pour l’enseignant. Prérequis pour les étudiants Chacune des quatre ﬁches indique les prérequis nécessaires à sa compréhension. Les prérequis portent sur les connaissances fondamentales en développement logiciel : les vulnérabilités logicielles standard, la sécurité des diﬀérents langages, les bonnes pratiques de développement et les outils d’analyse de vulnérabilités. Prérequis pour les formateurs Les ﬁches apportent des repères pédagogiques aux enseignants, en présentant de manière structurée et concise les sujets importants de la sécurité du développement logiciel. Ces ﬁches ne constituent pas un cours complet sur la sécurité du développement logiciel. Il n’est pas demandé à l’enseignant de parfaitement maîtriser le domaine de la sécurité, mais il devra se renseigner sur les sujets présentés pour pleinement exploiter les ﬁches pédagogiques. Une bonne maîtrise des diﬀérents langages de programmation étudiés est fortement conseillée. Utilisation du guide pédagogique Ce document contient quatre ﬁches pédagogiques à destination des enseignants en développement logiciel dans l’enseignement supérieur. Chaque ﬁche permettra à l’enseignant d’illustrer son cours de développement avec des notions de sécurité. Typiquement, l’enseignant consacrera une trentaine de minutes à la sécurité à la ﬁn de chacun de ses chapitres. Les ﬁches peuvent être présentées en tout ou partie, dans l’ordre approprié à l’enseignement et aux étudiants visés. Fiches pédagogiques sur la sécurité des logiciels Page 3/24 CyberEdu version 1.3 Numéro Sujet Durée (min) Prérequis Fiche 1 Vulnérabilités logicielles standard 30-45 Compilation - Corruption de mémoire par déborde- ment de pile d’appel Architecture des ordinateurs - Injection SQL - Programmation défensive et concep- tion orientée sécurité Fiche 2 Sécurité intrinsèque des diﬀérents lan- gages de programmation 45-60 Programmation (niveau intermédiaire) - Diﬀérences entre programmation défensive et mécanismes de sécurité - Mécanismes de sécurité des dif- férents langages - Notion de programme « déﬁni » Fiche 3 Pratiques et méthodologies pour le développement sécurisé 15-30 Développement logiciel (notions) - Surface d’attaque d’un logiciel - Principe des moindres pivilèges - Paramétrage des environnements d’exécution et de compilation Fiche 4 Outils d’analyse de vulnérabilités 30-45 Compilation - Recherche de vulnérabilités logiciels par fuzzing - Analyse de teintes - Types d’alertes en analyse statique Fiches pédagogiques sur la sécurité des logiciels Page 4/24 CyberEdu version 1.3 1 Fiche 1 : Vulnérabilités logicielles standard 1.1 Thématique Thématique Vulnérabilités logicielles standard Numéro de ﬁche 1 Mise à jour 05/01/2016 Ce cours aborde les sujets suivants : – la corruption de la mémoire par débordement de pile d’appel ; – l’injection SQL ; – la programmation défensive et conception orientée sécurité. 1.2 Thèmes des cours visés – Programmation – Compilation – Architecture des ordinateurs 1.3 Volume horaire Entre 30 et 45 minutes. Deux versions restreintes sont envisageables en évoquant uniquement la corruption de la mémoire par débordement de pile d’appel ou uniquement les injections SQL. Les contre-mesures de program- mation défensive devront être évoquées dans les deux cas. 1.4 Prérequis / corequis Cette activité s’intègre dans un cours de programmation ou en complément d’un cours de com- pilation, voire d’architecture des ordinateurs. Dans ces derniers cas, on pourrait supprimer l’étude d’une injection SQL et étoﬀer la présentation d’une corruption de la mémoire avec l’utilisation d’un débogueur. Si la ﬁche est utilisée dans un cours de programmation, il faudra veiller à ce que la notion de convention d’appel ait été préalablement présentée lors d’un cours d’architecture ou de compilation. 1.5 Objectifs pédagogiques L’objectif pédagogique de cette activité est de sensibiliser les étudiants aux vulnérabilités logicielles les plus classiques, en insistant sur les erreurs de conception qui peuvent mener à de telles vulnéra- bilités. 1.6 Conseils pratiques Un partie des mots clés de cette ﬁche sont parfois connus des étudiants informaticiens mais nous conseillons de prendre le temps de bien faire comprendre les mécanismes mis en jeux. La respons- Fiches pédagogiques sur la sécurité des logiciels Page 5/24 CyberEdu version 1.3 abilité du programmeur à utiliser des contre-mesures adaptées doit aussi être soulignée. 1.7 Description L’enseignant précise au préalable le modèle d’attaquant considéré ici : le programme de l’utilisateur est exécuté dans un environnement hostile où l’attaquant peut soumettre des entrées dans le but de pousser le programme à la faute. Deux exemples classiques d’attaques pourront être proposés. Le premier, une corruption mémoire par débordement de tampon (buﬀer overﬂow), est une des attaques les plus classiques. On peut par exemple l’illustrer en prenant un petit programme C. #include <stdio.h> #include <string.h> int verifie_mot_de_passe () { int res = 0; char tampon [10]; scanf("%s", &tampon); if (strcmp (tampon , "secret") == 0) res = 1; return res; } int main () { if (verifie_mot_de_passe ()) { // code privilégié } return 0; } En exécutant le programme et en fournissant une entrée suﬃsamment longue, il est facile de provoquer une corruption de la mémoire (segmentation fault). En tapant « abcdefghijklmn », un attaquant peut même changer la valeur de retour sans connaître le mot de passe. Attention, le changement du ﬂot d’exécution ne pourra pas forcement être observé, car il dépend à la fois des options de compilation (nous conseillons l’option -O0 pour réaliser cette expérience) et de l’architecture matérielle considérée. Pour faire comprendre le phénomène, il convient de rappeler les bases des conventions d’appels en génération de code. Un schéma de l’état de la pile d’appel après l’appel de fonction scanf permettra de faire comprendre le risque d’écraser l’adresse de retour de l’appel de verifie_mot_de_passe() et les variables locales de la fonction. En fonction du volume horaire alloué, une utilisation d’un débogueur pourra être proposée pour suivre pas-à- pas une attaque par débordement de tampon menant à une exécution de code arbitraire [1] (voir notamment la section 3.12 intitulée Out-of-Bounds Memory References and Buﬀer Overﬂow). Une protection eﬃcace contre un tel débordement est l’option -fstack-protector-all de gcc, qui implémente les canaris (une case mémoire insérée dans la pile pour vériﬁer que celle-ci n’a pas été modiﬁée 1). 1. Il est intéressant de noter que certaines distributions Linux l’activent par défaut, rendant la démonstration impossible. Pour la désactiver le temps du TP uniquement, il faut ajouter -fno-stack-protector. Fiches pédagogiques sur la sécurité des logiciels Page 6/24 CyberEdu version 1.3 La deuxième vulnérabilité qui pourra être présentée est une corruption d’argument de type injection SQL dans un script PHP. Cette attaque est très connue et largement documentée. L’attaquant soumet une chaîne de caractères sur un formulaire et cette chaîne est ensuite utilisée pour construire une requête SQL sur une base de donnée. Supposons que la requête soit de la forme : SELECT * from table WHERE login=’$login ’ AND password=’$pwd ’ avec $login et $pwd des entrées directement fournies sous forme de chaînes de caractères par un attaquant potentiel. Si la première chaîne est ’ OR 1=1#, puisque le symbole # indique le début d’un commentaire SQL, la requête transmise à la base de données sera simplement : SELECT * from table WHERE login=’’ OR 1=1 Cette requête devient triviale : elle ignore la vériﬁcation de mot de passe et interroge tous les noms de login de la base. Il conviendra de donner un exemple classique comme celui-ci mais surtout d’insister sur les leçons à tirer de cette vulnérabilité. Ceci fait l’objet de la deuxième partie de la ﬁche. Nous recommandons de ne pas dissocier les deux parties. La liste des attaques par injection SQL et les dégâts occasionnés sont immenses (vol, altération et/ou destruction de données). Le cours pourra s’orienter vers l’his- toire des failles de type Cross-site scripting pour prolonger l’étude de ce problème [2]. Pour illustrer des injections reposant sur d’autres langages, il est aussi possible de présenter des vulnérabilités reposant sur des langages de script comme bash (voir par exemple la vulnérabilité CVE-2010-3088). Face à ces vulnérabilités, la première contre-mesure est de penser, très tôt durant la conception, au modèle d’attaquant. Si certaines données du programme proviennent d’un environnement po- tentiellement hostile, le programmeur doit défendre son programme vis-à-vis de ces entrées. Les hypothèses réalisées sur les entrées sensibles doivent non seulement être explicités, mais testées à l’exécution grâce à une programmation défensive. Chaque langage de programmation possède des contre-mesures spéciﬁques, par exemple les bibliothèques C gérant explicitement la taille des chaînes uploads/Litterature/ fiches-developpement-1-3.pdf