SlideShare une entreprise Scribd logo
OWASP Application Security Verification Standard 2009 Microsoft TechDays  8 Février 2010  Paris Palais des congrès Sébastien Gioria (French Chapter Leader & OWASP Global Education Comittee Member) [email_address]
Sébastien Gioria Plus de 12ans en Sécurité des Systèmes d’Informations. Leader du chapitre Français de l’OWASP && Membre du comité d’éducation mondial. Consultant sénior en sécurité des systèmes d’informations.  Président du club Régional de la SSI de Poitou-Charentes (affilié au CLUSIF). Expériences professionnelles :  Directeur Technique Hébergement et RSSI d’un opérateur télécoms mondial. RSSI Adjoint d’une Banque Nationale Française. RSSI Adjoint au sein d’une Assurance Française. Domaines de prédilection :  Web 0.9 à Web 4.2, WebServices
L’OWASP  (Open Web Application Security Project) Indépendant des fournisseurs et des gouvernements. Objectif principal : produire des outils, documents et standards dédiés à la sécurité applicative. Tous les documents, standards, outils sont fournis sur la base du modèle open-source. Organisation : Réunion d’experts indépendants en sécurité informatique Communauté mondiale (plus de 100 chapitres) réunie en une fondation américaine pour supporter son action. L’adhésion est gratuite et ouverte à tous En France  : une Association.  Le point d’entrée est le wiki  http://www.owasp.org
Les ressources de l’OWASP Un Wiki, des Ouvrages, un Podcast, des Vidéos, des conférences,  une Communauté active .
Les publications Toutes les publications sont disponibles sur le site de l’OWASP:  http://www.owasp.org L’ensemble des documents est régi par la licence GFDL (GNU Free Documentation License) Les publications majeures : Le TOP 10 des vulnérabilités applicatives Le Guide de l’auditeur/du testeur Le  Code Review Guide Le guide de conception d’applications Web sécurisées L’Application Security Verification Standard (ASVS) La FAQ de l’insécurité des Applications Web Building Guide Code Review Guide Testing Guide Application Security Desk Reference (ASDR) Le Top 10 fait référence à tous ces guides
Type d’attaques applicatives Source : Rapport Cenzic – 1 er  semestre 2009
Faiblesse des Applications Web Etude du GARTNER  2003 75% des attaques ciblent le niveau Applicatif 66% des  applications web sont vulnérables Application Web Eléments Réseaux 75 % 90 % 25 % 10 % % Attaques % Dépenses Etude du SANS (septembre 2009) http://www.sans.org/top-cyber-security-risks/
L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
Philosophie de l'ASVS Il se veut un standard pour vérifier la sécurité des applications Web. Il se veut indépendant des applications/framework Il se veut indépendant des cycles de développement Il définit les éléments nécessaires à appliquer à une application sans avoir à interpréter celui ci. Points importants : Il définit plusieurs niveaux de vérification de la sécurité Les différences entre les niveaux et l’étendue de la couverture doit être linéaire Les éléments fonctionnels à vérifier doivent utiliser une approche de type liste blanche Il doit être indépendant des outils et des techniques de vérification !!!!
Quelles réponses apporte l'ASVS Quelles sont les fonctionnalités à mettre en oeuvre dans les contrôles de sécurité nécessaires à mon application Quelle est la couverture et le niveau de rigueur à mettre en oeuvre lors de la vérification de sécurité d'une application Web. Comment comparer les différentes vérifications de sécurité effectuées Quel niveau de confiance puis-je avoir dans une application Web
L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
Que sont les niveaux de vérification de l'ASVS
Techniques de vérification de la sécurité applicative Découverte des vulnérabilités dans l’application en ligne  Découverte des vulnérabilités dans le code source  Approche Globale Utilisation d’outils automatisés Revue de code statique  automatisée Pentest Manuel Revue de code Manuel
Définition des niveaux Level 1 – Vérification automatisée (vérification partielle de l'application) Level 1A –Scan dynamique Level 1B – Scan du code source Level 2 – Vérification manuelle (vérification partielle de l'application) Level 2A – Test d'intrusion Level 2B – Revue de code Level 3 – Vérification de la conception Level 4 – Vérification des fonctions internes
Level 1 en détail Vérification automatisée d'une application vue comme un groupe de composants  et une seule application monolithique
Level 1 Options Level 1A  Scan partiel de manière dynamique (aka ClikaWarrior) Level 1B  Scan partiel du code source (aka GrepWarrior) Les 2 sont nécessaires pour obtenir un niveau 1 complet
Au mieux un outil voit 45 % des failles Une étude de MITRE a démontré que les outils de tests applicatifs des éditeurs ont découverts 45% des vunérabilités Ils ont découvert peut d'overlap entre les outils, il est donc nécessaire de les avoir tous pour avoir 45% de couverture.
Niveau 2 en détail Vérification manuelle d'une application organisée en niveaux d'architecture
Level 2 Options Level 2A  Pentests manuels (aka BurpSuiteWarrior) Level 2B  Revue de code manuelle (aka EoinWarrior) Il n’est pas nécessaire d’effectuer des scans automatisés pour atteindre ces niveaux !! Les 2 sont nécessaires pour obtenir un niveau 2 complet.
Level 3 en détail Level 2 + Modèlisation des menaces pour vérifier la conception
Level 4 en détail Revue interne de l'application à la recherche de code malveillants (pas de virus/malware uniquement) et examination des fonctionnements des contrôles de sécurité
Que sont les exigences de vérification de l'ASVS Exigences d'architecture Exigences de vérification de la sécurité Liste d'éléments détaillée par niveau
Une approche positive ! Negative Rechercher les failles XSS…. Positive Vérifier  que toutes les données disposent d'un échappement propre des entrées fournies. See:  http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
Quels sont les exigences de rapport de l'ASVS R1 –Introduction R2 – Description de l'application R3 – Approche architecture R4 – Résultats de la vérification
L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
Par ou commencer L'acheteur et le vendeur se mettent d'accord sur les exigences de sécurité qui seront vérifiées en spécifiant le niveau ASVS Vérification initiale de l"application
Et ensuite…. Développe et executer une stratégie de correction… Re-vérifier que les différents fixes sont la  Mettre en place une stratégie permettant d'ajouter les vérfications dans le cycle de développement.
Integrating ASVS into your SDLC (Outsourcing not required)
Les 14 familles d’exigences  V1. Architecture de sécurité  V2. Authentification V3. Gestion de Sessions  V4. Contrôle d'accès V5. Validations d'entrées  V6. Encodage et échappement de sorties V7. Cryptographie V8. Gestion des erreurs et de la journalisation  V9. Protection des données  V10. Sécurité des communications  V11. HTTP Sécurisé  V12. Configuration de la sécurité  V13. Recherche de codes malicieux  V14. Sécurité interne
Plus d'infos  La page du projet http://www.owasp.org/index.php/ASVS
Plus d'infos Le PDF du document est disponible sur la page du projet http://www.owasp.org/index.php/ASVS   La liste de diffusion est disponible pour toutes questions : Voir le lien  “ Mailing List/Subscribe" Tip: Subscribe a la liste en 1 clic : [email_address]
L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
Les 14 familles d’exigences  V1. Architecture de sécurité  V2. Authentification V3. Gestion de Sessions  V4. Contrôle d'accès V5. Validations d'entrées  V6. Encodage et échappement de sorties V7. Cryptographie V8. Gestion des erreurs et de la journalisation  V9. Protection des données  V10. Sécurité des communications  V11. HTTP Sécurisé  V12. Configuration de la sécurité  V13. Recherche de codes malicieux  V14. Sécurité interne
Architecture de sécurité Il s’agit principalement d’exigences de documentation de l’architecture : Exemples :  Exigence L1 L2 L3 L4 Vérifier que tous les composants de l'application sont identifiés (aussi bien les composants individuels que les groupes de fichiers sources, bibliothèques de fonctions, et/ou fichiers exécutables. ✔ ✔ ✔ ✔ Vérifier que tous les composants qui ne font pas partie de l'application, mais dont l'application dépend pour fonctionner, soient correctement identifiés. ✔ ✔ ✔ Vérifier qu'une architecture de haut niveau a bien été définie pour l'application ✔ ✔ ✔
Authentification Il s’agit de vérifier l’ensemble des mécanismes permettant de s’assurer que l’utilisateur est le bon. Exigence L1 L2 L3 L4 Vérifier que toutes les pages et ressources exigent bien une authentification excepté celles qui sont spécialement prévues pour être public. ✔ ✔ ✔ ✔ Vérifier que tous les contrôles d'authentification ont une implémentation centralisée (les contrôles incluent les bibliothèques qui font appel des services d'authentification externes). ✔ ✔ ✔ Vérifier que tous les certificats d'authentification servant à accéder des services externes à l'application soient cryptés et stockés dans un endroit protégé (pas dans le code source). ✔ ✔ ✔
Gestion des sessions Vérification que le mécanisme des sessions est suffisamment surs L’authentification doit être simple, centralisée et standardisée Utiliser le mécanisme standard de gestion des cookies du framework (ils sont globalement fiables) Utiliser constamment SSL  pour protéger les identifiants de connexion et de sessions  Exigence L1 L2 L3 L4 Vérifier que l'implémentation du contrôle de gestion des sessions par défaut du framework est utilisé par l'application. ✔ ✔ ✔ ✔ Vérifier que les jetons de session d'authentification soient suffisamment long et aléatoires pour résister aux menaces typiques de l'environnement déployée. ✔ ✔ Vérifier que les cookies qui contiennent les jetons/ids de session d'authentification ont leurs domaine et chemin définit sur une valeur suffisamment restrictive pour ce site. ✔ ✔
Contrôle d’accès S’assurer que les accès aux fonctions et données sont limitées aux seuls utilisateurs  autorisés. Exigence L1 L2 L3 L4 Vérifier que les utilisateurs ne puissent accéder qu'aux URLs pour lesquelles ils possèdent des autorisations spécifiques. ✔ ✔ ✔ ✔ Vérifier que les contrôles d'accès échouent de manière sécurisée. ✔ ✔ Vérifier que toutes les décisions de contrôles d'accès ainsi que toutesgestion d'erreur soient journalisées. ✔ ✔
Validation des entrées S’assurer que les données entrantes dans l’application sont « propres » Utiliser les filtres de type Anti-XSS Initialiser les chaînes pour éviter les débordements de tampon. Exigence L1 L2 L3 L4 Vérifier que l'environnement d'exécution n'est pas sujet aux débordements de tampon, ou que les contrôles de sécurité préviennent les débordements de tampons. ✔ ✔ ✔ ✔ Vérifier que tous les échecs de validation des entrées soient journalisés. ✔ ✔ ✔ Vérifier que chaque entrée de données soient conforme en aval pour tous les décodeurs ou interpréteurs préalablement à la validation. ✔ ✔
Encodage et échappement de sortie S’assurer que les données sortantes ne renvoie pas de données « sales » : Utilisation de l’OWASP ESAPI Exigence L1 L2 L3 L4 Vérifier que toutes les données non fiables qui doivent sortir sous forme de HTML (incluant HTML éléments, HTML attributs, données Javascript, blocks CSS, et attributs d'URLs) soient correctement échappés en fonction du contexte. ✔ ✔ ✔ ✔ Vérifier que toutes les données non sûres qui sont inclut dans descommandes de système d'exploitation soient correctement échappées. ✔ ✔ ✔ Vérifier que pour chaque type de sortie encodée/échappée exécutée par l'application, il n'y ait qu'un seul contrôle de sécurité pour ce type de sortie pour la destination prévue. ✔ ✔
Vérification cryptographique S’assurer que chiffrements sont surs : Pas d’utilisation de DES, Rot13…. Exigence L1 L2 L3 L4 Vérifier que toutes les fonctions cryptographiques utilisées dans l'application soient implémentées coté serveur. ✔ ✔ ✔ Vérifier que tous les nombres aléatoires, noms de fichiers aléatoires, GUIDs aléatoires, et chaines de caractères aléatoires soient générés par un module cryptographique, dont le générateur de nombres aléatoire soit approuvé, et dont les valeurs aléatoires ne puissent être prévues par un attaquant. ✔ ✔ ✔ Vérifier que les modules cryptographiques utilisés par l'application soient validées par le standard FIPS 140-2 ou un standard équivalent. (voir http://csrc.nist.gov/groups/STM/cmvp/validation.html). ✔ ✔
Gestion des erreurs et de journalisation S’assurer qu’il n’y a pas d’envoi de données sensibles à l’utilisateur. Exigence L1 L2 L3 L4 Vérifier que l'application n'envoie pas sur la sortie des messages d'erreurs ou des traces de pile contenant des informations sensibles qui pourraient aider un attaquant, incluant les ids de session et les informations personnelles. ✔ ✔ ✔ Vérifier que les contrôles de sécurité de connexion permettent dejournaliser les succès ET échec d'évènements qui sont identifiés comme liés à la sécurité. ✔ ✔ ✔ Vérifier que l'application ne journalise pas des donnée sensibles spécifiques à l'application qui pourraient aider un attaquant, incluant les ids de session utilisateur et les informations personnelle ou sensible. ✔ ✔ ✔
Protection des données S’assurer que les données soient protégées vis a vis des règles métiers et légales. Exigence L1 L2 L3 L4 Vérifier que tous les formulaires contenant des informations sensibles ont désactivé les caches coté client, incluant les fonctionnalités d'auto- complétion. ✔ ✔ ✔ ✔ Vérifier que tous les caches ou copies temporaires de données sensibles stockées sur le serveur soient protégées d'accès non autorisés ou purgées/invalidées après que l'utilisateur autorisé ait accédé à ces données. ✔ ✔ ✔ Vérifier qu'il y a une méthode pour supprimer chaque type de données sensibles de l'application à la fin de la période de rétention requise. ✔ ✔
Vérification des communications sécurisées S’assurer qu’il n’y a pas de transmission de données sensibles sur des canaux en clair (HTTP). Exigence L1 L2 L3 L4 Vérifier qu'un chemin peut être créé depuis chaque CA de confiance vers chaque certificat de serveur TLS (Transport Layer Security), et que chaque certificat de serveur est valide. ✔ ✔ ✔ ✔ Vérifier que toutes les connexions à un système externe qui impliquent des informations ou des fonctionnalités sensibles utilisent un compte qui soit réglé pour avoir le minimum de privilèges nécessaire à l'application pour fonctionner correctement. ✔ ✔ ✔ Vérifier qu'un encodage de caractères spécifique est définit pour toutes les connexions (par ex. UTF-8) ✔ ✔
Vérifications de sécurité HTTP S’assurer que les éléments transitant dans HTTP sont au maximum de leur sécurité Exigence L1 L2 L3 L4 Vérifier que les redirections n'incluent pas de données non validées ✔ ✔ ✔ ✔ Vérifier que les entêtes HTTP ne contiennent que des caractères imprimables ASCII dans les requêtes et réponses. ✔ ✔ ✔ Vérifier que l'application génère un jeton aléatoire solide comme partie de tout lien ou formulaire associé à une transaction ou accédant à des données sensibles. Vérifier que l'application vérifie la présence du jeton contenu une valeur valide pour l'utilisateur courant lorsqu'il traite ces requêtes. ✔ ✔
Vérification de la configuration de la sécurité S’assurer que toutes les informations de configuration sont stockées de manière sécurisée Exigence L1 L2 L3 L4 Vérifier que toutes les informations de configurations liées à la sécurité sont stockées dans un endroit protégé des accès non-autorisés. ✔ ✔ ✔ Vérifier que tout changement dans la configuration de la sécurité gérée par l'application soit journalisé dans les journaux d'évènements de sécurité. ✔ ✔ Vérifier que le stockage de la configuration peut être ouvert dans un format lisible par un humain pour faciliter l'audit. ✔
Principes de développement  KISS : Keep it Short and Simple 8 étapes clés :  Validation des entrées Validation des sorties Gestion des erreurs Authentification ET Autorisation Gestion des Sessions Sécurisation des communications Sécurisation du stockage Accès Sécurisé aux ressources
KISS : Keep it Short and Simple Suivre constamment les règles précédentes Ne pas « tenter » de mettre en place des parades aux attaques Développer sécurisé ne veut pas dire prévenir la nouvelle vulnérabilité du jour Construire sa sécurité dans le code au fur et a mesure et ne pas s’en remettre aux éléments d’infrastructures ni au dernier moment.
L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
Pas de recette Miracle Mettre en place un cycle de développement sécurisé ! Auditer et Tester son code ! Vérifier le fonctionnement de son Application ! La sécurité est d’abord et avant tout affaire de bon sens.
Rejoignez nous  ! http://www.owasp.fr

Contenu connexe

PPT
Audit
 
PDF
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
PDF
Rapport PFE VoIP
PDF
VPN site-to-site.pdf
PDF
Mise en place d’un système de détection
PPTX
Présentation audits de sécurité
PDF
Système de supervision des réseaux de capteurs sans fil
PDF
Travaux Dirigée: Equipements d'interconnexion
Audit
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
Rapport PFE VoIP
VPN site-to-site.pdf
Mise en place d’un système de détection
Présentation audits de sécurité
Système de supervision des réseaux de capteurs sans fil
Travaux Dirigée: Equipements d'interconnexion

Tendances (20)

PDF
1 - Généralités - Réseaux Informatiques.pdf
PDF
QCM basique sur les réseaux informatiques
PPT
Mécanismes de sécurité
PPTX
Sécurité informatique
PDF
Réseaux et protocoles - Cours + exercices
PPTX
Les systèmes de détection et prévention d’intrusion
PDF
TELEPHONIE SUR IP
PPTX
Etude et mise en place d'une solution d'administration et de supervision Open...
PDF
Fiche TD sur les systèmes informatiques
PPSX
Les architectures client serveur
PDF
sécurité informatique
PDF
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
PDF
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
PDF
Alphorm.com Formation Hacking et Sécurité 2020 (4of4) : Attaques AD et Web
PPTX
Sécurité Réseau à Base d'un Firewall Matériel (fortigate)
PPTX
Architectures orientés services (SOA)
PDF
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
PDF
Commutation
PPTX
IDS,SNORT ET SÉCURITÉ RESEAU
PDF
PRÉSENTATION D’UN KIT SIEM DÉDIÉ AUX PMES
1 - Généralités - Réseaux Informatiques.pdf
QCM basique sur les réseaux informatiques
Mécanismes de sécurité
Sécurité informatique
Réseaux et protocoles - Cours + exercices
Les systèmes de détection et prévention d’intrusion
TELEPHONIE SUR IP
Etude et mise en place d'une solution d'administration et de supervision Open...
Fiche TD sur les systèmes informatiques
Les architectures client serveur
sécurité informatique
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
Alphorm.com Formation Hacking et Sécurité 2020 (4of4) : Attaques AD et Web
Sécurité Réseau à Base d'un Firewall Matériel (fortigate)
Architectures orientés services (SOA)
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
Commutation
IDS,SNORT ET SÉCURITÉ RESEAU
PRÉSENTATION D’UN KIT SIEM DÉDIÉ AUX PMES
Publicité

En vedette (20)

PDF
Rénovation énergétique efficace : Guide travaux pour la performance du logeme...
PPT
RevolucióN De 1859
PPT
Los Foros De Trabajo Colaborativo En El Campus
PDF
00 encuadre bd1-3
PPS
Ser Pobre O Rico Hoy
PPT
Fotoreportaje instalaciones FAME
PDF
Introduction sur les tablettes numériques
PDF
L'impact de la mobilité sur le e-commerce
PDF
Brochure Bachelors FR
PDF
cambiocultural. ITIL
PPT
La Veille De Né Kid du 04.03.09 : les pop-up stores
PPTX
Digital Breakfast 2009 : Initier et piloter une conversation
PDF
Khaled Ben Driss 28 Fev 2007 V1.0.4
PDF
La veille de Né Kid du 02.06.11 : la neutralité du net
PDF
Nodo centro occidente región
PPS
Redes sociales
PPT
Perspectivas 2011-2012_Inteligencia de Negocios Atalaya
PDF
Sevilla se mueve
Rénovation énergétique efficace : Guide travaux pour la performance du logeme...
RevolucióN De 1859
Los Foros De Trabajo Colaborativo En El Campus
00 encuadre bd1-3
Ser Pobre O Rico Hoy
Fotoreportaje instalaciones FAME
Introduction sur les tablettes numériques
L'impact de la mobilité sur le e-commerce
Brochure Bachelors FR
cambiocultural. ITIL
La Veille De Né Kid du 04.03.09 : les pop-up stores
Digital Breakfast 2009 : Initier et piloter une conversation
Khaled Ben Driss 28 Fev 2007 V1.0.4
La veille de Né Kid du 02.06.11 : la neutralité du net
Nodo centro occidente región
Redes sociales
Perspectivas 2011-2012_Inteligencia de Negocios Atalaya
Sevilla se mueve
Publicité

Similaire à 2010 02 09 Ms Tech Days Owasp Asvs Sgi V01 (20)

PPTX
Secure Software Development Life Cycle (SSDLC)
PDF
2010 - Intégration de l'authentification: les mesures proposées par OWASP
PDF
Geneva Application Security Forum: Vers une authentification plus forte dans ...
PDF
2014 09-25-club-27001 iso 27034-presentation-v2.2
PDF
Développement sécurisé
PPTX
Durcissement de code - Sécurité Applicative Web
PDF
ISO 27034 ISO 27034 ISO 27034 ISOo 27034
PPTX
Valdes securite des application - barcamp2012
PDF
OWASP TOP 10 Proactive
PDF
Sécurité des Applications WEB -LEVEL1
PDF
TECHCARE GROUP
PDF
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
PDF
Deploiement du pare feu checkpoint gaia r77
PDF
Les principales failles de sécurité des applications web actuelles
PDF
IKare Vulnerability Scanner - Datasheet FR
PPTX
Les principales failles de sécurité des applications Web actuelles
PPTX
Test d’intrusion dans le cadre du cycle de développement (Vumetric)
PDF
2014 11-06-sonarqube-asfws-141110031042-conversion-gate01
PDF
Analyser la sécurité de son code source avec SonarSource
PDF
SonarQube et la Sécurité
Secure Software Development Life Cycle (SSDLC)
2010 - Intégration de l'authentification: les mesures proposées par OWASP
Geneva Application Security Forum: Vers une authentification plus forte dans ...
2014 09-25-club-27001 iso 27034-presentation-v2.2
Développement sécurisé
Durcissement de code - Sécurité Applicative Web
ISO 27034 ISO 27034 ISO 27034 ISOo 27034
Valdes securite des application - barcamp2012
OWASP TOP 10 Proactive
Sécurité des Applications WEB -LEVEL1
TECHCARE GROUP
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
Deploiement du pare feu checkpoint gaia r77
Les principales failles de sécurité des applications web actuelles
IKare Vulnerability Scanner - Datasheet FR
Les principales failles de sécurité des applications Web actuelles
Test d’intrusion dans le cadre du cycle de développement (Vumetric)
2014 11-06-sonarqube-asfws-141110031042-conversion-gate01
Analyser la sécurité de son code source avec SonarSource
SonarQube et la Sécurité

Plus de Sébastien GIORIA (20)

PPTX
OWASP Top10 IoT - CLUSIR Infornord Décembre 2014
PDF
2014 09-04-pj
PPTX
Owasp top 10 2010 Resist toulouse
PPTX
Présentation Top10 CEGID Lyon
PDF
Présentation au CRI-Ouest
PDF
2013 06-27-securecoding-en - jug pch
PDF
OWASP Top10 2013 - Présentation aux RSSIA 2013
PDF
OWASP, the life and the universe
PDF
2013 04-04-html5-security-v2
PDF
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)
PDF
2013 03-01 automatiser les tests sécurité
PDF
2013 02-27-owasp top10 javascript
PDF
Secure Coding for Java
PDF
2012 11-07-owasp mobile top10 v01
PDF
2012 07-05-spn-sgi-v1-lite
PDF
2012 03-02-sdl-sgi-v03
PDF
2012 03-01-ror security v01
KEY
OWASP Mobile Top10 - Les 10 risques sur les mobiles
PDF
2011 02-07-html5-security-v1
PDF
2011 03-09-cloud sgi
OWASP Top10 IoT - CLUSIR Infornord Décembre 2014
2014 09-04-pj
Owasp top 10 2010 Resist toulouse
Présentation Top10 CEGID Lyon
Présentation au CRI-Ouest
2013 06-27-securecoding-en - jug pch
OWASP Top10 2013 - Présentation aux RSSIA 2013
OWASP, the life and the universe
2013 04-04-html5-security-v2
2013 02-12-owasp top10 mobile - attaques et solutions sur windows phone (sec309)
2013 03-01 automatiser les tests sécurité
2013 02-27-owasp top10 javascript
Secure Coding for Java
2012 11-07-owasp mobile top10 v01
2012 07-05-spn-sgi-v1-lite
2012 03-02-sdl-sgi-v03
2012 03-01-ror security v01
OWASP Mobile Top10 - Les 10 risques sur les mobiles
2011 02-07-html5-security-v1
2011 03-09-cloud sgi

2010 02 09 Ms Tech Days Owasp Asvs Sgi V01

  • 1. OWASP Application Security Verification Standard 2009 Microsoft TechDays 8 Février 2010 Paris Palais des congrès Sébastien Gioria (French Chapter Leader & OWASP Global Education Comittee Member) [email_address]
  • 2. Sébastien Gioria Plus de 12ans en Sécurité des Systèmes d’Informations. Leader du chapitre Français de l’OWASP && Membre du comité d’éducation mondial. Consultant sénior en sécurité des systèmes d’informations. Président du club Régional de la SSI de Poitou-Charentes (affilié au CLUSIF). Expériences professionnelles : Directeur Technique Hébergement et RSSI d’un opérateur télécoms mondial. RSSI Adjoint d’une Banque Nationale Française. RSSI Adjoint au sein d’une Assurance Française. Domaines de prédilection : Web 0.9 à Web 4.2, WebServices
  • 3. L’OWASP (Open Web Application Security Project) Indépendant des fournisseurs et des gouvernements. Objectif principal : produire des outils, documents et standards dédiés à la sécurité applicative. Tous les documents, standards, outils sont fournis sur la base du modèle open-source. Organisation : Réunion d’experts indépendants en sécurité informatique Communauté mondiale (plus de 100 chapitres) réunie en une fondation américaine pour supporter son action. L’adhésion est gratuite et ouverte à tous En France : une Association. Le point d’entrée est le wiki http://www.owasp.org
  • 4. Les ressources de l’OWASP Un Wiki, des Ouvrages, un Podcast, des Vidéos, des conférences, une Communauté active .
  • 5. Les publications Toutes les publications sont disponibles sur le site de l’OWASP: http://www.owasp.org L’ensemble des documents est régi par la licence GFDL (GNU Free Documentation License) Les publications majeures : Le TOP 10 des vulnérabilités applicatives Le Guide de l’auditeur/du testeur Le Code Review Guide Le guide de conception d’applications Web sécurisées L’Application Security Verification Standard (ASVS) La FAQ de l’insécurité des Applications Web Building Guide Code Review Guide Testing Guide Application Security Desk Reference (ASDR) Le Top 10 fait référence à tous ces guides
  • 6. Type d’attaques applicatives Source : Rapport Cenzic – 1 er semestre 2009
  • 7. Faiblesse des Applications Web Etude du GARTNER 2003 75% des attaques ciblent le niveau Applicatif 66% des applications web sont vulnérables Application Web Eléments Réseaux 75 % 90 % 25 % 10 % % Attaques % Dépenses Etude du SANS (septembre 2009) http://www.sans.org/top-cyber-security-risks/
  • 8. L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
  • 9. Philosophie de l'ASVS Il se veut un standard pour vérifier la sécurité des applications Web. Il se veut indépendant des applications/framework Il se veut indépendant des cycles de développement Il définit les éléments nécessaires à appliquer à une application sans avoir à interpréter celui ci. Points importants : Il définit plusieurs niveaux de vérification de la sécurité Les différences entre les niveaux et l’étendue de la couverture doit être linéaire Les éléments fonctionnels à vérifier doivent utiliser une approche de type liste blanche Il doit être indépendant des outils et des techniques de vérification !!!!
  • 10. Quelles réponses apporte l'ASVS Quelles sont les fonctionnalités à mettre en oeuvre dans les contrôles de sécurité nécessaires à mon application Quelle est la couverture et le niveau de rigueur à mettre en oeuvre lors de la vérification de sécurité d'une application Web. Comment comparer les différentes vérifications de sécurité effectuées Quel niveau de confiance puis-je avoir dans une application Web
  • 11. L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
  • 12. Que sont les niveaux de vérification de l'ASVS
  • 13. Techniques de vérification de la sécurité applicative Découverte des vulnérabilités dans l’application en ligne Découverte des vulnérabilités dans le code source Approche Globale Utilisation d’outils automatisés Revue de code statique automatisée Pentest Manuel Revue de code Manuel
  • 14. Définition des niveaux Level 1 – Vérification automatisée (vérification partielle de l'application) Level 1A –Scan dynamique Level 1B – Scan du code source Level 2 – Vérification manuelle (vérification partielle de l'application) Level 2A – Test d'intrusion Level 2B – Revue de code Level 3 – Vérification de la conception Level 4 – Vérification des fonctions internes
  • 15. Level 1 en détail Vérification automatisée d'une application vue comme un groupe de composants et une seule application monolithique
  • 16. Level 1 Options Level 1A Scan partiel de manière dynamique (aka ClikaWarrior) Level 1B Scan partiel du code source (aka GrepWarrior) Les 2 sont nécessaires pour obtenir un niveau 1 complet
  • 17. Au mieux un outil voit 45 % des failles Une étude de MITRE a démontré que les outils de tests applicatifs des éditeurs ont découverts 45% des vunérabilités Ils ont découvert peut d'overlap entre les outils, il est donc nécessaire de les avoir tous pour avoir 45% de couverture.
  • 18. Niveau 2 en détail Vérification manuelle d'une application organisée en niveaux d'architecture
  • 19. Level 2 Options Level 2A Pentests manuels (aka BurpSuiteWarrior) Level 2B Revue de code manuelle (aka EoinWarrior) Il n’est pas nécessaire d’effectuer des scans automatisés pour atteindre ces niveaux !! Les 2 sont nécessaires pour obtenir un niveau 2 complet.
  • 20. Level 3 en détail Level 2 + Modèlisation des menaces pour vérifier la conception
  • 21. Level 4 en détail Revue interne de l'application à la recherche de code malveillants (pas de virus/malware uniquement) et examination des fonctionnements des contrôles de sécurité
  • 22. Que sont les exigences de vérification de l'ASVS Exigences d'architecture Exigences de vérification de la sécurité Liste d'éléments détaillée par niveau
  • 23. Une approche positive ! Negative Rechercher les failles XSS…. Positive Vérifier que toutes les données disposent d'un échappement propre des entrées fournies. See: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
  • 24. Quels sont les exigences de rapport de l'ASVS R1 –Introduction R2 – Description de l'application R3 – Approche architecture R4 – Résultats de la vérification
  • 25. L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
  • 26. Par ou commencer L'acheteur et le vendeur se mettent d'accord sur les exigences de sécurité qui seront vérifiées en spécifiant le niveau ASVS Vérification initiale de l"application
  • 27. Et ensuite…. Développe et executer une stratégie de correction… Re-vérifier que les différents fixes sont la Mettre en place une stratégie permettant d'ajouter les vérfications dans le cycle de développement.
  • 28. Integrating ASVS into your SDLC (Outsourcing not required)
  • 29. Les 14 familles d’exigences V1. Architecture de sécurité V2. Authentification V3. Gestion de Sessions V4. Contrôle d'accès V5. Validations d'entrées V6. Encodage et échappement de sorties V7. Cryptographie V8. Gestion des erreurs et de la journalisation V9. Protection des données V10. Sécurité des communications V11. HTTP Sécurisé V12. Configuration de la sécurité V13. Recherche de codes malicieux V14. Sécurité interne
  • 30. Plus d'infos La page du projet http://www.owasp.org/index.php/ASVS
  • 31. Plus d'infos Le PDF du document est disponible sur la page du projet http://www.owasp.org/index.php/ASVS La liste de diffusion est disponible pour toutes questions : Voir le lien “ Mailing List/Subscribe" Tip: Subscribe a la liste en 1 clic : [email_address]
  • 32. L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
  • 33. Les 14 familles d’exigences V1. Architecture de sécurité V2. Authentification V3. Gestion de Sessions V4. Contrôle d'accès V5. Validations d'entrées V6. Encodage et échappement de sorties V7. Cryptographie V8. Gestion des erreurs et de la journalisation V9. Protection des données V10. Sécurité des communications V11. HTTP Sécurisé V12. Configuration de la sécurité V13. Recherche de codes malicieux V14. Sécurité interne
  • 34. Architecture de sécurité Il s’agit principalement d’exigences de documentation de l’architecture : Exemples : Exigence L1 L2 L3 L4 Vérifier que tous les composants de l'application sont identifiés (aussi bien les composants individuels que les groupes de fichiers sources, bibliothèques de fonctions, et/ou fichiers exécutables. ✔ ✔ ✔ ✔ Vérifier que tous les composants qui ne font pas partie de l'application, mais dont l'application dépend pour fonctionner, soient correctement identifiés. ✔ ✔ ✔ Vérifier qu'une architecture de haut niveau a bien été définie pour l'application ✔ ✔ ✔
  • 35. Authentification Il s’agit de vérifier l’ensemble des mécanismes permettant de s’assurer que l’utilisateur est le bon. Exigence L1 L2 L3 L4 Vérifier que toutes les pages et ressources exigent bien une authentification excepté celles qui sont spécialement prévues pour être public. ✔ ✔ ✔ ✔ Vérifier que tous les contrôles d'authentification ont une implémentation centralisée (les contrôles incluent les bibliothèques qui font appel des services d'authentification externes). ✔ ✔ ✔ Vérifier que tous les certificats d'authentification servant à accéder des services externes à l'application soient cryptés et stockés dans un endroit protégé (pas dans le code source). ✔ ✔ ✔
  • 36. Gestion des sessions Vérification que le mécanisme des sessions est suffisamment surs L’authentification doit être simple, centralisée et standardisée Utiliser le mécanisme standard de gestion des cookies du framework (ils sont globalement fiables) Utiliser constamment SSL pour protéger les identifiants de connexion et de sessions Exigence L1 L2 L3 L4 Vérifier que l'implémentation du contrôle de gestion des sessions par défaut du framework est utilisé par l'application. ✔ ✔ ✔ ✔ Vérifier que les jetons de session d'authentification soient suffisamment long et aléatoires pour résister aux menaces typiques de l'environnement déployée. ✔ ✔ Vérifier que les cookies qui contiennent les jetons/ids de session d'authentification ont leurs domaine et chemin définit sur une valeur suffisamment restrictive pour ce site. ✔ ✔
  • 37. Contrôle d’accès S’assurer que les accès aux fonctions et données sont limitées aux seuls utilisateurs autorisés. Exigence L1 L2 L3 L4 Vérifier que les utilisateurs ne puissent accéder qu'aux URLs pour lesquelles ils possèdent des autorisations spécifiques. ✔ ✔ ✔ ✔ Vérifier que les contrôles d'accès échouent de manière sécurisée. ✔ ✔ Vérifier que toutes les décisions de contrôles d'accès ainsi que toutesgestion d'erreur soient journalisées. ✔ ✔
  • 38. Validation des entrées S’assurer que les données entrantes dans l’application sont « propres » Utiliser les filtres de type Anti-XSS Initialiser les chaînes pour éviter les débordements de tampon. Exigence L1 L2 L3 L4 Vérifier que l'environnement d'exécution n'est pas sujet aux débordements de tampon, ou que les contrôles de sécurité préviennent les débordements de tampons. ✔ ✔ ✔ ✔ Vérifier que tous les échecs de validation des entrées soient journalisés. ✔ ✔ ✔ Vérifier que chaque entrée de données soient conforme en aval pour tous les décodeurs ou interpréteurs préalablement à la validation. ✔ ✔
  • 39. Encodage et échappement de sortie S’assurer que les données sortantes ne renvoie pas de données « sales » : Utilisation de l’OWASP ESAPI Exigence L1 L2 L3 L4 Vérifier que toutes les données non fiables qui doivent sortir sous forme de HTML (incluant HTML éléments, HTML attributs, données Javascript, blocks CSS, et attributs d'URLs) soient correctement échappés en fonction du contexte. ✔ ✔ ✔ ✔ Vérifier que toutes les données non sûres qui sont inclut dans descommandes de système d'exploitation soient correctement échappées. ✔ ✔ ✔ Vérifier que pour chaque type de sortie encodée/échappée exécutée par l'application, il n'y ait qu'un seul contrôle de sécurité pour ce type de sortie pour la destination prévue. ✔ ✔
  • 40. Vérification cryptographique S’assurer que chiffrements sont surs : Pas d’utilisation de DES, Rot13…. Exigence L1 L2 L3 L4 Vérifier que toutes les fonctions cryptographiques utilisées dans l'application soient implémentées coté serveur. ✔ ✔ ✔ Vérifier que tous les nombres aléatoires, noms de fichiers aléatoires, GUIDs aléatoires, et chaines de caractères aléatoires soient générés par un module cryptographique, dont le générateur de nombres aléatoire soit approuvé, et dont les valeurs aléatoires ne puissent être prévues par un attaquant. ✔ ✔ ✔ Vérifier que les modules cryptographiques utilisés par l'application soient validées par le standard FIPS 140-2 ou un standard équivalent. (voir http://csrc.nist.gov/groups/STM/cmvp/validation.html). ✔ ✔
  • 41. Gestion des erreurs et de journalisation S’assurer qu’il n’y a pas d’envoi de données sensibles à l’utilisateur. Exigence L1 L2 L3 L4 Vérifier que l'application n'envoie pas sur la sortie des messages d'erreurs ou des traces de pile contenant des informations sensibles qui pourraient aider un attaquant, incluant les ids de session et les informations personnelles. ✔ ✔ ✔ Vérifier que les contrôles de sécurité de connexion permettent dejournaliser les succès ET échec d'évènements qui sont identifiés comme liés à la sécurité. ✔ ✔ ✔ Vérifier que l'application ne journalise pas des donnée sensibles spécifiques à l'application qui pourraient aider un attaquant, incluant les ids de session utilisateur et les informations personnelle ou sensible. ✔ ✔ ✔
  • 42. Protection des données S’assurer que les données soient protégées vis a vis des règles métiers et légales. Exigence L1 L2 L3 L4 Vérifier que tous les formulaires contenant des informations sensibles ont désactivé les caches coté client, incluant les fonctionnalités d'auto- complétion. ✔ ✔ ✔ ✔ Vérifier que tous les caches ou copies temporaires de données sensibles stockées sur le serveur soient protégées d'accès non autorisés ou purgées/invalidées après que l'utilisateur autorisé ait accédé à ces données. ✔ ✔ ✔ Vérifier qu'il y a une méthode pour supprimer chaque type de données sensibles de l'application à la fin de la période de rétention requise. ✔ ✔
  • 43. Vérification des communications sécurisées S’assurer qu’il n’y a pas de transmission de données sensibles sur des canaux en clair (HTTP). Exigence L1 L2 L3 L4 Vérifier qu'un chemin peut être créé depuis chaque CA de confiance vers chaque certificat de serveur TLS (Transport Layer Security), et que chaque certificat de serveur est valide. ✔ ✔ ✔ ✔ Vérifier que toutes les connexions à un système externe qui impliquent des informations ou des fonctionnalités sensibles utilisent un compte qui soit réglé pour avoir le minimum de privilèges nécessaire à l'application pour fonctionner correctement. ✔ ✔ ✔ Vérifier qu'un encodage de caractères spécifique est définit pour toutes les connexions (par ex. UTF-8) ✔ ✔
  • 44. Vérifications de sécurité HTTP S’assurer que les éléments transitant dans HTTP sont au maximum de leur sécurité Exigence L1 L2 L3 L4 Vérifier que les redirections n'incluent pas de données non validées ✔ ✔ ✔ ✔ Vérifier que les entêtes HTTP ne contiennent que des caractères imprimables ASCII dans les requêtes et réponses. ✔ ✔ ✔ Vérifier que l'application génère un jeton aléatoire solide comme partie de tout lien ou formulaire associé à une transaction ou accédant à des données sensibles. Vérifier que l'application vérifie la présence du jeton contenu une valeur valide pour l'utilisateur courant lorsqu'il traite ces requêtes. ✔ ✔
  • 45. Vérification de la configuration de la sécurité S’assurer que toutes les informations de configuration sont stockées de manière sécurisée Exigence L1 L2 L3 L4 Vérifier que toutes les informations de configurations liées à la sécurité sont stockées dans un endroit protégé des accès non-autorisés. ✔ ✔ ✔ Vérifier que tout changement dans la configuration de la sécurité gérée par l'application soit journalisé dans les journaux d'évènements de sécurité. ✔ ✔ Vérifier que le stockage de la configuration peut être ouvert dans un format lisible par un humain pour faciliter l'audit. ✔
  • 46. Principes de développement KISS : Keep it Short and Simple 8 étapes clés : Validation des entrées Validation des sorties Gestion des erreurs Authentification ET Autorisation Gestion des Sessions Sécurisation des communications Sécurisation du stockage Accès Sécurisé aux ressources
  • 47. KISS : Keep it Short and Simple Suivre constamment les règles précédentes Ne pas « tenter » de mettre en place des parades aux attaques Développer sécurisé ne veut pas dire prévenir la nouvelle vulnérabilité du jour Construire sa sécurité dans le code au fur et a mesure et ne pas s’en remettre aux éléments d’infrastructures ni au dernier moment.
  • 48. L'ASVS Détails Techniques Comment s'y prendre Les différentes exigences Questions Agenda The OWASP Foundation http://www.owasp.org
  • 49. Pas de recette Miracle Mettre en place un cycle de développement sécurisé ! Auditer et Tester son code ! Vérifier le fonctionnement de son Application ! La sécurité est d’abord et avant tout affaire de bon sens.
  • 50. Rejoignez nous ! http://www.owasp.fr

Notes de l'éditeur

  • #14: You have a number of options when verifying the security of an application. The standard gives you the flexibility to use any and all of these options in your verification effort.
  • #16: Niveau 1 (“Vérification automatique”) est généralement approprié pour des applications ou un usage convenable des contrôles de sécurité est requis. Les menaces de sécurité9 seront généralement des virus, worms, (les cibles sont choisies au hasard à travers de larges scan, et impactent les plus vulnérables). La portée des vérifications inclus le code qui a été développé ou modifié durant la création de l'application. Dans le niveau 1, la vérification implique l'utilisation d'outils automatisés ainsi que des vérifications manuelles. Ce niveau assure seulement une protection de sécurité partielle de l'application. La vérification manuelle n'est pas prévue pour rendre la sécurité de l'application complète, seulement pour vérifier que chaque découverte automatique est correcte et pas simplement une fausse alerte (false positive). Il y a deux éléments constituants le niveau 1. Le niveau 1A utilise des outils pour scanner automatiquement les vulnérabilités de l'application (analyse dynamique), et le niveau 1B utilise des outils pour scanner automatiquement le code source (analyse statique). Les efforts de vérification peuvent utiliser chacun de ces composants individuellement, ou utiliser une combinaison de ces approches pour obtenir le niveau 1 complet. La structure de ces niveaux est décrite dans la figure ci-dessous. Tandis qu'il peut déterminé qu'une application accède au niveau 1A ou 1B, aucun de ces niveaux pris séparément ne procure le même niveau de rigueur et de protection qu'une application qui accède au niveau 1. Une application qui est de niveau 1, doit être de niveaux d'exigences 1A et 1B. Whichever tool or tools you use must provide coverage against all the requirements in the standard. Covering a requirement simply means that the tool provides some benefit in that area. Not that it necessarily finds ALL flaws in that area. For example, if the tool can find some XSS flaws, that it is considered to cover that area at Level 1, even though it can’t find all XSS flaws in a particular application. If there is a level 1 (A or B) requirement that your selected tool suite doesn’t cover, then you can augment your verification process with manual verification to address that particular requirement.
  • #17: Whichever tool or tools you use must provide coverage against all the requirements in the standard. Covering a requirement simply means that the tool provides some benefit in that area. Not that it necessarily finds ALL flaws in that area. For example, if the tool can find some XSS flaws, that it is considered to cover that area at Level 1, even though it can’t find all XSS flaws in a particular application. If there is a level 1 (A or B) requirement that your selected tool suite doesn’t cover, then you can augment your verification process with manual verification to address that particular requirement.
  • #18: Note: Clearly a level 1 review can’t do any more than what the tools can do, since it’s a tool based review. Given that tools don’t yet provide a huge amount of coverage of the application security problem space, level 1 reviews are understandable limited in their scope. But they are just the first level in the model. Higher levels provide better coverage and more rigor, as defined by the standard itself.
  • #19: Le niveau 2 (« Vérification manuelle ») est approprié pour des applications qui gèrent des transactions personnelles, des transactions B2B (business to business), des informations de cartes de crédit, ou des informations personnelles. Le niveau 2 procure une assurance que les vérifications des contrôles de sécurité se font conformément aux spécifications et qu'ils fonctionnent correctement. Les menaces seront les virus, vers, et des opportunistes simple qui utilisent des outils d'attaque préconçus. L'étendue des vérifications inclut tous les codes développés ou modifiés pour l'application, aussi bien que l'examen des tierces parties qui procure des fonctionnalités de sécurité à l'application. Il y a deux composants pour le niveau 2, comme décrit sur la figure ci-dessous. Si une application peut accéder au niveau 2A ou 2B, aucun de ces niveaux seul n'apporte la même rigueur ni le même niveau de protection que le niveau 2.D'autre part, alors que le niveau 2 englobe le niveau 1, il n'y a pas d'exigences d'utilisation d'outils automatisés pour accéder au niveau 2. Au lieu de cela, le vérificateur a l'option d'utiliser seulement des techniques manuelles pour répondre aux exigences du niveau 2. Si des outils automatisés sont disponibles, le vérificateur peut les utiliser pour appuyer son analyse. Cependant, répondre à une exigence de niveau 1, ne signifie pas systématiquement que l'on répond à la même exigence de niveau 2, et ce parce que les outils automatiques n'apportent pas de preuves suffisamment solides, pour affirmer que l'exigence de niveau 2 a été satisfaite.
  • #20: Manual verification can also leverage the use of automated tools, but it doesn’t have to. Manual verification WILL involve the use of tools. It will be crazy not to. However, the level of ‘automation’ of such tools is up to the verifier. It could range from the simple use of an IDE, to automated commercial tools like what might be used at level 1, to custom code review tools that have custom rules built and maintained by the verifier that are not commercially available.
  • #21: Level 3, is Level 2 plus more coverage and more depth of analysis. It also include high level threat modeling and design verification, to verify that all the critical assets are protected by the proper set of security controls.
  • #37: // Create a new cookie HttpCookie cookie = new HttpCookie("MyKey", "MyValue"); // Set the expirtation on the cookie cookie.Expires = DateTime.Now.AddHours(1.0);// Enable transmission of the cookie over HTTPS cookie.Secure = true;// Enable HttpOnly cookie.HttpOnly = true;// Add the cookie to the Response stream Response.Cookies.Add(cookie);