Sécurité d'applications PHP - 11 mars 2019

Transcript

1. <animés par la passion> Sécurité d'applications PHP MONTRÉAL | 11 MARS 2019 @afilina
2. Anna Filina ‣ @ZenikaMontreal ‣ Je réusine le code legacy. ‣ J'automatise les tests. ‣ Je corrige la sécurité et la performance. ‣ Je donne des présentations et des ateliers.
3. Plan de cours ‣ Bases de durcissement d'applications. ‣ Injection. ‣ Authentification brisée. ‣ Exposition de données sensibles. ‣ Entités externes XML (XXE). ‣ Contrôle d'accès brisé. ‣ Mauvaise configuration de la sécurité. ‣ Cross-site scripting (XSS). ‣ Désérialisation insécure. ‣ Utilisation de composants avec des vulnérabilités connues. ‣ Journalisation et surveillance insuffisants. ‣ Dépassement de tampon. ‣ Cross-site request forgery (CSRF). ‣ Identification et classification des vulnérabilités. ‣ Modélisation des menaces.
4. Durcissement d'applications
5. Surface d'attaque ‣ La somme de tous les chemins entrants et sortants de l'application. ‣ Le code qui protège ces chemins. ‣ Toutes les données sensibles utilisées dans l'application. ‣ Le code qui protège ces données. ‣ Réduire la surface d'attaque.
6. Réduire la quantité de code exécuté ‣ Passer en revue et simplifier le code. ‣ Réusiner le legacy. ‣ Supprimer le code mort. ‣ Formulaires moins nombreux, plus simples. ‣ Beaucoup de code = grande surface d'attaque.
7. Réduire points d'entrée pour utilisateurs non vérifiés ‣ Mode débogage. ‣ Endpoints d'API. ‣ Accès à la BD ou aux formulaires de connexion admin 
 en dehors du réseau interne. ‣ Fichiers accessibles via le serveur Web.
8. Mauvais /var/www/myproject << vhost target - config - index.php - src Bon /var/www/myproject - config - public << vhost target - src
9. Éliminer les services demandés par peu d'utilisateurs ‣ <5% des utilisateurs s'authentifient auprès de votre AD? ‣ <1% des utilisateurs ont besoin de téléverser des fichiers PDF?
10. Désactiver les fonctionnalités inutilisées ‣ Fermer les ports. ‣ Désinstaller les logiciels inutilisés. ‣ Supprimer les fonctionnalités inutilisées dans le code.
11. Réduire le transit inutile ‣ Envoyer les informations d'identification une seule fois,
 puis utiliser un jeton. ‣ Ne pas envoyer de données inutiles.
12. ILS NE PEUVENT PAS LE VOLER SI VOUS NE LE STOCKEZ PAS
13. Réduire la quantité de données stockées ‣ Stocker moins de données utilisateur. ‣ Supprimer les données dès qu'elles ne servent plus. ‣ Rendre les données stockées inutilisables.
14. Couches de sécurité
15. Vulnérabilités de codage communes
16. Préparation du projet
17. 1: Injection
18. Démo: injection SQL
19. Exercice: injection SQL
21. Vecteurs ‣ Injections stockées. ‣ Requêtes: SQL, LDAP, XPath, NoSQL. ‣ Commandes OS. ‣ En-têtes SMTP. ‣ Langages d'expression (regex). ‣ Analyseurs syntaxique XML.
22. Solutions ‣ Examiner le code: scanneurs, fuzzing, revues de code. ‣ Garder les données non fiables séparées des commandes et des requêtes. ‣ Validation par liste blanche. ‣ Utiliser ORM ou ODM. ‣ Requêtes paramétrées (where user_id = ?) ‣ Filtrer les données fournies par l'utilisateur.
23. Solutions ‣ Requêtes paramétrées: • Assurez-vous qu'un attaquant n'est pas en mesure de changer l'intention d'une requête. • Il suffit d'oublier une fois, alors faites-le systématiquement.
24. 2: Débordement de tampon
28. Vecteurs ‣ Archive TAR. ‣ Image GD. ‣ Données EXIF. ‣ Chaîne de caractères.
29. Impact ‣ Exécuter du code arbitraire. ‣ Corrompre des adresses de mémoire, provoquant un crash. ‣ Exposer des données sensibles.
30. Solutions ‣ Valider les frontières (rejeter ou tronquer). ‣ Mettre à jour les logiciels et les librairies à temps. ‣ Le code écrit en PHP est à l'abri, à moins d’un problème dans PHP ou une extension.
31. 3: Stockage cryptographique inadéquat
32. Mots de passe ‣ Pas de texte en clair. ‣ Pas de hash (empreinte). ‣ À cause des "ranbow tables".
33. Rainbow tables ‣ Créer des permutations. ‣ Calculer le hash et stocker dans la table. ‣ Voler les hash de mots de passe. ‣ Chercher dans la table.
34. Tables MD5 Charset Longueur Volume ascii-32-95 1-7 52 GB ascii-32-95 1-8 460 GB mixalpha-numeric 1-8 127 GB
35. Démo: rainbow table
36. Qu'en est-il des collisions? ‣ Ils n'existent pas pour les chaînes courtes. ‣ Vous n’en aurez pas dans vos tables.
37. Solutions ‣ Saler les hash: • Clé aléatoire supplémentaire (sel) pour le hachage. • Conserver le sel et le hash. • Plus de permutations à essayer pour les attaquants. ‣ Hachage répété.
38. Re-hachage +sel + hachage Hash Mot de passe Hash +sel + hachage x20,000
39. Démo: hachage
40. Exercice: hachage
41. Bcrypt ‣ Fait tout le travail lourd pour vous. ‣ Choisissez le coût, augmentez plus tard. ‣ Toutes les métadonnées stockées dans le hash résultant.
42. Politique de mot de passe ‣ Ne pas limiter le nombre et le type de caractères. ‣ Plus difficile de générer des rainbow table. ‣ Empêche également les attaques par force brute.
43. Questions de sécurité ‣ Connu par un large groupe de personnes. ‣ Vous stockez plus de données privées. ‣ Mêmes questions de sécurité sur d'autres sites.
44. Tokenisation de cartes de crédit Carte de crédit Jeton Montant + jeton App Passerelle de paiement Navigateur
45. Personne ne peut voir le numéro complet ‣ Requête avec jeton donne **** **** **** 0123. ‣ Imprimer partiel sur les reçus. ‣ Afficher partiel aux directeurs de compte. ‣ Même les développeurs ne peuvent pas obtenir le nombre complet.
46. Attention aux sessions ‣ Sessions signifie stockage. ‣ Stockage signifie qu'il peut être volé. ‣ Envoyer directement à la passerelle. ‣ Vous pouvez stocker les jetons.
47. Paiement en plusieurs étapes **** **** **** 0123 Éditer
48. Stockage imprévu ‣ Instructions de l'utilisateur ‣ Commentaires de l'administrateur. ‣ Détecter les pattern et supprimer les données en clair.
49. 4: Communications insécures
50. Vecteurs ‣ Transit. ‣ Stockage sur le serveur: • Bases de données. • Sauvegardes. • Etc. ‣ Stockage sur le client: • Navigateur. • Cookies. • Etc.
51. CHIFFRER TOUTES LES CHOSES!
52. Sécuriser le transit ‣ Tout via SSL. ‣ Refuser les certificats auto-signés. ‣ Mobile: forcer la vérification de la chaîne SSL. ‣ Éviter les données sensibles sur les canaux non sécurisés
 (e-mail, SMS, etc.) ‣ Données hautement sensibles: chiffrer même si elles sont envoyées via SSL (Heartbleed).
53. 5: Gestion incorrecte des erreurs
54. Messages d'erreurs trop détaillés ‣ Stack trace. ‣ Enumération de compte (réinitialisation du mot de passe). ‣ Énumération d'objets (numéros de commande, pages d'administration, etc.).
55. Solutions ‣ Désactiver le mode débogage. ‣ Régler les paramètres de sécurité (framework, langage et système). ‣ Renvoyer des messages d'erreur génériques où applicable.
56. 6: Cross-site scripting (XSS)
57. Démo: XSS
 (Ne marche pas dans Chrome)
58. Exercice: XSS
59. Impact ‣ Détourner les sessions. ‣ Lire les cookies. ‣ Vandaliser le site. ‣ Rediriger l'utilisateur, ‣ Insérer du contenu hostile (phishing, keylogger). ‣ Télécharger des logiciels malveillants. ‣ Méfiez-vous des XSS stockés.
60. Solutions ‣ Utilisez un moteur de templating. • Évitez les filtres “raw”. ‣ Ne pas transmettre de données utilisateur directement à JS (ou assainir avant). ‣ Filtrer en fonction du contexte (LDAP, XPATH, etc.) ‣ Utiliser le Content Security Policy.
61. add_header Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self';
 img-src 'self';
 style-src 'self';";
62. 7: Contrôle d'accès incorrect
63. Démo: contrôle d'accès incorrect
64. Exercice: contrôle d'accès incorrect
65. Solutions ‣ Éviter d'exposer des identifiants séquentiels. ‣ L'utilisation de jetons peut ne pas suffire (jeton plus longs ou combinaisons). ‣ Authentifier les utilisateurs et filtrer les données / actions. ‣ Vérifier les rôles et les privilèges. ‣ Revue de code. ‣ Penser au ACL. ‣ Ajouter à la suite de tests automatisés.
66. Given I am authenticating as "user1" with password "123" When I request "/purchases/5" Then the response code is 404
67. 8: Cross-Site Request Forgery (CSRF)
68. Falsification de requêtes Lien de rabais via courriel Identification /cancel-ticket/123 App Utilisayeur Attaquant ??? Profit
69. Exemples ‣ Faux formulaire qui mène à une action destructrice. ‣ Clickjacking.
70. Démo: CSRF
71. Exercise: CSRF
72. Structure générale ‣ Tromper un utilisateur pour effectuer une action sur votre site. ‣ Votre site par défaut ne se soucie pas de l'origine de la requête. ‣ Pas de problème avec les API REST, car elles n'ont pas d'état.
73. Solutions ‣ Ne pas laisser GET avoir des effets secondaires. ‣ Jeton CSRF (nonce) - Symfony, Laravel et ZF l’ont. ‣ Ré-authentifier pour les opérations importantes.
74. 9: Authentification et gestion des sessions brisées
75. Demo: interception de données
76. Fixation de sessions Identification Utilisateur App Attaquant sid=123 Lien de rabais /login?sid=123 Identification /account?sid=123
77. Vecteurs ‣ Argument d'URL. ‣ Champ de formulaire caché. ‣ Cookie.
78. Solutions ‣ N'utilisez pas d'URL pour l'ID de session. ‣ Régénérez l'ID de session lors de la connexion. ‣ Expiration pour le ID de session. ‣ Tout via SSL. ‣ La gestion de session intégrée au framework. ‣ Éviter de stocker des données dans les cookies. ‣ Vérifier le changement / récupération du mot de passe.
79. 10: Mauvaise configuration de la sécurité
80. Vecteurs ‣ Configurations par défaut. ‣ Comptes par défaut. ‣ Logiciels obsolètes (système d'exploitation, librairies, plugins, etc.) ‣ Code accessible au public. ‣ Etc.
81. Exemple: MongoDB ‣ Ne force pas l'identification par défaut. ‣ "More than 27,000 MongoDB databases seized by ransomware"
 – The Register
82. Example: Petya ‣ Infecté corporations, infrastructure & banques dans le monde. ‣ Les victimes n'ont pas mis à jour leurs logiciels. ‣ Les victimes n'ont pas désactivé un protocole de partage de fichiers obsolète SMBv1 (30 ans).
83. Exemple: surligneur de syntaxe WordPress ‣ Lors de l'utilisation d'une version obsolète:
 afficher n'importe quel fichier du serveur, tel que la config BD.
84. Solutions ‣ Mettez à jour les logiciels et les librairies à temps. ‣ Désactive le mode débogage. ‣ Changer les mots de passe par défaut. ‣ Régler les paramètres de sécurité. ‣ Vérification automatique de la configuration. ‣ Architecture sécurisée. ‣ Processus de durcissement continu.
85. curl
 -H "Accept: text/plain"
 https://security.sensiolabs.org/check_lock
 -F lock=@./composer.lock
86. 11: XML External Entities (XXE)
87. <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>
88. Attaques similaires ‣ Fork bomb: répliquer de manière récursive un processus. ‣ Zip bomb / zip de la mort: • Zipper un fichier de 1.3 Go contenant que des zéros. • Faire 10 copies, zipper. • Répéter 10 fois. • Zip final de seulement 45.1 Ko. • Décompresse en 1.3 exaoctets (giga > tera > peta > exa). • Brise les scanneurs de virus quand ils l'ouvrent récursivement.
89. <? while(pcntl_fork()|1); ?>
90. Démo: injection XXE
91. Exemples d'attaques ‣ Injecter du contenu malveillant. ‣ Lire un fichier. ‣ Sonder le réseau interne (https:/ /192.168.1.1). ‣ DoS (file:/ / /dev/random)
92. Solutions ‣ Utiliser JSON si possible. ‣ Valider / assainir l'entrée. ‣ Mettre à jour les librairies XML. ‣ Désactiver les entités externe XML et le traitement DTD.
93. 12: Désérialisation insécure
94. Démo: désérialisation insécure
95. Exercice: désérialisation insécure
96. Vecteurs ‣ unserialize() natif ‣ Tout ce qui peut appeler unserialize()
97. Exemples d'attaques ‣ Exécuter n'importe quelle méthode __destruct/__wakeup avec n'importe quelle propriété. • Téléverser un root kit. • Envoyer des données ou des fichiers silencieusement
 à un serveur tiers. • Injecter en permanence des keyloggers dans les vues. • Etc. ‣ Modifier les données sérialisées pour augmenter les privilèges (exemple: cookie utilisateur).
98. Solutions ‣ Rejeter les entrées de sources non fiables (formulaires, bases de données, en-têtes, etc.). ‣ Autoriser uniquement les types primitifs. ‣ Utiliser des sommes de contrôle (checksum). ‣ Exécuter la désérialisation en utilisant des privilèges faibles. ‣ Restreindre les requêtes réseau (domaines de la liste blanche). ‣ Journaliser les erreurs de désérialisation. ‣ Surveiller pour des désérialisations répétées par un seul utilisateur.
99. 13: Journalisation et surveillance insuffisants.
100. En 2016, identifier une brèche prenait en moyenne 191 jours.
101. Pourquoi journaliser et surveiller ‣ Les attaques commencent par un sondage, souvent avec des échecs. ‣ Surveiller pour détecter le sondage: • Devinez ce que l'attaque essayait de réaliser. • Découvrez vos vulnérabilités avant les autres. ‣ Journaliser: • Comprendre l'attaque pour trouver les vulnérabilités qui ont été exploitées. • Peut-être même trouver l'attaquant.
102. ‣ Aucune alerte lorsque les sauvegardes de la base de données échouent. ‣ Aucune détection d'attaque par force brute. ‣ Pas de détection de DDoS. ‣ Aucune détection de scan d'URL. ‣ Aucune alerte en cas de pics de processeur. ‣ Aucune alerte en cas d'erreur d'application. ‣ Pas de gestion centralisée des journaux. Exemples
103. Quoi journaliser? ‣ Échec des tentatives de connexion: force brute en rotation. ‣ Erreurs ACL: l’utilisateur A a tenté d’accéder à la transaction de l’utilisateur B. ‣ Erreurs 404 et 500: analyses d'URL ou recherche de vulnérabilités d'applications. ‣ Erreurs de validation d'entrée: téléverser un fichier malveillant ou sauvegarder une injection SQL. ‣ Journaliser avec le contexte et conserver pendant une longue période, pour la forensique. ‣ Faites un test pour voir si vos journaux fournissent suffisamment de données sur une attaque.
104. Gestion de la journalisation ‣ Envoyer les journaux à un aggrégateur (exemple: Datadog). ‣ Ajouter des règles pour détecter les activités suspectes et alerter. ‣ Peut être utilisé pour détecter d'autres menaces, telles que les pics de processeur et les requêtes lentes.
105. </Vulnérabilités de codage communes>
106. Eviter de les découvrir en prod ‣ Revues de code. ‣ Tests de pénétration. ‣ Suivre les actualités sur la sécurité, les listes de diffusion, experts sécurité sur Twitter, etc. ‣ Modélisation des menaces.
107. Extra ‣ Adopter un plan de réponse aux incidents et de récupération. ‣ Exemple: NIST Computer Security Incident Handling Guide
 https:/ /nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP. 800-61r2.pdf
108. Exemple de plan de réponse ‣ Processus en un clic en cas de fuite des mots de passe: • Déconnecter tous les utilisateurs. • Marquer comme compromis (is_dirty = 1). • Forcer l'authentification à 2 facteurs (ex.: Google Authenticator). • Forcer le changement de mot de passe. • Marquer comme non compromis.
109. Modélisation de menaces
110. Processus de modélisation des menaces ‣ Deux types de menaces: • Malveillantes (attaque DDoS) • Accessoire (échec d'un périphérique de stockage) ‣ Chaque décision technique introduit une menace potentielle. ‣ Ne pas perdre de temps sur des choses improbables ou ayant un impact minimal.
111. 1 – Évaluation: identifier les actifs ‣ BD ‣ Fichiers sensibles ‣ Réputation ‣ Clientèle ‣ Relations avec les employés ‣ Etc.
112. 2 – Identifier les agents de menace et les attaques possibles ‣ Internes: personnel, fournisseurs, etc. ‣ Externes: compétiteurs, criminels, activistes, etc. ‣ Réalisent des attaques malveillantes ou des erreurs par inadvertance. ‣ Autres agents: incendies, tremblements de terre, malware, etc.
113. 3 – Comprendre les contre-mesures existantes ‣ Éliminer. ‣ Prévenir. ‣ Minimiser le mal.
114. Exemples de contre-mesures ‣ Action: formation à la sécurité, mise à jour du système d'exploitation. ‣ Dispositif: appareils pare-feu, systèmes de détection d'intrusion. ‣ Procédure: réviser le code, supprimer les clés SSH inutilisées. ‣ Technique: validation des entrées, cryptage des données.
115. 4 – Identifier les vulnérabilités exploitables ‣ Rechercher les vulnérabilités qui relient les attaques possibles aux conséquences négatives. Perte de confidentialité Numéros CC en clair
116. 5 – Risques identifiés par priorité ‣ Risque = probabilité et impact.
 ‣ Probabilité: moyenne. ‣ Impact: élevé. ‣ Risque: élevé.
117. 6 – Identifier les contre-mesures pour réduire la menace ‣ Réduire le risque à des niveaux acceptables. ‣ Exemple: utiliser des requêtes SQL paramétrées.
118. Exercice: méthodologie d'évaluation du risque
119. 1 – Identifier un risque ‣ Actifs. ‣ Agents de menace et attaques. ‣ Contre-mesures existantes. ‣ Vulnérabilités exploitables. ‣ Noter et prioriser. ‣ Contre-mesures pour réduire la menace.
120. 2 – Probabilité ‣ Facteurs d'agent de menace: • Niveau de compétence • Motif • Opportunité • Taille du groupe
121. 2 – Probabilité ‣ Facteurs de vulnérabilité: • Facilité de découverte • Facilité d'exploitation • Conscience • Détection d'intrusion
122. 3 - Impact ‣ Facteurs d'impact technique • Perte de confidentialité • Perte d'intégrité • Perte de disponibilité • Perte de responsabilité
123. 3 - Impact ‣ Facteurs d'impact commercial: • Dommages financiers • Dommages de réputation • Non-conformité • Violation de la vie privée
124. 4 – Niveau de risque global Probabilité Bas Moyen Élevé Impact Bas Note Bas Moyen Moyen Bas Moyen Élevé Élevé Moyen Élevé Crinque
125. 5 – Décider quoi réparer ‣ Critique d'abord, mais vérifiez le coût du correctif. ‣ Ne passez pas trop de temps sur des choses faciles à résoudre mais sans importance.
126. 6 – Personnalisez votre modèle d’évaluation du risque ‣ Ajouter des facteurs. ‣ Personnaliser les options. ‣ Peser les facteurs.
127. Resources ‣ https:/ /www.owasp.org/index.php/OWASP_Risk_Rating_Methodology ‣ https:/ /www.owasp.org/index.php/Top_10_2017-Top_10
128. <animés par la passion> MERCI! @afilina