Veille Technologique

Les fonctions applicatives liées à l'authentification et à la gestion de session sont souvent mal implémentées, ce qui permet aux attaquants de compromettre les mots de passe, les clés ou les jetons de session, ou d'exploiter d'autres failles d'implémentation pour assumer temporairement ou définitivement l'identité des autres utilisateurs.

Exemple:

Parmi les attaques contre les systèmes d'authentification, la plus répandue est l'utilisation de la force brute. Pour cela l'attaquant va bombarder la page d'authentification avec des valeurs d'identifiant et de mots de passe jusqu'à ce qu'il se fasse accepter.

Solution:

"Concernant les systèmes d'authentification, l'application ne doit accepter que des mots de passe suffisamment forts pour éviter d'être devinés rapidement par la force brute. Une longueur minimale de huit caractères est ce qui recommandé par l'OWASP pour les applications critiques. De plus il doit comporter au moins un chiffre, une lettre en minuscule et une lettre en majuscule.

Le message affiché lors d'un problème de validité de l'identifiant ou du mot de passe doit être générique et ne doit pas donner d'indice quant à l'origine de l'erreur.

Pour contrer les attaques de force brute, le compte ciblé par l'attaque doit être verrouillé après cinq tentatives consécutives infructueuses de connexion. La procédure de déverrouillage peut être automatique après un laps de temps prédéfini ou manuelle par un administrateur de l'application.

Dans la mesure du possible il est conseillé de ne pas développer son propre mécanisme d'authentification. Il est préférable d'utiliser un système existant éprouvé.

Concernant les identifiants de session, les applications Web doivent limiter la durée de vie d'une session. Une période d'inactivité maximale doit être définie. Si l'utilisateur n'utilise pas l'application pendant ce laps de temps, la session devient inutilisable et l'utilisateur doit se reconnecter. Une session doit également avoir une durée de vie maximale au-delà de laquelle la session expire, même si la période d'inactivité autorisée n'était pas dépassée. Ces précautions permettent de limiter le temps d'action d'un attaquant.

Du côté client, du code JavaScript doit fermer la session lorsque l'utilisateur ferme le navigateur. Cela permet de simuler une action de l'utilisateur pour se déconnecter de l'application. Pour que l'utilisateur évite de perdre des saisies non sauvegardées, du code JavaScript peut prévenir l'utilisateur que sa session va bientôt expirer.

L'identifiant de session doit être généré automatiquement et être suffisamment long pour se prémunir des vols par prédiction.

Pour détecter des attaques de force brute, il faut régulièrement consulter les journaux d'activité à la recherche d'événements inhabituels, comme un nombre important de requêtes utilisant des identifiants de sessions invalides."
https://web.developpez.com/tutoriels/web/failles-securite-application-web/

De nombreuses applications Web et API ne protègent pas correctement les données sensibles, telles que les données financières, les soins de santé et les informations personnelles. Les attaquants peuvent voler ou modifier ces données faiblement protégées pour mener une fraude par carte de crédit, un vol d'identité ou d'autres crimes. Les données sensibles peuvent être compromises sans protection supplémentaire, telle que le cryptage au repos ou en transit, et nécessitent des précautions particulières lorsqu'elles sont échangées avec le navigateur.

Exemple :

Un pirate attaque un serveur via par exemple une faille de type injection SQL et récupère ainsi tout ou partie de la base de données. Cette base de données contient l’ensemble des mots de passe de tous les consommateurs. Malheureusement, les mots de passe ont été hachés avec un algorithme dépassé (tel que “MD5”). L’attaquant va pouvoir utiliser ce que l’on appelle des “rainbow tables”, permettant de faire la correspondance entre des valeurs déjà hachés avec MD5 et les valeurs en clair. La majorité des mots de passe pourront être exploités.

Solution:

• La première étape est de ne pas collecter d’informations auprès des utilisateurs, qui ne seront pas utilisés. Il en va de même pour le stockage des données: ne pas stocker d’informations qui n’ont pas besoin de stocker. Si elles ne sont pas présentes, les informations ne pourront pas être volées!
  Durant la conception fonctionnelle et technique, il est nécessaire de prendre le temps pour évaluer les besoins de collecte/stockage.
• Identifier les données sensibles, et s’assurer qu’elles sont cryptées avec l’algorithme adéquat, lors de la transmission et lors du stockage.
• S’assurer que des algorithmes récents et reconnus sont utilisés pour crypter/hacher les données.
  L’OWASP et de nombreuses autres sources d’informations répertorient ces algorithmes.
• Effectuer un test d’intrusion sur l'application web, pour être certain de ne pas avoir oublié quoi que ce soit.
  Périodiquement soumettre l'application web à un audit de sécurité permettra de s’assurer que l’application reste suffisamment robuste au fil du temps.

De nombreux processeurs XML plus anciens ou mal configurés évaluent les références d'entités externes dans les documents XML. Les entités externes peuvent être utilisées pour divulguer des fichiers internes à l'aide du gestionnaire d'URI de fichier, des partages de fichiers internes, de l'analyse des ports internes, de l'exécution de code à distance et des attaques par déni de service.

Exemple:

Scenario 1 : L'attaquant tente d'extraire des données du serveur :

<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [
    <!ELEMENT foo ANY >
    <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
    <foo>&xxe;</foo>
                        

Scenario 2 : Un attaquant scan le réseau privé du serveur en modifiant la ligne ENTITY ci-dessous en :

   <!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
                    

Scenario 3 : Un attaquant tente une attaque par déni de service en incluant un fichier potentiellement sans fin :

   <!ENTITY xxe SYSTEM "file:///dev/random" >]>
                    

Solution:

La formation des développeurs est essentielle pour identifier et atténuer les XXE. De plus, prévenir des XXE nécessite :

• Autant que possible, utiliser des formats de données moins complexes tels que JSON et éviter la sérialisation des données sensibles.
• Corriger ou mettre à niveau tous les moteurs et bibliothèques XML utilisés par l'application ou sur le système d'exploitation sous-jacent. Utiliser des vérificateurs de dépendance. Mettre à jour SOAP vers SOAP 1.2 ou supérieur.
• Désactiver le traitement des entités externes XML et des DTD dans tous les moteur XML de l’application, OWASP Cheat Sheet 'XXE Prevention'.
• Implémenter une validation, un filtrage ou une désinfection des entrées côté serveur positives ("liste blanche") pour empêcher les données hostiles dans les documents XML, les en-têtes ou les nœuds.
• Vérifier que la fonctionnalité de téléchargement de fichier XML ou XSL valide le XML entrant à l'aide de la validation XSD ou similaire.
• Les outils SAST peuvent aider à détecter XXE dans le code source, bien que la relecture manuelle du code soit la meilleure alternative dans les applications volumineuses et complexes comportant de nombreuses intégrations. Si ces contrôles sont impossibles, envisagez d'utiliser des correctifs virtuels, des passerelles de sécurité d'API ou des pare-feu d'applications Web (WAF) pour détecter, surveiller et bloquer les attaques XXE.

Les restrictions sur ce que les utilisateurs authentifiés sont autorisés à faire ne sont souvent pas correctement appliquées. Les attaquants peuvent exploiter ces failles pour accéder à des fonctionnalités et / ou des données non autorisées, telles que l'accès aux comptes d'autres utilisateurs, afficher des fichiers sensibles, modifier les données d'autres utilisateurs, modifier les droits d'accès, etc.

Exemple:


Solution:

Les contrôles d'accès ne sont efficaces que s'ils sont appliqués dans du code de confiance côté serveur ou dans des API server-less, là ou un attaquant ne peut pas modifier les vérifications des contrôles ni les meta-données.

• A l'exception des ressources publiques, tout doit être bloqué par défaut.
• Centraliser l'implémentation des mécanismes de contrôle d'accès et les réutiliser dans l'ensemble de l'application. Cela comprend de minimiser l'utilisation de CORS.
• Le modèle de contrôle d'accès doit vérifier l'appartenance des enregistrements, plutôt que de permettre à l'utilisateur de créer, lire, modifier ou supprimer n'importe quel enregistrement.
• Les exigences spécifiques métier de l'application doivent être appliquées par domaines.
• Désactiver le listing de dossier sur le serveur web, et vérifier que les fichiers de meta-données (ex : .git) et de sauvegardes ne se trouvent pas dans l'arborescence web.
• Tracer les échecs de contrôles d'accès, les alertes administrateur quand c'est approprié (ex : échecs répétés).
• Limiter la fréquence d'accès aux API et aux contrôleurs d'accès, afin de minimiser les dégats que causeraient des outils d'attaques automatisés.
• Les jetons JWT doivent être invalidés côté serveur après une déconnexion.
• Les développeurs et les testeurs qualités doivent procéder à des tests unitaires et d'intégration sur les fonctionnalités de contrôle d'accès.

Une mauvaise configuration de la sécurité est le problème le plus courant. Cela est généralement le résultat de configurations par défaut non sécurisées, de configurations incomplètes ou ad hoc, d'un stockage dans le cloud ouvert, d'en-têtes HTTP mal configurés et de messages d'erreur détaillés contenant des informations sensibles. Non seulement tous les systèmes d'exploitation, frameworks, bibliothèques et applications doivent être configurés de manière sécurisée, mais ils doivent être corrigés / mis à niveau en temps opportun.

Exemple:

Scénario 1 : Le serveur d'application est livré avec des applications classiques qui ne sont pas supprimées du serveur mis en production. Ces mêmes applications ont des failles de sécurité connues que les attaquants utilisent afin de compromettre le serveur. Si l'une de ces applications est la console d'administration, et que les comptes par défaut n'ont pas été modifiés, l'attaquant se connecte avec les mots de passe par défaut et prend la main sur la cible.

Scénario 2 : La fonctionnalité de listage des répertoires n'est pas désactivée sur le serveur. Un attaquant découvre qu'il peut simplement lister les répertoires. L'attaquant trouve et télécharge les classes Java compilées, qu'il décompose et fait de l'ingéniérie inversée pour visualiser le code. L'attaquant trouve alors un grave défaut dans le contrôle d'accès de l'application.

Scénario 3 : La configuration du serveur d'application permet de renvoyer aux utilisateurs des messages d'erreur détaillés, par exemple avec des traces des couches protocolaires applicatives. Cela peut ainsi exposer des informations sensibles ou des vulnérabilités sous-jacentes telles que les versions de composants dont on sait qu'elles sont vulnérables.

Scénario 4 : Un fournisseur de services Cloud (CSP) a positionné des droits de partage par défaut qui sont ouverts sur Internet par d'autres utilisateurs du CSP. Cela permet d'accéder à des données sensibles stockées dans le stockage Cloud.

Solution:

Des processus d'installation sécurisés doivent être mis en œuvre, avec notamment :

• Un processus de durcissement répétable qui permette de déployer rapidement et facilement un autre environnement correctement sécurisé avec une configuration verrouillée. Les environnements de développement, d'assurance qualité et de production doivent tous être configurés de manière identique, avec des droits différents pour chaque environnement. Ce processus devrait être automatisé afin de réduire au minimum les efforts requis pour mettre en place un nouvel environnement sécurisé.
• Une plate-forme minimale sans fonctionnalité, composant, documentation et échantillon inutile. Supprimer ou ne pas installer des fonctionnalités et frameworks inutilisés.
• Une tâche pour revoir et mettre à jour les configurations appropriées à tous les avis de sécurité, toutes les mises à jour et tous les correctifs dans le cadre du processus de gestion des correctifs (voir A9:2017 Utilisation de Composants avec des Vulnérabilités Connues). En particulier, examiner les permissions de stockage dans le Cloud (ex. les permissions des buckets AWS S3).
• Une architecture d'application segmentée qui fournit une séparation efficace et sécurisée entre les composants ou les environnement hébergés, avec de la segmentation, de la mise en conteneurs ou l'utilisation de groupes de sécurité dans le Cloud (ACL).
• L'envoi de directives de sécurité aux clients, par exemple [En-têtes de sécurité] (https://www.owasp.org/index.php/OWASP_Secure_Headers_Project).
• Un processus automatisé pour vérifier l'efficacité des configurations et des réglages dans tous les environnements.

Des failles XSS se produisent chaque fois qu'une application inclut des données non approuvées dans une nouvelle page Web sans validation ou échappement appropriée, ou met à jour une page Web existante avec des données fournies par l'utilisateur à l'aide d'une API de navigateur qui peut créer du HTML ou du JavaScript. XSS permet aux attaquants d'exécuter des scripts dans le navigateur de la victime qui peuvent détourner les sessions des utilisateurs, dégrader des sites Web ou rediriger l'utilisateur vers des sites malveillants.

Exemple:

Scénario : L'application utilise des données non sûres dans la construction du fragment de code HTML sans validation ni technique d'échappement :

Cette attaque envoie l'ID de session de la victime vers le site web de l'attaquant, lui permettant ainsi de détourner la session active de l'utilisateur.

Note : Les attaquants peuvent utiliser XSS pour invalider les défenses automatisées anti-falsification de requête intersite (CSRF) que l'application peut avoir mises en place.

Solution:

Se protéger des attaques XSS nécessite la séparation des données non sûres du contenu actif du navigateur. Pour cela :

• Utiliser des frameworks avec des techniques automatiques d'échappements XSS par conception, comme les dernières versions de Ruby on Rails et React JS. Regarder les limitations de protection XSS de votre framework et prendre les mesures appropriées pour couvrir les cas non gérés.
• Appliquer des techniques d'échappement aux données des requêtes HTTP non sûres, selon le contexte des sorties HTML dans lequel elles seront insérées (body, attribute, Javascript, CSS, ou URL). Cela résoudra les vulnérabilités des XSS Réfléchis ou Stockés. L'Aide-mémoire de l'OWASP 'Prévention des XSS' donne des détails sur les techniques requises d'échappement des données.
• Appliquer un encodage adapté au contexte lors des modifications des documents du navigateur du client est une protection contre les XSS basés sur DOM. Quand cela ne peut pas être évité, des techniques d'échappement, adaptées au contexte, peuvent être appliquées aux API du navigateur comme indiqué dans l'Aide-mémoire de l'OWASP 'Prévention des XSS basés sur DOM'.
• Etablir une Politique de Sécurité du Contenu (CSP) comme mesure de défense en profondeur limitant les attaques XSS. Cela sera efficace, s'il n'y a pas d'autre vulnérabilité qui permettrait de déposer du code malicieux par insertion de fichier en local (ex : écrasement par attaque de type "traversée de répertoire" ou via des bibliothèques vulnérables des réseaux de diffusion de contenu (CDN) autorisés).

Une désérialisation non sécurisée conduit souvent à l'exécution de code à distance. Même si les failles de désérialisation n'entraînent pas l'exécution de code à distance, elles peuvent être utilisées pour effectuer des attaques, y compris des attaques de relecture, des attaques par injection et des attaques par élévation de privilèges.

Exemple:

Scénario 1 : Une application React appelle un ensemble de microservices Spring Boot. Sensibles à la programmation fonctionnelle, les développeurs essaient de s'assurer que leur code est immutable. La solution qu'ils ont trouvée consiste à sérialiser l'état de l'utilisateur et à le transmettre à chaque requête. Un attaquant remarque la signature d'objet Java "R00" et utilise l'outil Java Serial Killer pour effectuer une exécution de code à distance sur le serveur d'applications.

Scénario 2 : Un forum utilise la sérialisation des objets PHP pour enregistrer un cookie, contenant l'ID utilisateur, le rôle, le condensat du mot de passe et les autres attributs de l'utilisateur.

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Un attaquant modifie l'objet sérialisé pour se donner des privilèges d'administrateur :

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Solution:

La seule architecture logicielle sûre est de ne pas accepter les objets sérialisés provenant de sources non fiables ou d'utiliser des supports de sérialisation qui autorisent uniquement les types de données primitifs.
Si ce n'est pas possible, envisagez l'une des solutions suivantes :

• Implémenter des contrôles d'intégrité tels que des signatures numériques sur tous les objets sérialisés pour empêcher la création d'objets dangereux ou la falsification de données.
• Appliquer des contraintes de typage fort lors de la désérialisation avant la création de l'objet car le code attend généralement un ensemble définissable de classes. Des contournements de cette technique ont été démontrés, il est donc déconseillé de se fier uniquement à elle.
• Isoler et exécuter le code qui désérialise dans des environnements à faible privilège lorsque cela est possible.
• Journaliser les exceptions et échecs de désérialisation, par exemple lorsque le type entrant n'est pas le type attendu, ou que la désérialisation génère des exceptions.
• Restreindre ou surveiller la connectivité réseau entrante et sortante des conteneurs ou des serveurs utilisés pour la désérialisation.
• Faire une surveillance des désérialisations, alerter si un utilisateur désérialise constamment.

Les composants, tels que les bibliothèques, les frameworks et d'autres modules logiciels, s'exécutent avec les mêmes privilèges que l'application. Si un composant vulnérable est exploité, une telle attaque peut faciliter de graves pertes de données ou une prise de contrôle du serveur. Les applications et les API utilisant des composants avec des vulnérabilités connues peuvent saper les défenses des applications et permettre diverses attaques et impacts.

Exemple:

Scénario : Les composants s'exécutent généralement avec le même niveau de privilèges que l'application, et donc les failles d'un quelconque composant peuvent aboutir à un impact sévère. Les failles peuvent être accidentelles (ex : erreur de codage) ou intentionnelles (ex : porte dérobée dans un composant). Voici quelques exemples de découvertes de vulnérabilités exploitables de composants :

• CVE-2017-5638, une vulnérabilité d'exécution à distance de Struts 2, qui permet l'éxecution de code arbitraire sur le serveur, a été responsable d'importantes violations.
• Bien que l'internet des objets (IoT) soit souvent difficile voire impossible à mettre à jour, l'importance de ces mises à jour peut être énorme (ex : objets biomédicaux).

Il existe des outils automatiques qui aident les attaquants à trouver des systèmes malconfigurés ou non mis à jour. Par exemple, le moteur de recherche IoT de Shodan peut vous aider à trouver des objets qui sont encore vulnérables à la faille Heartbleed corrigée en Avril 2014.

Solutions:

Vous devez mettre en place une gestion des mises à jour pour :

• Supprimer les dépendances inutiles et les fonctionnalités, composants, fichiers et documentation non nécessaires.
• Faire un inventaire en continu des versions de composants à la fois client et serveur (ex : frameworks, bibliothèques) et de leurs dépendances avec des outils tels que versions, DependencyCheck, retire.js, etc.
• Surveiller en permanence les sources comme CVE et NVD pour suivre les vulnérabilités des composants. Utiliser des outils d'analyse de composants logiciels pour automatiser le processus. Souscrire aux alertes par courriel concernant les vulnérabilités sur les composants que vous utilisez.
• Ne récupérer des composants qu'auprès de sources officielles via des liens sécurisés. Préférer des paquets signés pour minimiser les risques d'insertion de composants modifiés malicieux.
• Surveiller les bibliothèques et les composants qui ne sont plus maintenus ou pour lesquels il n'y a plus de correctifs de sécurité. Si les mises à jour ne sont pas possibles, penser à déployer des mises à jour virtuelles pour surveiller, détecter et se protéger d'éventuelles découvertes de failles.
• Chaque organisation doit s'assurer d'avoir un projet continu de surveillance, de tri, d'application des mises à jour et de modification de configuration pour la durée de vie d'une application ou de sa gamme.

Une journalisation et une surveillance insuffisantes, associées à une intégration manquante ou inefficace avec la réponse aux incidents, permettent aux attaquants d'attaquer davantage les systèmes, de maintenir la persistance, de basculer vers plus de systèmes et de falsifier, extraire ou détruire les données. La plupart des études sur les violations montrent que le temps de détection d'une violation est supérieur à 200 jours, généralement détecté par des parties externes plutôt que par des processus ou une surveillance internes.

Exemple:

Scénario 1 : Un forum, pour un projet de développement open source d’une petite équipe, a été piraté à cause d’une faille logicielle. Les attaquants ont effacé le dépôt du code source de la future version et tout le contenu du forum. Bien que le code ait pu être récupéré, le manque de supervision, de journalisation et d’alertes ont conduit à une atteinte bien plus grave. Le résultat étant que le projet a été arrêté.

Scénario 2 : Un attaquant teste des accès utilisateurs avec un mot de passe commun. Il pourra accéder à tous les comptes ayant ce mot de passe. Pour tous les autres utilisateurs, ce test ne laisse qu'une trace de tentative d'accès échoué. Quelques jours après, ce test peut être réalisé avec un autre mot de passe.

Scénario 3 : Un grand distributeur américain a rapporté qu'une sandbox d’analyse de malware de fichiers attachés, aurait détecté un logiciel suspect, mais que personne n'a réagi à cette détection. Il y a eu plusieurs alertes avant que la brèche ne soit découverte par une banque externe à cause d'une transaction par carte frauduleuse.

Solution:

Conformément aux risques évalués sur les données stockées ou gérées par l'application :

• S'assurer que toutes les authentifications, les erreurs de contrôle d'accès et de contrôle des entrées côté serveur sont enregistrées, avec un contexte utilisateur suffisant pour identifier les comptes suspects ou malveillants, et conservées suffisamment longtemps pour permettre une analyse légale différée.
• S'assurer que les enregistrements des journaux sont dans un format standard pour permettre de les intégrer facilement à une solution de gestion de logs centralisée.
• S'assurer que les transactions à haute valeur ajoutée ont une piste d'audit, avec un contrôle d'intégrité, pour éviter la modification ou la suppression, comme des tables de bases de données en ajout seul ou équivalent.
• Mettre en place une supervision et une gestion d'alertes efficaces pour détecter et réagir aux actions suspectes en temps opportun.
• Définir ou adopter un plan de réaction et de reprise sur incident, comme celui du NIST 800-61 rev 2 ou ultérieur.

On trouve des logiciels, commerciaux ou open source, de protection d'applications tel que OWASP AppSensor, de pare-feux d'application web (WAF) tel que ModSecurity with the OWASP ModSecurity Core Rule Set et de logiciels de corrélation de journaux avec des tableaux de bord et d'alertes configurables.