Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20080923 02 - Securité applicative (GDF-Suez)

95 views

Published on

La sécurité applicative

Published in: Software
  • Be the first to comment

  • Be the first to like this

20080923 02 - Securité applicative (GDF-Suez)

  1. 1. La Sécurité Applicative Mise en œuvre chez GDF SUEZ Club Qualimétrie du 23/09/2008 Marina Retbi
  2. 2. Plan Contexte et Problématique Détails et positionnement de l’offre GDF SUEZ Processus de réalisation Documentation disponible Livrables Délais et charges L’outil utilisé : AppScan Exemple réel - 2 - Sécurité Applicative
  3. 3. - 3 - La Cellule de Qualification Logicielle CQL Qualité du code Performance Sécurité applicative • Respect de l’état de l’art en terme de sécurité • Non-vulnérabilité aux principales attaques • Respect des normes de développement • Aide au pilotage de prestation par la qualité • Conformité des temps de réponse avec les exigences formulées dans le CdC • Évaluation de la robustesse à la charge Juil-07 Opérationnel Avr-07 Industrialisation Statut Étude en cours Fin-08 Fin-08 Sécurité Applicative
  4. 4. - 4 - La sécurité applicative : dangers et impacts Les dangers • Vol et manipulation Des sessions des utilisateurs Des logins et mots de passe associés D’informations confidentielles • Possibilité de provoquer des erreurs internes de l’application Lenteurs Arrêts complets • Modification de contenu du site (« défacement ») • Intrusion sur le réseau interne Les impacts • Atteinte potentielle à l’entreprise et son image • Nuisible au bon fonctionnement du SI • Utilisation du SI à des fins malveillantes • Espionnage industriel • I.C.S Sécurité Applicative
  5. 5. - 5 - Sécurité applicative : les couches visées Couche applicative Infrastructure Sécurité Applicative
  6. 6. - 6 - La sécurité applicative en chiffres Quelques chiffres… • « 75 percent of successful attacks take place at the application layer » Gartner • 85% des sites vulnérables au Cross-Site Scripting 31 000 sites testés étude WhiteHat Les 2 principales menaces rencontrées • Cross-Site Scripting • Injection SQL L’étude 2007 du WASC montre une augmentation des failles type « fuites d’information » • http://www.webappsec.org/projects/statistics/ Sécurité Applicative
  7. 7. - 7 - Le Cross-Site Scripting ou XSS Exécution de script malicieux sur le poste client • N’attaque pas directement l’application mais l’utilisateur Exploite la confiance de l’utilisateur Peut nuire aux deux parties • Vol de session / usurpation d’identité • Prise de contrôle du poste client • Récupération d’informations personnelles • etc. Sécurité Applicative
  8. 8. - 8 - Le Cross-Site Scripting ou XSS - Exemple XSS volatile Sécurité Applicative
  9. 9. - 9 - L’injection SQL Manipulation des paramètres de formulaires ou d’URL • Modification des requêtes SQL de l’application Exécution de ces requêtes sur la base de donnée de l’application • Récupération de données sensibles Login & mot de passe Numéros de cartes bancaires Données extérieures à l’application accessibles avec les mêmes droits applicatifs etc. • Modification, corruption, effacement • Élévation de privilèges • Trojan • Prise de contrôle du système SELECT * FROM SQL Sécurité Applicative
  10. 10. - 10 - L’injection SQL - Exemple 1. Requête SQL d’origine pour l’authentification 2. Manipulation des paramètres • username • password 3. La requête devient SELECT * FROM Users WHERE (username = ‘$username’) AND (pwd = ‘$password’); Paramètres HTTP POST SELECT * FROM Users WHERE (username = ‘’ OR 1=1 ) AND (pwd = ‘’ OR 1=1 ); Sécurité Applicative
  11. 11. - 11 - Références en sécurité applicative OWASP (Open Web Application Security Project) • Style Wikipedia, communauté très active • Nombreux projets, tutoriaux, explications, etc. à surveiller et à utiliser comme source d’info. • http://www.owasp.org WASC • WASC TC (Threat Classification) Classification des failles de sécurité Standard industriel • http://www.webappsec.org/ Sécurité Applicative
  12. 12. - 12 - La sécurité applicative chez Gaz de France Une démarche Groupe de sécurité applicative • Passage d’un fonctionnement projet par projet à une politique globale • Charte de Sécurité opérationnelle • Niveau de sécurité minimum garanti Uniquement pour les projets web Audit obligatoire pour tout nouveau projet web • La mise en production dépend du résultat de l’audit Audit recommandé pour les applications web existantes Audit recommandé après toute évolution majeure Sécurité Applicative
  13. 13. Impact fort sur les projets Résultats de l’audits requis pour le Comité de Validation Technique final • Pour tous les nouveaux projets web • Attribution du drapeau « Niveau minimum de sécurité applicative » Impact sur la décision de la mise en production • Bloquant si présence de failles majeures Mécanisme de dérogation • Etude d’impact requise • Passage en Comité d’architecture SSI 1 audit par an si évolutions majeures au cours de l’année passée - 13 - Sécurité Applicative STOP
  14. 14. Positionnement de l’offre dans le cycle de vie projet Intégration des exigences techniques dans le CCTP Réalisation d’audits - 14 - Offre sécurité applicative Offre sécurité applicative Offre sécurité applicative Offre sécurité applicative Sécurité Applicative arbitrage STOP
  15. 15. - 15 - L’offre Sécurité Applicative Déroulement de l’offre de sécurité applicative Intégration des exigences techniques dans le CCTP de l’A.O. Évaluation* de la maturité des intégrateurs Définition + planification stratégie d’audit Réalisation audit sécurité applicative Remise rapport + élaboration et suivi du plan d’action Sensibilisation des équipes de l’intégrateur** Récupératio n du dossier d’audit rempli par l’intégrateur Au lancement d’un AO Pour tout audit Sécurité Applicative * Questionnaire soumis lors de l’AO ** Documentation + réunion de lancement
  16. 16. Livrables Rapport synthétique • contenant Les types de failles et leur répartition Les risques encourus • Transmis au Comité de Validation Technique final Impact potentiel sur la mise en production Rapport détaillé (à destination de l’équipe projet) contenant • Le détail de toutes failles rencontrées par l’outil • Les préconisations génériques pour les corrections Présentation synthétique des résultats • Inclus des Préconisations / Plan d’actions génériques - 16 - Sécurité Applicative
  17. 17. Documents disponibles pour l’offre de sécurité applicative (1/2) Charte de sécurité applicative Questionnaire de sécurité applicative Guide du développement d’applications web sécurisées Modèle de dossier de sécurité applicative Description de l’offre de sécurité applicative - 17 - Sécurité Applicative ?
  18. 18. - 18 - Charges de réalisation d’un audit sécurité applicative Durée du projet Durée moyenne constatée de l’audit Nb audits intermédiaires recommandés < 2 mois 5 jours n/a < 4 mois 5 jours 1 < 6 mois 7 jours 1 < 1 an 10 jours 3 < 2 ans 20 jours 7 Sécurité Applicative
  19. 19. Outil d’audit automatique utilisé : AppScan Fonctionnalités • Exploration Manuelle Automatique • Tests de sécurité • Base de connaissance Recensement des failles Types de faille Gravité Préconisations pour les corrections Généralités J2EE, PHP, .NET • Génération de rapports d’audit Personnalisables Multiples formats PDF, Word, HTML - 19 - Sécurité Applicative
  20. 20. AppScan : la découverte de l’application (« crawling ») Exploration manuelle • AppScan enregistre la navigation Exploration Automatique ( ~ spider google) • Découverte de liens Exploration en profondeur ou en largeur Supporte le javascript et le flash Enregistrement de l’exploration • les requêtes HTTP • Les URL Les pages Les paramètres - 20 - Sécurité Applicative
  21. 21. - 21 - AppScan : la découverte de l’application (« crawling ») Contraintes et limitations • Paramétrage de l’exploration automatique peut être délicat et prendre du temps Phases de login Détection du logout etc. • Exploration manuelle parfois obligatoire et fastidieuse AJAX Workflows etc. Sécurité Applicative
  22. 22. - 22 - AppScan : Tests / Analyse Lancement des tests de sécurité en manipulant les paramètres • Comparaison des réponses de l’application par rapport fonctionnement normal • Reconnaissance de « patterns » pour les failles • Regroupement des failles découvertes Contraintes • Explosion combinatoire : tests parfois très longs Peut atteindre 24 à 48h, voire plus • Peut planter différentes couches de l’application Serveur Base de donnée etc. Sécurité Applicative
  23. 23. AppScan : Contraintes de l’audit Tests non transparents pour l’application • Potentiellement intrusifs • Modification des données en base Audit potentiellement long fonction du scénario Impact sur les performances • Baisse du niveau de service • Ralentissement / bloquage de l’application • Attention aux serveurs mutualisés Impact sur les autres applications hébergés Tests doivent être réalisés sur une version la plus proche de la production pré-production / recette / formation / etc. - 23 - Sécurité Applicative
  24. 24. - 24 - AppSan : Capture d’écran Sécurité Applicative
  25. 25. Exemple : Le contexte applicatif et de l’audit Fonctionnel • Application de gestion des risques au niveau local et global Technique • Application Java/Oracle • Framework Struts Emplacement de l’analyse • Serveur de recette de l’application Déroulement de l’audit • Prévu 7 jours 2 profils différents avec escalade de privilège 6 scénarios • Réalisé 7.5 jours 1 profil testé 1 scénario 608 URL visitées 187 210 tests effectués - 25 - Sécurité Applicative
  26. 26. Exemple : Synthèse des résultats analysés (1/2) Remontée d’un nombre très important de failles • 24 types de failles différentes remontés par l’outil • 760++ points de vulnérabilité au total Types de faille • Blind SQL injection • Cross-Site Scripting (XSS) • Injection de liens • Erreurs applicatives • etc. Étude des failles les plus critiques • temps limité • Vérifier leur pertinence • Analyser leur sévérité en fonction du contexte - 26 - 8 3 0 critique moyenne recommandation
  27. 27. Synthèse des résultats analysés (2/2) Aperçu des possibles risques encourus • Voir, modifier, détruire la base de données • Voler et manipuler des sessions d’utilisateurs • Provoquer des erreurs internes de l’application lenteurs, arrêts • Voir le contenu de certains fichiers Nombre important de failles ne reflète pas le nombre de corrections à apporter • Méthodologie de correction identique : filtrage centralisé de toutes les données utilisateur • Traiter les corrections de façon unifiée
  28. 28. Exemple réel : Cross Site Scripting - 28 - Sécurité Applicative Apparition d’une pop-up alerte, initialement non programmée dans l’application
  29. 29. Exemple réel : Modification d’interface - 29 - Sécurité Applicative
  30. 30. Exemple réel : Poison Null Byte Files Retrieval - 30 - Sécurité Applicative Récupération du fichier système boot.ini https://www.mon-domaine.com/[…]/Action.do?crud=callHelp&pageId=/../../../../../../../../boot.ini%00.html
  31. 31. Exemples réels : Erreurs Applicatives et injection de lien Insertion d’un lien, initialement non programmé dans l’application Données parlantes pour un attaquant sur la structure de l’application - 31 - Sécurité Applicative
  32. 32. Exemple : Plan d’action Correctif (1/2) Contrôler tous les paramètres d’entrée côté serveur • Ne pas faire confiance aux données extérieures • Contrôles Sur le format attendu Sur la longueur Aux limites Etc. Filtrer tous les paramètres • Requêtes SQL (notamment depuis la page de recherche) • Données de script • Etc. Un conseil : mutualiser le filtrage des paramètres • dans des objets spécifiques. ex: package Validator de Struts • Via un « reverse proxy »
  33. 33. Exemple : Plan d’action MOE (2/2) Envoyer les informations sensibles via la méthode POST plutôt que GET Re-générer l’ID de session une fois l’utilisateur identifié Valider le chemin d’accès aux fichiers • Doivent rester dans le contexte de l’application • Limiter les extensions utilisables • Retirer tout caractère spécial (cf. filtrage de données) Faire une page d’erreur générique • Sans information technique • Que des pages de type HTTP 404 (ressource inexistante)
  34. 34. Annexe - 34 - Sécurité Applicative
  35. 35. Extrait des en-têtes de règles de la Charte Sécurité Applicative (1/3) RSEC-CONC-1 Globalement, la démarche consiste à tout interdire et n’autoriser que certains éléments (au lieu de tout autoriser sauf certains éléments). RSEC-CONC-5 Placer les filtres et expressions régulières en amont des traitements de sorte à centraliser la politique de sécurité. RSEC-CONC-8 Afficher à l’utilisateur uniquement les informations nécessaires. RSEC-CONC-11 Employer des requêtes paramétrées (PreparedStatement) qui échappent automatiquement les données lors de la valorisation de la requête pour limiter l’injection SQL RSEC-DEV-4 Ne pas mettre de données sensibles en paramètres d’URL. RSEC-DEV-10 Contrôler TOUTES les données provenant du navigateur client : en- tête, cookies, formulaires, champs cachés, paramètres d’URL, ainsi que les données provenant de la base de données, d’applications ou de services extérieurs, avant leur traitement applicatif. Toutes ces données sont appelées des données étrangères.
  36. 36. Extrait des en-têtes de règles de la Charte Sécurité Applicative (2/3) RSEC-DEV-11 Refaire TOUS les contrôles côté serveur, même s'ils sont aussi réalisés côté client pour des questions d’efficacité et d’ergonomie. RSEC-DEV-14 Utiliser une charte de nommage pour différencier les variables filtrées et non filtrées, afin de s’assurer que l’on utilise la variable filtrée lors des traitements. RSEC-DEV-17 Tester pour toute chaîne de caractères destinée à être un nom de fichier la non- présence du caractère nul (0) ou d’une de ses représentations encodées (%00 au format URL). RSEC-DEV-19 Échapper les données qui permettent de valoriser une requête SQL lorsqu’elles sont fournies par l’utilisateur, par une application ou un service externe, ou même par des fonctions internes à l’application qui potentiellement manipulent des données initialement fournies par un utilisateur. RSEC-DEV-20 Échapper les caractères spéciaux et encoder au format URL les données provenant initialement d’un utilisateur ou des valeurs obtenues à partir du système d’information, avant de les envoyer à l’utilisateur final. RSEC-DEV-23 Limiter, lorsque c’est possible, la longueur des chaînes de caractères issues de données étrangères (champ de saisie libre dans un formulaire, valeur d’un paramètre transmis dans une URL…).
  37. 37. Extrait des en-têtes de règles de la Charte Sécurité Applicative (3/3) RSEC-DEV-26 Ne pas afficher les messages d’erreurs « internes » à l’application dans le navigateur client. RSEC-DEV-31 Ne pas afficher d’informations critiques inutilement. RSEC-DEV-33 Toujours demander à l’utilisateur de se ré-authentifier avant une action critique. RSEC-DEV-34 Régénérer l’identifiant de session après authentification afin de se protéger de la fixation de session. RSEC-DEV-36 Vérifier que l’utilisateur a le droit d’accéder à une page ou à une ressource (ex : fichier à downloader) avant de lui fournir la ressource RSEC-ENV-1 Installer régulièrement les derniers patchs de sécurité sur les logiciels qui appartiennent à l’environnement d’exécution.

×