Phenquestions
Table des matières
- Injection de base de données
- Authentification cassée
- Exposition de données sensibles
- Entités externes XML (XEE)
- Contrôle d'accès cassé
- Mauvaise configuration de la sécurité
- Script intersites (XSS)
- Désérialisation non sécurisée
- Utilisation de composants avec des vulnérabilités connues
- Journalisation et surveillance insuffisantes
Injection de base de données :
En cas d'envoi de données non fiables à l'interpréteur dans le cadre d'une commande via n'importe quelle zone qui prend l'entrée de l'utilisateur i.e formulaire de saisie ou toute autre zone de soumission de données, des défauts d'injection se produisent. Les requêtes malveillantes de l'attaquant peuvent amener l'interpréteur à exécuter des commandes pouvant afficher des données confidentielles que l'utilisateur n'est pas autorisé à consulter. Par exemple, lors d'une attaque par injection SQL, lorsque la saisie du formulaire n'est pas correctement filtrée, l'attaquant peut entrer dans la base de données SQL et accéder à son contenu sans autorisation, simplement en saisissant le code malveillant de la base de données SQL dans un formulaire qui attend un texte en clair. Tout type de champ qui prend l'entrée de l'utilisateur est injectable i.e paramètres, variables d'environnement, tous les services Web, etc.
L'application est vulnérable à l'attaque par injection lorsque les données fournies par l'utilisateur ne sont pas filtrées et validées, par l'utilisation de requêtes dynamiques sans échappement contextuel et l'utilisation directe de données hostiles. Les défauts d'injection peuvent être facilement découverts grâce à l'examen du code et à l'utilisation d'outils automatisés tels que des scanners et des fuzzers. Pour empêcher les attaques par injection, certaines mesures peuvent être prises, comme séparer les données des commandes et des requêtes, utiliser une API sécurisée qui fournit une interface paramétrée, utiliser la validation d'entrée côté serveur « liste blanche » via des outils comme Snort, échappement de caractères spéciaux à l'aide d'une syntaxe d'échappement spécifique, etc.
Une attaque par injection peut entraîner une perte massive de données, la divulgation d'informations confidentielles, un refus d'accès et peut même conduire à une prise de contrôle complète de l'application. Certains contrôles SQL comme LIMIT peuvent être utilisés pour contrôler d'énormes quantités de données perdues en cas d'attaque. Certains types d'attaques par injection sont les attaques par injection SQL, OS, NoSQL, LDAP.
Authentification cassée :
Les attaquants peuvent accéder aux comptes d'utilisateurs et peuvent même compromettre l'ensemble du système hôte via des comptes d'administrateur, en utilisant les vulnérabilités des systèmes d'authentification. Les failles d'authentification permettent à l'attaquant de compromettre les mots de passe, les jetons de session, les clés d'authentification et peuvent être enchaînées avec d'autres attaques pouvant conduire à un accès non autorisé à tout autre compte d'utilisateur ou session temporairement et dans certains cas, de manière permanente. Supposons qu'un utilisateur dispose d'une liste de mots ou d'un dictionnaire de millions de noms d'utilisateurs et de mots de passe valides obtenus lors d'une violation. Il peut les utiliser un par un en un temps extrêmement réduit à l'aide d'outils et de scripts automatisés sur le système de connexion pour voir si quelqu'un fonctionne. Une mauvaise mise en œuvre de la gestion des identités et des contrôles d'accès entraîne des vulnérabilités telles que l'authentification interrompue.
L'application est vulnérable aux attaques d'authentification lorsqu'elle permet d'essayer différents noms d'utilisateur et mots de passe, autorise les attaques par dictionnaire ou les attaques par force brute sans aucune stratégie de défense, utilise des mots de passe par défaut simples ou des mots de passe qui sont divulgués dans toute violation, expose les identifiants de session dans l'URL, utilise mauvais schéma de récupération de mot de passe, utilise un modèle de cookies. L'authentification cassée peut être exploitée facilement à l'aide d'outils simples pour les attaques par force brute et par dictionnaire avec un bon dictionnaire. Ces types d'attaques peuvent être évités à l'aide de systèmes d'authentification multifacteur, en mettant en œuvre des contrôles de mot de passe faibles en exécutant un mot de passe via une base de données de mots de passe incorrects, en n'utilisant pas les informations d'identification par défaut, en alignant la politique de complexité des mots de passe, en utilisant de bons gestionnaire de session qui génère un nouvel identifiant de session aléatoire après la connexion, etc.
Une vulnérabilité d'authentification brisée peut entraîner la compromission de quelques comptes d'utilisateurs et d'un compte administrateur, c'est tout ce dont un attaquant a besoin pour compromettre un système. Ces types d'attaques conduisent au vol d'identité, à la fraude à la sécurité sociale, au blanchiment d'argent et à la divulgation d'informations hautement classifiées. Les attaques incluent les attaques par dictionnaire, le brute-forcing, le piratage de session et les attaques de gestion de session.
Exposition de données sensibles :
Parfois, les applications Web ne protègent pas les données et informations sensibles telles que les mots de passe, les informations d'identification de la base de données, etc. Un attaquant peut facilement voler ou modifier ces informations d'identification faiblement protégées et les utiliser à des fins illégitimes. Les données sensibles doivent être cryptées au repos ou en transit et avoir une couche de sécurité supplémentaire, sinon les attaquants peuvent les voler. Les attaquants peuvent mettre la main sur des données sensibles exposées et voler des utilisateurs en texte haché ou en clair et des informations d'identification de base de données sur le serveur ou un navigateur Web. Par exemple, si une base de données de mots de passe utilise des hachages non salés ou simples pour stocker des mots de passe, une faille de téléchargement de fichier peut permettre à un attaquant de récupérer la base de données de mots de passe, ce qui entraînera l'exposition de tous les mots de passe avec une table arc-en-ciel de hachages pré-calculés.
Le principal défaut est non seulement que les données ne sont pas cryptées, même si elles sont cryptées, mais une génération de clé faible, des algorithmes de hachage faibles, une utilisation faible du chiffrement peuvent également entraîner ces types d'attaques les plus courantes. Pour empêcher ces types d'attaques, commencez par classer les types de données pouvant être considérées comme sensibles selon les lois sur la confidentialité et appliquez des contrôles selon la classification. Essayez de ne pas stocker de données classifiées dont vous n'avez pas besoin, lavez-les dès que vous les utilisez. Pour les données en transit, cryptez-les avec des protocoles sécurisés i.e TLS avec chiffrements PFS, etc.
Ces types de vulnérabilités peuvent entraîner l'exposition d'informations hautement sensibles telles que les informations d'identification de carte de crédit, les dossiers de santé, les mots de passe et toute autre donnée personnelle pouvant conduire à l'usurpation d'identité et à la fraude bancaire, etc.
Entités externes XML (XEE) :
Les processeurs XML mal configurés traitent les références d'entités externes dans les documents XML. Ces entités externes peuvent être utilisées pour récupérer les données des fichiers internes comme /etc/passwd fichier ou pour effectuer d'autres tâches malveillantes. Les processeurs XML vulnérables peuvent facilement être exploités si un attaquant peut télécharger un document XML ou inclure XML, etc. Ces entités XML vulnérables peuvent être découvertes à l'aide des outils SAST et DAST ou manuellement en inspectant les dépendances et les configurations.
Une application Web est vulnérable à l'attaque XEE pour de nombreuses raisons, par exemple si l'application accepte une entrée XML directe de sources non fiables, les définitions de type de document (DTD) sur l'application sont activées, l'application utilise SAML pour le traitement des identités, car SAML utilise XML pour l'identité. insertions, etc. Les attaques XEE peuvent être atténuées en évitant la sérialisation des données sensibles, en utilisant des formats de données moins compliqués i.e JSON, correctif des processeurs XML que l'application utilise actuellement et même des bibliothèques, désactivation des DTD dans tous les analyseurs XML, validation de la fonctionnalité de téléchargement de fichiers XML à l'aide de la vérification XSD, etc.
L'application vulnérable à ces types d'attaques peut entraîner une attaque DOS, une attaque de Billion Laughs, une analyse des systèmes internes, une analyse des ports internes, l'exécution d'une commande à distance qui affecte toutes les données de l'application.
Contrôle d'accès cassé :
Le contrôle d'accès donne aux utilisateurs des privilèges pour effectuer des tâches spécifiques. Une vulnérabilité de contrôle d'accès brisée se produit lorsque les utilisateurs ne sont pas correctement limités sur les tâches qu'ils peuvent effectuer. Les attaquants peuvent exploiter cette vulnérabilité qui peut finir par accéder à des fonctionnalités ou des informations non autorisées. Disons qu'une application Web permet à l'utilisateur de changer le compte à partir duquel il est connecté simplement en changeant l'URL du compte d'un autre utilisateur sans autre vérification. L'exploitation de la vulnérabilité de contrôle d'accès est une attaque incontournable de tout attaquant, cette vulnérabilité peut être trouvée manuellement ainsi qu'en utilisant les outils SAFT et DAFT. Ces vulnérabilités existent en raison d'un manque de tests et de détection automatisée des applications Web bien que la meilleure façon de les trouver soit de le faire manuellement.
Les vulnérabilités contiennent une escalade de privilèges i.e agir en tant qu'utilisateur que vous n'êtes pas ou en tant qu'administrateur pendant que vous êtes un utilisateur, en contournant les contrôles d'accès simplement en modifiant l'URL ou en changeant l'état de l'application, la manipulation des métadonnées, en permettant à la clé primaire d'être modifiée en tant que clé primaire d'un autre utilisateur, etc. Pour empêcher ces types d'attaques, des mécanismes de contrôle d'accès doivent être implémentés dans le code côté serveur où les attaquants ne peuvent pas modifier les contrôles d'accès. L'application de limites commerciales d'applications uniques par les modèles de domaine, la désactivation de la liste des répertoires de serveurs, l'alerte de l'administrateur en cas de tentatives répétées de connexion infructueuses, l'invalidation des jetons JWT après la déconnexion doivent être assurées pour atténuer ces types d'attaques.
Les attaquants peuvent agir comme un autre utilisateur ou administrateur en utilisant cette vulnérabilité pour effectuer des tâches malveillantes telles que la création, la suppression et la modification d'enregistrements, etc. Une perte massive de données peut se produire si les données ne sont pas sécurisées même après une violation.
Mauvaise configuration de la sécurité :
La vulnérabilité la plus courante est la mauvaise configuration de la sécurité. La principale raison de la vulnérabilité est l'utilisation d'une configuration par défaut, d'une configuration incomplète, de configurations Adhoc, d'en-têtes HTTP mal configurés et de messages d'erreur détaillés contenant plus d'informations que l'utilisateur n'aurait dû savoir. À n'importe quel niveau d'une application Web, des erreurs de configuration de sécurité peuvent se produire i.e base de données, serveur Web, serveur d'applications, services réseau, etc. Les attaquants peuvent exploiter des systèmes non corrigés ou accéder à des fichiers et répertoires non protégés pour avoir une emprise non autorisée sur le système. Par exemple, une application des messages d'erreur excessivement verbeux qui aident l'attaquant à connaître les vulnérabilités du système d'application et son fonctionnement. Des outils et des scanners automatisés peuvent être utilisés pour détecter ces types de failles de sécurité.
Une application Web contient ce type de vulnérabilité si elle manque les mesures de renforcement de la sécurité dans n'importe quelle partie de l'application, des ports inutiles sont ouverts ou si elle active des fonctionnalités inutiles, des mots de passe par défaut sont utilisés, la gestion des erreurs révèle des erreurs informatives à l'attaquant, il utilise logiciel de sécurité non corrigé ou obsolète, etc. Cela peut être évité en supprimant les fonctionnalités inutiles du code, je.une plate-forme minimale sans fonctionnalités inutiles, documentation, etc., permettant à une tâche de mettre à jour et de corriger les failles de sécurité dans le cadre des processus de gestion des correctifs, l'utilisation d'un processus pour vérifier l'efficacité des mesures de sécurité prises, l'utilisation d'un processus de renforcement reproductible pour faire il est facile de déployer un autre environnement correctement verrouillé.
Ces types de vulnérabilités ou de failles permettent à l'attaquant d'obtenir un accès non autorisé aux données du système, ce qui conduit à la compromission complète du système.
Script intersites (XSS) :
Les vulnérabilités XSS se produisent au moment où une application Web incorpore des données non fiables dans une nouvelle page de site Web sans approbation ou échappement légitime, ou actualise une page de site actuelle avec des données fournies par le client, en utilisant une API de navigateur qui peut créer du HTML ou du JavaScript. Des failles XSS se produisent dans le cas où le site Web permet à un utilisateur d'ajouter un code personnalisé dans un chemin d'URL qui peut être vu par d'autres utilisateurs. Ces failles sont utilisées pour exécuter du code JavaScript malveillant sur le navigateur de la cible. Disons qu'un attaquant peut envoyer un lien à la victime contenant un lien vers le site Web de n'importe quelle entreprise. Cette connexion peut contenir du code JavaScript malveillant. Si la page Web de la banque n'est pas correctement sécurisée contre les attaques XSS, en cliquant sur le lien, le code malveillant sera exécuté sur le navigateur de la victime.
Le Cross-Site Scripting est une vulnérabilité de sécurité présente dans près des ⅔ des applications Web. Une application est vulnérable à XSS si l'application stocke une entrée utilisateur non filtrée qui peut être vue par un autre utilisateur, par l'utilisation de structures JavaScript, d'applications à page unique et d'API qui intègrent puissamment des informations contrôlables par un attaquant sur une page sont impuissantes contre DOM XSS. Les attaques XSS peuvent être atténuées par l'utilisation de frameworks qui échappent et désinfectent les entrées XSS par nature comme React JS, etc., en apprenant les limites des frameworks et en les couvrant en utilisant ses propres cas, en échappant aux données HTML inutiles et non fiables partout où je.e dans les attributs HTML, URI, Javascript, etc, utilisation de l'encodage contextuel en cas de modification du document côté client, etc.
Les attaques basées sur XSS sont de trois types i.e XSS reflété, DOM XSS et XSS stocké. Tous les types de ces attaques ont un impact important, mais dans le cas du XSS stocké, l'impact est encore plus important i.e vol d'identifiants, envoi de malware à la victime, etc.
Désérialisation non sécurisée :
La sérialisation des données signifie prendre des objets et les convertir dans n'importe quel format afin que ces données puissent être utilisées à d'autres fins ultérieurement, tandis que la désérialisation des données signifie le contraire de cela. La désérialisation déballe ces données sérialisées pour l'utilisation d'applications. La désérialisation non sécurisée signifie la trempe des données qui ont été sérialisées juste avant d'être sur le point d'être décompressées ou désérialisées. La désérialisation non sécurisée conduit à l'exécution de code à distance et est utilisée pour effectuer d'autres tâches à des fins malveillantes telles que l'élévation des privilèges, les attaques par injection, les attaques par rejeu, etc. Il existe des outils disponibles pour découvrir ce type de failles, mais une assistance humaine est fréquemment nécessaire pour valider le problème. L'exploitation de la désérialisation est un peu difficile car les exploits ne fonctionneront pas sans quelques modifications manuelles.
Lorsque l'application désérialise les objets malveillants fournis par l'entité attaquante. Cela peut conduire à deux types d'attaques i.e attaques liées à la structure des données et aux objets dans lesquelles l'attaquant modifie la logique de l'application ou exécute du code à distance et attaques typiques de falsification des données dans lesquelles des structures de données existantes sont utilisées avec un contenu modifié, par exemple des attaques liées au contrôle d'accès. La sérialisation peut être utilisée dans la communication de processus à distance (RPC) ou une communication inter-processus (IPC), la mise en cache de données, les services Web, le serveur de cache de bases de données, les systèmes de fichiers, les jetons d'authentification API, les cookies HTML, les paramètres de formulaire HTML, etc. Les attaques de désérialisation peuvent être atténuées en n'utilisant pas d'objets sérialisés provenant de sources non fiables, en mettant en œuvre des contrôles d'intégrité, en isolant le code exécuté dans un environnement peu privilégié, en surveillant les connexions réseau entrantes et sortantes à partir de serveurs qui se désérialisent fréquemment.
Utilisation de composants présentant des vulnérabilités connues :
Différents composants tels que les bibliothèques, les frameworks et les modules logiciels sont utilisés par la plupart des développeurs de l'application Web. Ces bibliothèques aident le développeur à éviter les travaux inutiles et fournissent les fonctionnalités nécessaires. Les attaquants recherchent des failles et des vulnérabilités dans ces composants pour coordonner une attaque. En cas de découverte d'une faille de sécurité dans un composant, tous les sites utilisant le même composant peuvent être vulnérables. Les exploits de ces vulnérabilités sont déjà disponibles tandis que l'écriture d'un exploit personnalisé à partir de zéro demande beaucoup d'efforts. Il s'agit d'un problème très courant et répandu, l'utilisation de grandes quantités de composants dans le développement d'une application Web peut conduire à ne même pas connaître et comprendre tous les composants utilisés, corriger et mettre à jour tous les composants est un long chemin à parcourir.
Une application est vulnérable si le développeur ne connaît pas la version d'un composant utilisé, le logiciel est obsolète i.e le système d'exploitation, les SGBD, les logiciels en cours d'exécution, les environnements d'exécution et les bibliothèques, l'analyse des vulnérabilités n'est pas effectuée régulièrement, la compatibilité des logiciels patchés n'est pas testée par les développeurs. Cela peut être évité en supprimant les dépendances, les fichiers, la documentation et les bibliothèques inutilisés, en vérifiant régulièrement la version des composants côté client et côté serveur, en obtenant des composants et des bibliothèques à partir de sources sécurisées officielles et fiables, en surveillant les bibliothèques et les composants non corrigés, en assurant un plan pour mettre à jour et corriger régulièrement les composants vulnérables.
Ces vulnérabilités entraînent des impacts mineurs mais peuvent également conduire à une compromission du serveur et du système. De nombreuses violations importantes reposaient sur des vulnérabilités connues des composants. L'utilisation de composants vulnérables sape les défenses des applications et peut être le point de départ d'une attaque de grande envergure.
Journalisation et surveillance insuffisantes :
La plupart des systèmes ne prennent pas suffisamment de mesures et d'étapes pour détecter les violations de données. Le temps de réponse moyen d'un incident est de 200 jours après qu'il s'est produit, c'est beaucoup de temps pour faire toutes les choses désagréables pour une entité attaquante. Une journalisation et une surveillance insuffisantes permettent à l'attaquant d'attaquer davantage le système, de maintenir son emprise sur le système, de falsifier, de conserver et d'extraire des données selon les besoins. Les attaquants utilisent le manque de surveillance et de réponse en leur faveur pour attaquer l'application Web.
Une journalisation et une surveillance insuffisantes se produisent à tout moment i.Les journaux d'applications non surveillés pour les activités inhabituelles, les événements auditables tels que les tentatives de connexion infructueuses et les valeurs de transaction élevées ne sont pas correctement enregistrés, les avertissements et les erreurs génèrent des messages d'erreur peu clairs, aucune alerte de déclenchement en cas de test de pente à l'aide d'outils DAST automatisés, impossible de détecter ou alerter rapidement les attaques actives, etc. Ceux-ci peuvent être atténués en s'assurant que toutes les connexions, les échecs de contrôle d'accès et la validation d'entrée côté serveur peuvent être enregistrés pour identifier le compte d'utilisateur malveillant et conservés pendant une durée suffisante pour une enquête médico-légale retardée, en veillant à ce que les journaux générés soient dans un format compatible avec les solutions de gestion centralisée des journaux, en assurant des contrôles d'intégrité sur les transactions de grande valeur, en mettant en place un système d'alertes opportunes d'activités suspectes, etc.
La plupart des attaques réussies commencent par la vérification et la recherche de vulnérabilités dans un système, permettre à ces recherches de vulnérabilité peut compromettre l'ensemble du système.
Conclusion:
Les vulnérabilités de sécurité dans une application Web affectent toutes les entités liées à cette application. Ces vulnérabilités doivent être prises en compte pour fournir un environnement sûr et sécurisé aux utilisateurs. Les attaquants peuvent utiliser ces vulnérabilités pour compromettre un système, s'en emparer et élever les privilèges. L'impact d'une application Web compromise peut être visualisé, du vol d'informations d'identification de carte de crédit et de l'usurpation d'identité à la fuite d'informations hautement confidentielles, etc. en fonction des besoins et des vecteurs d'attaque des entités malveillantes.
