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

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

B3b2139e4f2c0eca4efe2379fcebc1c5?s=128

Anna Filina

March 11, 2019
Tweet

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

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

  25. None
  26. None
  27. None
  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