22 vulnérabilités courantes des applications Web à connaître
Publié: 2021-10-14Les entreprises « se déplacent constamment vers la gauche » et profitent des expériences innovantes des clients et des employés fournies par les applications basées sur le cloud. Dans le même temps, les auteurs malveillants révisent continuellement leurs stratégies d'attaque pour s'adapter à ce changement.
Pour préserver la confidentialité et la sécurité des données, il est impératif que les entreprises recherchent une protection contre ces 22 vulnérabilités courantes des applications Web .
Contrôle d'accès endommagé
Les contrôles d'accès sont responsables de la manière dont les utilisateurs interagissent avec les ressources et les données, ainsi que de ce qu'ils peuvent modifier et/ou lire. Une vulnérabilité de contrôle d'accès défectueux est possible lorsque l'utilisateur est capable d'engager les données d'une manière vraiment inutile. Par exemple, si l'utilisateur ne doit être capable que de lire les détails de paiement mais a en fait la possibilité de les modifier, une telle situation illustre un contrôle d'accès brisé. Les attaquants malveillants profitent de cette vulnérabilité pour obtenir un accès non autorisé aux logiciels, réseaux et systèmes. Ils peuvent alors exploiter la situation, accorder à l'ID utilisateur plus d'accès au sein de l'infrastructure, pour compromettre la disponibilité, la confidentialité ou l'intégrité des données.
Authentification endommagée
Les vulnérabilités des applications Web associées à une authentification endommagée ou cassée proviennent également de l'accès des utilisateurs. Dans ce cas, cependant, les attaquants malveillants ont un impact négatif sur les données qui confirment l'identité d'un utilisateur, par exemple en détournant des jetons de session, des clés ou des mots de passe. L'attaquant malveillant obtient un accès non autorisé au logiciel, aux systèmes et aux réseaux car l'organisation n'a pas été en mesure de définir correctement les contrôles de gestion des identités et des accès.
Injection de retour chariot et saut de ligne (CRLF)
Le retour chariot agit comme une commande qui indique le début d'une ligne de code, généralement indiquée par /r. Le saut de ligne, quant à lui, est une commande qui indique la fin d'une ligne de code, généralement indiquée par /n. Comme plusieurs autres logiciels, chaque système d'exploitation utilise différentes combinaisons de retour chariot et de saut de ligne. Lorsque des attaquants malveillants sont impliqués dans des injections CRLF, le code saisi modifie la manière dont l'application Web réagit aux commandes. Cela peut être utilisé pour divulguer des données sensibles ou exécuter du code.
Transformation chiffrée non sécurisée
Cipher, qui est un terme standard pour "algorithme de chiffrement", est en fait les mathématiques derrière un processus de chiffrement ou de déchiffrement. La transformation désigne l'esquisse des opérations effectuées sur l'input pour délivrer l'output attendu. Ainsi, une transformation de chiffrement fait référence au nombre d'opérations qui convertissent des données chiffrées illisibles en données lisibles et déchiffrées. Une vulnérabilité non sécurisée de transformation de chiffrement décrit que l'algorithme de chiffrement peut être facilement brisé, sabotant finalement l'essence du chiffrement dans un premier temps.
Composants présentant des vulnérabilités évidentes
Chaque application Web dépend d'autres composants pour fonctionner. Par exemple, si vous exploitez une application sur un serveur Web ou d'application non corrigé, le serveur est la partie présentant des vulnérabilités évidentes. La liste CVE (Common Vulnerabilities and Exposures) comprend toutes les vulnérabilités de sécurité connues. Étant donné que les attaquants malveillants ont connaissance de la liste, ils recherchent fréquemment des composants sans mises à jour de correctifs de sécurité adéquates. Dès qu'ils peuvent infiltrer un composant de l'application Web, ils peuvent également accéder aux données de l'application.
Politique de partage des ressources d'origine croisée (CORS)
Toutes les applications Web utilisent une URL comme moyen de connecter le navigateur de l'utilisateur à son serveur. La politique de même origine est une protection commune. Conformément à cela, le serveur ne répondra qu'à une URL avec le même protocole, schéma de chemin et nom de domaine de premier niveau. Cela signifie que vous pouvez accéder à http://organization.com/page1 et http://organization.com/page2, car ils partagent tous les deux les éléments suivants :
- Protocole : HTTP
- Domaine : Entreprise.com
- Schéma du chemin : /page#
Bien qu'elle soit sécurisée, la politique de même origine est restrictive lorsqu'il s'agit d'applications Web qui nécessitent un accès à des ressources qui se connectent à des tiers ou à des sous-domaines.
Une politique CORS accorde au navigateur l'autorisation d'afficher ces ressources interdépendantes en établissant un certain nombre d'en-têtes HTTP autorisés considérés comme "de confiance". Par exemple, une application peut devoir extraire des données de deux bases de données sur des serveurs Web distincts. La rédaction d'une liste "autorisée" particulière devient un travail excessif car vous incluez des serveurs supplémentaires. Étant donné que les deux serveurs "partagent" l'application, la société écrit une politique CORS qui permet aux navigateurs de se connecter aux deux. Cependant, si une stratégie CORS n'est pas correctement définie, la stratégie peut laisser les serveurs accorder l'accès à la demande d'un attaquant malveillant.
Gestion des identifiants
Les informations d'identification de l'utilisateur comprennent un ID utilisateur et un mot de passe. L'utilisateur doit fournir les deux éléments d'information dans la page de connexion avant d'obtenir l'accès à une application. Cependant, les bases de données ont tendance à utiliser un cryptage faible ou à conserver les informations en clair. Une mauvaise gestion des informations d'identification permet aux attaquants de voler facilement les informations d'identification et de les exploiter pour obtenir l'accès aux applications Web.
Contrefaçon de requête intersite (CSRF)
Une attaque CSRF utilise des méthodologies d'ingénierie sociale pour inciter un utilisateur à modifier des informations, telles que des mots de passe ou des noms d'utilisateur, dans une application. Un CSRF, contrairement aux attaques de script intersite (XXS) ou aux logiciels malveillants, nécessite qu'un utilisateur soit connecté à l'application qui utilise uniquement des cookies de session pour valider les demandes des utilisateurs ou suivre les sessions. Au moment où l'utilisateur effectue l'action anticipée, l'acteur malveillant utilise le navigateur pour exécuter la partie restante de l'attaque, comme déplacer des fonds, sans que l'utilisateur sache ce qui s'est passé.
Script intersite (XXS)
Contrairement à un CSRF qui nécessite que l'utilisateur soit connecté à une application pour être amené à modifier certaines informations, une attaque XXS nécessite que l'attaquant malveillant saisisse du code dans une page Web, généralement dans certains composants de la page tels qu'une image. Une fois qu'un utilisateur lance la page Web sur son navigateur, le mauvais code commence à se télécharger et à s'exécuter dans le navigateur. Par exemple, le code malveillant peut rediriger l'utilisateur d'un site crédible vers un site illégitime.
Indexation des répertoires
Habituellement, les serveurs Web décrivent tous les fichiers qui y sont enregistrés dans un seul répertoire. Lorsqu'un utilisateur souhaite localiser un fichier particulier dans une application Web, il ajoute généralement le nom du fichier dans la requête. Dans le cas où le fichier n'est pas disponible, l'application présentera à l'utilisateur une liste de tous les fichiers indexés, de sorte que l'utilisateur ait la possibilité de sélectionner autre chose.
Cependant, les fichiers sont automatiquement indexés par les serveurs Web. Lorsque l'application présente une liste de tous les fichiers stockés, un attaquant malveillant profitant des vulnérabilités de l'index du répertoire peut obtenir l'accès aux données qui peuvent lui donner plus d'informations sur le système. Par exemple, ils peuvent se familiariser avec les comptes d'utilisateurs personnels ou les conventions de dénomination. Ces deux points de données peuvent être exploités pour mener des attaques de vol d'informations d'identification ou démêler des informations sensibles.
Traversée de répertoire
Également connue sous le nom d'attaque de retour en arrière, de point-point-barre oblique et d'escalade de répertoire, la vulnérabilité de traversée de répertoire exploite la manière dont une application reçoit les données du serveur Web. Les listes de contrôle d'accès (ACL) limitent généralement l'accès des utilisateurs à certains fichiers donnés dans un répertoire racine. Les attaquants malveillants qui utilisent le mode de vulnérabilité de traversée de répertoire déterminent le format d'URL utilisé par l'application pour demander des fichiers.
Encapsulation
Différente de certaines des autres vulnérabilités d'application Web courantes de la liste, la vulnérabilité d'encapsulation tire parti des failles dans la façon dont un développeur a codé l'application. L'encapsulation est un terme de programmation qui fait référence au regroupement de données et d'actions pouvant être effectuées sur ces données en une seule unité. L'encapsulation sécurise les données en masquant les informations sur l'exécution du code, ce qui offre une meilleure interface utilisateur. Les utilisateurs n'ont pas besoin de savoir comment l'application leur fournit les données ; tout ce dont ils ont besoin, c'est d'y avoir accès.
Par exemple, un développeur d'applications peut inclure des contrôles d'accès, tels que des autorisations de lecture ou d'écriture, dans la capacité d'une application à récupérer des données. Si l'utilisateur demande des informations dans l'application, celle-ci ne fournit que les données auxquelles il a été autorisé à accéder.
Mais si les développeurs ne parviennent pas à définir des limites clairement définies entre les données et les actions effectuées dans divers aspects de l'application, l'application souffre d'une vulnérabilité d'encapsulation. Les attaquants en profitent en envoyant une requête à l'application, sachant qu'une telle action entraînerait un message d'erreur. Ce message d'erreur fournit alors des informations sur la structure de l'application, facilitant davantage de stratégies d'attaque telles que le DOS - déni de service.
Références d'objet directes non sécurisées (IDOR)
Les URL d'application Web sont capables d'exposer le modèle ou le format utilisé pour diriger les utilisateurs vers les emplacements de stockage principaux. Par exemple, une URL peut afficher le modèle/format d'un identifiant d'enregistrement dans un système de stockage tel qu'un système de fichiers ou une base de données.
L'IDOR seul pourrait être une préoccupation à faible risque. Cependant, lorsqu'un IDOR est combiné à un échec de contrôle d'accès, les attaquants ont une chance de frapper avec succès.
Les autres vulnérabilités courantes des applications Web que vous devez connaître sont :
Fractionnement de la réponse HTTP
Il s'agit d'une sorte d'attaque par injection CRLF. HTTP est le processus par lequel les navigateurs envoient des requêtes et les serveurs renvoient les réponses. Dans cette vulnérabilité d'application Web, les attaquants malveillants utilisent les notations CR et LR afin de manipuler la façon dont les navigateurs et les serveurs communiquent entre eux, ce qui envoie une requête mais demande au serveur de « diviser » la réponse en plusieurs parties. Diviser la réponse en deux parties différentes permet à l'acteur malveillant de prendre le contrôle des informations que le serveur fournit en réponse à l'autre partie de la requête. Lorsque ces données demandées sont des données d'identification d'utilisateur ou des informations sensibles, l'acteur malveillant a réussi l'attaque.
Défaut d'injection
Une faille d'injection permet une pléthore de techniques d'attaque diverses. Toute application qui permet aux utilisateurs de mettre à jour la commande shell, l'appel du système d'exploitation ou une base de données peut souffrir d'un défaut d'injection. Les attaquants malveillants exploitent les failles d'injection pour modifier les commandes qui se transforment en actions nouvelles et inattendues au sein de l'application. En tirant parti de ces vulnérabilités, les acteurs malveillants sont capables de créer, mettre à jour, lire ou même supprimer des données.
Vulnérabilité de résumé de message non sécurisée
Il s'agit d'une vulnérabilité cryptographique qui limite l'efficacité du chiffrement. Un résumé de message doit comprendre la fonction de hachage cryptographique. Contrairement au chiffrement, les fonctions de hachage n'exigent pas que l'expéditeur et les utilisateurs utilisent des clés.
Les attaquants malveillants profitent ainsi des vulnérabilités de résumé non sécurisées pour perpétuer «l'attaque par collisions de hachage». L'objectif de l'attaque est de savoir si l'envoi d'une entrée conduit à la génération d'un hachage duplicatif. Si l'action malveillante génère de force un hachage partagé, ils peuvent utiliser ce hachage pour présenter un fichier malin à télécharger. Cela laisse à son tour à l'utilisateur final l'hypothèse que le fichier est légitime.
Protection insuffisante de la couche de transport
La sécurité de la couche de transport (TLS) fait référence au processus par lequel les applications informatiques peuvent « communiquer » en toute sécurité entre elles sur Internet. Un certain nombre d'applications n'utilisent TLS que pendant le processus d'authentification, ce qui rend les données et les informations de session d'identification vulnérables lorsqu'une personne utilise l'application.
Les attaquants peuvent profiter de cette vulnérabilité pour détourner les données lorsqu'elles se déplacent sur Internet entre l'appareil de l'utilisateur et le serveur d'application.
Exécution de code à distance (RCE)
Les vulnérabilités d'exécution de code à distance sont des erreurs de codage dans les applications Web qui permettent à des attaquants malveillants d'insérer du code indépendamment de leur emplacement géographique. Les RCE relèvent d'une catégorie plus large de vulnérabilités d'injection d'applications Web où les attaquants saisissent leur propre code dans une application qui ne confirmera pas les entrées de l'utilisateur, ce qui oblige le serveur à le considérer comme un véritable code d'application. En règle générale, les attaquants malveillants tirent parti des vulnérabilités connues non corrigées et insèrent leur code dans l'application.
Inclusion de fichiers à distance (RFI)
Pour lier des répertoires communs à une application, les développeurs ajoutent des instructions « include » dans leur code. Par exemple, une application peut devoir extraire des données d'une base de données. Plutôt que de le coder manuellement pour obtenir chaque fichier, l'instruction "include" permet de lier l'ensemble du répertoire source afin que tout ce qui y est stocké puisse être utilisé.
Lorsqu'une application Web souffre d'une vulnérabilité RFI, les attaquants peuvent manipuler l'application pour télécharger du code malveillant ou des logiciels malveillants sur la base de données, le serveur ou le site Web.
Mauvaise configuration de la sécurité
La probabilité d'une mauvaise configuration de la sécurité est en effet l'une des vulnérabilités les plus courantes des applications Web aujourd'hui. Cette vulnérabilité se produira généralement en raison de l'incapacité d'une organisation à modifier les paramètres de sécurité par défaut. Les erreurs de configuration de sécurité courantes sont :
- Utiliser des mots de passe ou des comptes par défaut
- Logiciel non corrigé
- Pas de cryptage
- Politiques de pare-feu inadéquates
- Négliger les ressources, fonctionnalités et autres composants inutilisés
Injection SQL
SQL, qui signifie Structured Query Language, est un langage de programmation utilisé pour les bases de données. Il permet la récupération et la manipulation de données pour des bases de données relationnelles. Une vulnérabilité d'injection SQL se trouve sous un plus grand groupe d'entrées utilisateur non vérifiées. Lorsque des acteurs malveillants envoient délibérément de fausses requêtes, l'application Web répond par un message d'erreur qui leur fournit des informations sur la structure et la protection de la base de données.
Activation automatique de la bibliothèque non validée
Afin de gagner du temps lors du codage, les développeurs ont tendance à utiliser des bibliothèques tierces. Dans la plupart des cas, cela leur permet d'utiliser un code pré-testé qui accélère le processus de développement d'applications. Cependant, l'utilisation de code open source accessible au public augmente les risques de sécurité, notamment :
- L'absence de propriété documentée augmente le risque de code malin ajouté
- Projets négligés qui ne sont plus mis à jour
Cette vulnérabilité particulière est de plus en plus répandue, étant donné que plusieurs applications engagent des dépendances de bibliothèques tierces.
Nous espérons que le contenu de ce billet de blog vous a effectivement été utile et perspicace. S'assurer que vous trouvez une solution à la vulnérabilité de l'application Web qui s'applique à votre cas changera la donne dans l'expérience de vos employés et de vos clients.