Audit technique et analyse de code

Présentation au sujet: "Audit technique et analyse de code"— Transcription de la présentation:

1 Audit technique et analyse de code
9 juillet 2008

2 Ordre du jour Introduction Revue d’architecture Revue de code
Diagnostic sur la maintenabilité de l’application Diagnostic sur la sécurité applicative Alignements aux critères DICP Alignements au top ten OWASP Conclusion Audit technique GIBII

3 Introduction 23 mai 2008

4 Contexte Dans le cadre de la certification B2I (Brevet Informatique et Internet), l’Education Nationale dispose de GIBII (Gestion Informatique du Brevet Informatique et Internet) largement répandue dans diverses académies, afin de répondre à un besoin de suivi de la certification. Avant d’élargir le champ d’utilisation de GIBII, le SERIA souhaite réaliser une validation des travaux entamés sous le volet de la maintenabilité et de la sécurité applicative. L’objectif de la prestation est de déterminer, si GIBII : Est conforme aux attentes de l’Education Nationale, N’est pas conforme aux attentes, mais peut être corrigé. N’est pas conforme aux attentes, et nécessite une refonte complète. Audit technique GIBII

5 Méthodologie d’intervention
Documentation projet, Code source Lot 2 Audit de code SERIA Interviews Q/R Phase 0 Prise de connaissances Rapport Revue d’architecture Phase 1 Revue d’architecture Rapport Revue de code Phase 2 Revue de code Rédaction rapport Architecture technique/applicative Code Phase 3 Intégration ClearTrust Synthèse managériale Phase 4 Macro chiffrage / synthèse Support de présentation Audit technique GIBII

6 Analyse documentaire Documentation fournie :
Documentation pour la présentation de GIBII (skin), Documentation administrateurs et utilisateurs finaux, Documentation pour super-administrateurs, Documentation annexe (SSO, pacth, etc.) Documentation « fonctionnelle » et « manuel d’utilisations » du projet très complète. Pas de documentation technique. Audit technique GIBII

7 Revue d’architecture 23 mai 2008

8 Revue d’architecture Protocoles
HTTP(S) Aucune connexion à des services tiers Approche purement procédurale dans la conception. Une architecture simple (mono couche), Redondance de code, (usage des fonctions limité) Pas de séparation entre présentation / traitement Dimensionnement, environ 250 scripts PHP. Audit technique GIBII

9 Périmètre de la revue de code
Revue de code orientée sécurité applicative Vérifier les mécanismes suivants: Contrôle d’accès Authentification Identification Autorisation Contrôle des flux Gestion des logs Gestion d’erreur Qualité du code Protection des données Audit technique GIBII

10 Revue de code 23 mai 2008

11 Rappel des remarques détectées 1/2
Contexte / Point de contrôle Remarque Gravité Code Client Le code Javascript est peu structuré dans les bibliothèques. Méthodes de chiffrement exposées côté client. (Divulgation d’informations) Inutile si SSL Authentification Messages trop explicites en cas d’échec d’authentification Il n’existe pas de mécanisme de blocage lors de multiples tentatives infructueuses . Identification Le processus d’identification n’est pas centralisé. Certaines fonctionnalités d’identification, se basent sur des paramètres d’URL. Habilitation La fonctionnalité se base également sur des valeurs d’URL, Audit technique GIBII

12 Rappel des remarques détectées 2/2
Contexte / Point de contrôle Remarque Gravité Protection des données Mots de passe stockés et non chiffrés Date de naissance pour mot de passe (syntaxe trop simple) Inspection des flux Globaliser les variables issues de paramètres d’URL et de la session est un vecteur d’attaque. Pas de couche d’accès aux données (ou librairies). Fonctions d’échappement ne sont pas systématiquement utilisées avant chaque requête SQL Pas de contrôles des flux coté serveur (ou d’encodage et de canonisation). Qualité du code - Pas de règles ou de normes de programmation en vigueur. - Code peu factorisé. Maintenance difficile. Gestion des traces - Il n’existe pas de mécanisme de gestion des traces fonctionnelles. - Il n’existe pas de mécanisme de gestion des traces applicatives. Audit technique GIBII

13 Rappel des bonnes pratiques identifiées
Contexte / Point de contrôle Remarque Cookies Ne stockent pas de données sensibles Protection des données - La modification du mot de passe lors de sa première connexion - SSL utilisé pour le transfert des mots de passe Gestion de session - Processus de gestion de session PHP - Différents contrôles ont été ajoutés afin de valider l’accès à l’application et d’empêcher le détournement de session. (User-agent chiffré en sha1 + adresse IP) - Stockages des informations utiles en session Blocage des ressources L’accès aux ressources n’est autorisé que si la session est validée. Habilitation Un contrôle d’habilitation est implémenté et utilisé pour toutes les pages du site. Gestion des traces Des traces de sécurité sont stockées en base de données Audit technique GIBII

14 Maintenabilité de l’application

15 Maintenabilité de l’application
Bibliothèques et fonctions peu utilisées. Code peu factorisé. Plusieurs logiques métier Requêtes SQL codées dans les pages Web Présentation et accès aux données dans une unique couche Pas de centralisation du code Des évolutions majeures sembles difficiles à mettre en œuvre : Charges conséquentes en développement, Risques de régression Audit technique GIBII

16 Alignements de la sécurité applicative (DICP, OWASP)
23 mai 2008

17 Alignements selon les critères DICP
Commentaire Niveau de Garantie Disponibilité Pas d’informations sur les infrastructures. Risques de déni de service. Intégrité Risques d’injection SQL. Confidentialité - Pas de protection contre XSS, - Mdp stocké en clair dans la base de données, - Pas de mécanisme de blocage des authentifications infructueuses, - Messages trop explicites en cas d’un échec d’authentification. Preuve Gestion des preuves non suffisante. Audit technique GIBII

18 Alignements selon les critères OWASP 1/2
Vulnérabilité OWASP Commentaire Niveau de Garantie Cross site Scripting (XSS) Pas de contrôle des flux. Injection de commandes Exécution de fichiers malicieux 3 fonctions sensibles : Fopen() Move_Uploaded_File() UnLink() Référence directe d’objets non sécurisés GIBII fait référence à des paramètres d’URL pour accéder à certains objets sécurisés. Audit technique GIBII

19 Alignements selon les critères OWASP 2/2
Vulnérabilité OWASP Commentaire Niveau de Garantie Cross Site Request Forgery (CSRF) Pas de contrôle des flux. Mauvaise gestion des erreurs Pas de divulgation d’informations. Stockage non sécurisé Mot de passe stocké en clair. Communication non sécurisée SSL utilisé (selon informations recueillies) Violation de contrôle d’accès N/A. Audit technique GIBII

20 Préconisations et macro chiffrage
23 mai 2008

21 Préconisations - solution 1
Mécanisme d’authentification (>10J) Revoir la gestion du mot de passe . Mettre en place un moyen limitant le nombre de tentatives d’authentification. Utiliser un seul message d’erreur. Identification (?) Centraliser le processus d’identification dans une classe ou méthode unique Contrôle d’accès – Habilitation - Gestion de session (20J) Dissocier la gestion de session, du contrôle d’accès et de l’habilitation. Ne pas se baser sur les paramètres d’URL Refonte de l’habilitation (appels de la fonction opensession() ) Audit technique GIBII

22 Préconisations - solution 1
Inspection des flux (?) Contrôles de saisie coté serveur (Javascript => PHP) . Ne pas globaliser les variables de session. Contrôler toutes les saisies utilisateur Contrôle métier (longueur, syntaxe, etc.) Protection SQL injection et XSS Gestion des traces et des erreurs (7j) Utiliser un framework de log et tracer les actions utilisateur. Le macro chiffrage estime le correctif à une charge supérieure à 100 jours Audit technique GIBII

23 Préconisations - solution alternative
Principe 1 seul mode de connexion : AM CleartTrust Identification / Authentification / contrôle d’accès, assurés par l’outil. Habilitation de GIBII (contrôle d’accès aux URL en fonction du profil) Installation d’un filtre applicatif sur le serveur frontal comme mod_security Inspection des flux SQL Injection et XSS Macro chiffrage (applicatif GIBII) Suppression du mode SSO CAS (1j) Intégration ClearTrust RSA (6j) Installation mod_security (2j) Gestion des traces et des erreurs (7j) Le macro chiffrage estime le correctif à une charge environ à 20 jours Reste le code Javascript => coté serveur Impose un compte LDAP pour chaque élève Audit technique GIBII

24 Conclusion 23 mai 2008

25 Conclusion GIBII a été développé pour un besoin particulier et est une application qui répond parfaitement aux besoins fonctionnels. L’application web est aujourd’hui « victime de son succès » et doit s’aligner aux exigences de l’Education Nationale. La capacité de l’application à évoluer est aujourd’hui limitée Uniquement des évolutions mineures. La sécurité est très perfectible : Un correctif purement applicatif serait trop coûteux Un correctif purement applicatif Charge de développement conséquente Ne corrige que la sécurité => l’application reste difficilement maintenable ! Une refonte complète iso fonctionnelle JEE Entre 200 et 300 jours de développement (soit environ 500 h/j au total) Audit technique GIBII

26 questions? Audit technique GIBII