La sécurité applicative

1. La Sécurité Applicative
Mise en œuvre chez GDF SUEZ
Club Qualimétrie du 23/09/2008
Marina Retbi

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 -
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 -
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 -
Sécurité applicative : les couches visées
Couche
applicative
Infrastructure
Sécurité Applicative

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 -
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 -
Le Cross-Site Scripting ou XSS - Exemple XSS volatile
Sécurité Applicative

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 -
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 -
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 -
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. 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. 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 -
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. 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. 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 -
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. 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. 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 -
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 -
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. 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 -
AppSan : Capture d’écran
Sécurité Applicative

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. 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. 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. Exemple réel : Cross Site Scripting
- 28 -
Sécurité Applicative
Apparition d’une pop-up
alerte,
initialement non
programmée dans
l’application

29. Exemple réel : Modification d’interface
- 29 -
Sécurité Applicative

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. 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. 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. 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. Annexe
- 34 -
Sécurité Applicative

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. 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. 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.