Audit technique et analyse de code 9 juillet 2008

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

Introduction 23 mai 2008

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

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

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

Revue d’architecture 23 mai 2008

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

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

Revue de code 23 mai 2008

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

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

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

Maintenabilité de l’application

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

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

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

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

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

Préconisations et macro chiffrage 23 mai 2008

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

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

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

Conclusion 23 mai 2008

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

questions? Audit technique GIBII