Ceux d'entre vous qui lisent cette série de blogs peuvent remarquer de nombreuses similitudes entre la vulnérabilité d'inclusion de fichiers à distance et la vulnérabilité d'inclusion de fichiers locaux et de traversée de chemin dont il a été question précédemment. Leurs causes profondes sont similaires, tout comme les correctifs recommandés.

À bien des égards, la vulnérabilité d'inclusion de fichiers à distance est beaucoup plus dangereuse, et aussi plus facile à exploiter, que son équivalent local. C'est pourquoi il convient de la détecter et d'y remédier dès que possible. Ou mieux encore, les applications web devraient être conçues de manière à éviter qu'elle ne se produise.

Dans cet épisode, vous apprendrez

• Comment les pirates exploitent la vulnérabilité d'inclusion de fichiers à distance
• Pourquoi il est dangereux d'autoriser l'inclusion de fichiers à distance
• Les techniques permettant de résoudre ce problème.

Comment les attaquants exploitent-ils l'inclusion de fichiers à distance ?

La vulnérabilité d'inclusion de fichiers à distance tire parti de la commande ou du mécanisme d'inclusion dynamique de fichiers qui existe dans la plupart des cadres de programmation. Cette capacité est destinée à permettre aux développeurs d'utiliser des fichiers situés sur un serveur secondaire pour exécuter des activités sur le serveur d'application. Il est évident que cela peut s'avérer dangereux entre de mauvaises mains.

Les attaquants exploitent cette capacité en trouvant un site web ou une application qui permet une entrée utilisateur incontrôlée, qui peut provenir d'éléments tels que des en-têtes HTTP ou des zones d'entrée dans des formulaires interactifs. Ils s'en servent comme point de départ pour générer des commandes d'inclusion de fichiers.

Par exemple, si un site utilise la fonction GET pour charger des pages, comme page = request.getParameter("page") ; include page ; un pirate pourrait alors envoyer une requête en utilisant la commande page, mais avec l'URL d'un site qu'il contrôle et le chemin d'accès au fichier qu'il veut exécuter. La requête est alors transmise au serveur et le fichier distant est exécuté sur l'hôte. L'activité est autorisée car elle fait désormais partie de l'application de confiance.

Pourquoi la vulnérabilité d'inclusion de fichier à distance est-elle dangereuse ?

Le niveau de danger posé par l'inclusion de fichiers à distance est extrêmement élevé. Contrairement aux vulnérabilités liées à l'inclusion de fichiers locaux, où les fichiers qu'un attaquant exécute doivent exister sur un hôte et être trouvés par l'attaquant par tâtonnement, l'inclusion de fichiers à distance n'est soumise à aucune restriction de ce type. Il est évident qu'un attaquant connaît l'emplacement des fichiers qu'il veut exploiter puisqu'ils existent probablement sur ses propres machines ou sur des sites qu'il contrôle. Les fichiers peuvent également être choisis par le pirate et n'ont pas besoin d'exister sur la machine cible avant l'exploitation. Le fichier peut même consister en des scripts spécifiquement écrits pour exploiter un hôte distant.

En bref, une fois qu'un attaquant est en mesure de trouver et d'exploiter une vulnérabilité d'inclusion de fichier à distance, rien ne l'empêche de prendre le contrôle total d'une application ou même d'un site entier. Il est certain qu'aucune donnée stockée ne sera à l'abri de leur incursion.

Suppression de la vulnérabilité d'inclusion de fichiers à distance

Ne permettez jamais à l'utilisateur de passer directement à une commande d'inclusion de fichier pour l'exécuter. Utilisez plutôt une carte de référence indirecte des commandes et n'exécutez les commandes qu'à partir de cette carte. Une carte de référence indirecte associe les données non fiables de l'utilisateur à un ensemble de valeurs fiables codées en dur sur le serveur. Veillez à mettre sur liste blanche toutes les zones où les utilisateurs peuvent saisir des données, et n'oubliez pas d'inclure dans cette liste les en-têtes HTTP, les paramètres des formulaires et même les cookies. Cela fermera toute fenêtre qu'un attaquant cherchant à créer une commande d'inclusion de fichier pourrait utiliser.

En prime, une vérification et une validation appropriées du contenu généré par l'utilisateur et l'utilisation de cartes de référence pour exécuter des commandes permettront non seulement d'éliminer la vulnérabilité d'inclusion de fichiers à distance, mais aussi un certain nombre d'autres vulnérabilités, y compris la dangereuse cousine de ce bogue, l'exploit d'inclusion de fichiers locaux et de traversée de chemin d'accès.

Plus d'informations sur l'inclusion de fichiers à distance

Pour en savoir plus, vous pouvez consulter le guide de référence de l'OWASP sur les exploits d'inclusion de fichiers à distance. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Contrairement à de nombreuses vulnérabilités, l'exploitation des processus d'inclusion de fichiers locaux et de traversée de chemin à des fins malveillantes nécessite un attaquant suffisamment habile, beaucoup de temps et peut-être un peu de chance. Cela ne veut pas dire que cette vulnérabilité peut être ignorée. Des attaquants habiles peuvent l'utiliser pour retourner des fichiers internes contre une organisation, cartographier une structure de répertoire ou même voler des mots de passe et des informations sur les utilisateurs qui peuvent être utilisés pour des attaques secondaires dangereuses.

Dans cet épisode, vous apprendrez

• Comment les pirates exploitent les vulnérabilités liées à l'inclusion de fichiers locaux et à la traversée de chemins d'accès
• Pourquoi il peut être dangereux d'autoriser l'inclusion de fichiers locaux sans restriction et la traversée de chemins d'accès ?
• Les politiques et les techniques qui peuvent être employées pour trouver et résoudre ce problème.

Comment les attaquants exploitent-ils l'inclusion de fichiers locaux et le détournement de chemin ?

Le célèbre détective de télévision Columbo avait l'habitude de dire "Encore une chose" juste avant de livrer une information précieuse qui permettrait d'élucider l'affaire en cours. Cette information semblait sans importance à ce moment-là et était presque toujours ignorée par le suspect, mais elle s'avérait toujours être sa perte. Les vulnérabilités d'inclusion de fichiers locaux et de traversée de chemin ressemblent beaucoup à cela.

Les vulnérabilités d'inclusion de fichier local et de traversée de chemin utilisent le mécanisme d'inclusion de fichier dynamique qui existe dans la plupart des cadres de programmation tels que les scripts ASP, JSP et PHP. Pour l'inclusion de fichiers locaux, un attaquant glisse le nom d'un fichier qui existe sur le serveur local dans une zone d'une application web telle qu'un en-tête ou une zone d'entrée de formulaire. L'application traite l'entrée principale normalement, mais aussi la commande include(page) ou une commande similaire. Dans le cas de la traversée de chemin, l'attaquant définit le chemin d'accès à un fichier suspect, en utilisant normalement les caractères point, point et barre oblique (../) comme variables. C'est un peu comme Columbo : le pirate ne se préoccupe pas de la première partie de l'argument. C'est simplement un moyen pour eux d'ajouter "juste une chose de plus" à la fin.

Dans les deux cas, l'attaquant doit normalement procéder par tâtonnements. À moins qu'il ne connaisse très bien la structure du site, deviner les configurations de chemins et les noms de fichiers peut prendre beaucoup de temps. Cela dit, la plupart des sites suivent des modèles spécifiques et ont des répertoires et des noms de fichiers plus ou moins similaires. Il se peut donc que cela ne prenne pas autant de temps que vous le pensez. Et comme le paiement est potentiellement très lucratif, les pirates ont tout intérêt à essayer d'exploiter les vulnérabilités d'inclusion de fichiers locaux et de traversée de chemin d'accès une fois qu'elles sont trouvées.

Pourquoi les vulnérabilités d'inclusion de fichier local et de franchissement de chemin sont-elles dangereuses ?

Les vulnérabilités liées à l'inclusion de fichiers locaux et à la traversée de chemin sont dangereuses car elles peuvent permettre à des pirates d'accéder à des fichiers sensibles ou critiques. Pour les fichiers de données, le danger est que le pirate puisse obtenir quelque chose de précieux comme les mots de passe des utilisateurs ou d'autres informations personnelles. Les fichiers de mots de passe ou de configuration de l'utilisateur constituent souvent une cible privilégiée, car ils permettent d'accéder au reste du site. Les bases de données sont également des cibles privilégiées. Les vulnérabilités liées à l'inclusion de fichiers locaux et à la traversée de chemins peuvent permettre à un pirate de voler tout le contenu d'une base de données dans le pire des cas.

Pour les fichiers exécutables, le danger est que l'accès à ces fichiers peut permettre à un attaquant d'effectuer des activités malveillantes telles que la destruction d'une partie d'un site ou même de monter un type d'attaque interne par déni de service en gaspillant les ressources du système. Mais l'étendue du danger n'est limitée que par l'ingéniosité et l'habileté du pirate, et par les fichiers auxquels il peut accéder et qui existent déjà sur le serveur cible.

Élimination de la menace que représentent l'inclusion de fichiers locaux et le détournement de chemin d'accès

Le danger posé par l'inclusion de fichiers locaux et les vulnérabilités de traversée de chemin peut être éliminé grâce à de bonnes pratiques de cybersécurité. La chose la plus importante à retenir est de ne jamais autoriser l'entrée de l'utilisateur dans "file include" ou d'autres commandes ayant des fonctions similaires. Si une application doit l'autoriser, ne la transmettez pas directement. Utilisez plutôt une carte de référence indirecte. Une carte de référence indirecte prend l'entrée de l'utilisateur et l'associe à un ensemble de valeurs de confiance codées en dur qui peuvent ensuite être utilisées en toute sécurité.

Comme pour de nombreuses autres vulnérabilités, accordez une attention particulière à toutes les zones d'entrée contrôlées par l'utilisateur, telles que les cookies, les en-têtes HTTP et les paramètres de formulaire. Les entrées autorisées doivent figurer sur une liste blanche et toutes les autres doivent être explicitement refusées. Lorsque cela n'est pas possible, utilisez la validation d'entrée pour réglementer étroitement les valeurs autorisées telles que les nombres, les valeurs alphanumériques, etc.

Plus d'informations sur l'inclusion de fichiers locaux et le détournement de chemin d'accès

Pour en savoir plus, vous pouvez consulter le guide de test de l'OWASP pour l'inclusion de fichiers locaux et les exploits de traversée de chemin. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Même si vous avez complètement sécurisé un serveur d'application et les systèmes dorsaux qu'il utilise, les communications peuvent toujours être vulnérables à l'espionnage si la protection de la couche transport est insuffisante. Dans le monde physique, la raison pour laquelle les devises fortes sont déplacées à l'aide de véhicules blindés est qu'elles sont protégées pendant leur transit. La sécurité d'un magasin ou d'une banque importe peu si l'argent qu'il génère est chargé dans une voiturette de golf pour être transporté à l'autre bout de la ville.

Il en va de même pour les couches de transport dans le domaine cybernétique. Même si une application est sécurisée, il existe toujours une vulnérabilité critique si les informations qui lui parviennent sont envoyées sans protection. Certaines applications présentent une deuxième vulnérabilité si elles envoient en outre des informations à d'autres serveurs ou à une base de données. Ces informations peuvent être exposées à des initiés qui n'ont rien à faire pour espionner ces transactions.

Pour protéger pleinement les utilisateurs et les données, il faut protéger la couche de transport. Ce n'est qu'à cette condition que vous pourrez sécuriser l'ensemble d'une transaction de bout en bout.

Dans cet épisode, vous apprendrez

• Comment les pirates peuvent exploiter une protection insuffisante de la couche transport
• Pourquoi le fait de ne pas protéger la couche transport est si dangereux
• Ce qui peut être fait pour sécuriser le transport de toutes les données qui entrent et sortent d'une application ou d'un serveur.

Comment les attaquants exploitent-ils une protection insuffisante de la couche transport ?

Une protection insuffisante de la couche transport peut permettre des attaques en deux points de votre flux de données. Le point le plus couramment exploité se situe entre un utilisateur et le serveur d'application. Si des informations sont envoyées en clair, ou avec un faible cryptage, les pirates pourront surveiller, voler et éventuellement modifier ces informations. Les pirates peuvent ainsi voler la carte de crédit d'un utilisateur, ses identifiants de connexion ou tout autre élément envoyé au serveur d'application. Même si le serveur lui-même est sécurisé, un pirate informatique surveillant le canal non sécurisé entre le serveur et les utilisateurs pourrait obtenir un accès presque illimité à de nombreuses informations.

Le deuxième point qui n'est souvent pas protégé est la couche de transport entre une application et le reste du réseau. Par exemple, un serveur d'application peut traiter des commandes d'achats en ligne et les envoyer ensuite à un système d'exécution, ou des données peuvent simplement être transférées vers une base de données pour y être stockées. Si ces canaux internes ne sont pas protégés, les utilisateurs internes pourraient être en mesure de voir ces informations.

S'il est agréable de croire que tous les utilisateurs internes sont de bonnes personnes, il n'en reste pas moins que les menaces internes sont en augmentation dans de nombreux secteurs d'activité. Des initiés ont été surpris en train d'accepter des pots-de-vin en échange de la collecte d'informations sensibles pour des attaquants ou des concurrents. Et avoir accès à des milliers de cartes de crédit valides peut être tout simplement trop tentant pour certaines personnes.

En termes de techniques d'attaque, il n'est pas très difficile d'intercepter des communications non protégées. Même les pirates de bas niveau savent comment effectuer des attaques de type "man-in-the-middle" contre des flux de données non chiffrés. S'ils ne le savent pas, il existe des vidéos en ligne qui leur permettent de se former en moins d'une demi-heure.

Pourquoi les vulnérabilités liées à une protection insuffisante de la couche transport sont-elles si dangereuses ?

Une protection insuffisante ou inexistante des couches de transport est dangereuse car elle permet aux pirates de recueillir très facilement des informations sensibles. Ils n'ont pas besoin de s'introduire dans votre serveur d'applications ou de pirater votre réseau. Il leur suffit de mettre en place une attaque de type "man in the middle" et de lire tout ce que les utilisateurs envoient à un serveur. Il peut s'agir de noms d'utilisateur et de mots de passe qui peuvent être utilisés pour contourner la sécurité à l'avenir en utilisant des informations d'identification valides. Selon l'application, il peut également s'agir d'informations relatives aux cartes de crédit ou d'autres données personnelles concernant les utilisateurs.

Il est important de noter que tous ces espionnages ont lieu en dehors de votre réseau. Si vous utilisez des canaux de transport non sécurisés, il n'y a aucun moyen de savoir si quelqu'un capture ces informations. Normalement, le premier signe est lorsque de nombreux utilisateurs commencent à signaler des comptes compromis ou des achats par carte de crédit, et le facteur commun est que votre application " n'est pas un bon endroit où se trouver ". Les pirates peuvent également modifier les informations une fois qu'ils les ont, en changeant l'adresse de livraison par exemple, ou même en insérant des scripts malveillants dans la réponse du serveur avant de la transmettre aux utilisateurs.

Au niveau du backend, le fait de ne pas sécuriser la couche de transport expose les données à des initiés. Il est probablement beaucoup moins probable qu'un initié espionne la couche de transport que des pirates de l'extérieur qui font la même chose. Mais c'est aussi plus dangereux si cela se produit, parce que la menace interne pourra voir non seulement les données de l'utilisateur, mais aussi toute information propriétaire ajoutée par le serveur d'application avant d'envoyer ces paquets.

Élimination des vulnérabilités liées à une protection insuffisante de la couche transport

Aussi dangereuse que puisse être une protection insuffisante de la couche de transport, il n'est pas incroyablement difficile de sécuriser correctement tous vos canaux de transport. Cela commence par l'infrastructure dorsale. Celle-ci doit être exclusivement HTTPS, veillez à ne pas mélanger HTTPS et HTTP sur un site. Enfin, maintenez un certificat SSL valide avec une taille de clé minimale de 2048 bits tout en forçant tous les utilisateurs à interagir avec des navigateurs sécurisés avec HTTP Strict Transport Security (HSTS).

Une fois l'infrastructure en place, les développeurs doivent utiliser un protocole solide pour protéger la couche de transport. L'idéal est d'utiliser TLS 1.2, bien que TLS 1.1 et 1.0 soient également acceptables en cas d'absolue nécessité. Une fois ce protocole en place, les protocoles faibles comme SSLv2 doivent être complètement désactivés et ne jamais être pris en charge.

Il convient également de veiller à ce que les algorithmes de chiffrement soient suffisamment puissants au niveau du backend. Idéalement, la taille minimale de la clé de session devrait être de 128 bits. Comme pour les protocoles, la prise en charge d'algorithmes cryptographiques faibles tels que DES et RC4-40 doit être désactivée. Enfin, ne considérez pas une application comme réellement sûre tant que le serveur lui-même et tous les chemins de données qui y mènent et qui en partent ne sont pas suffisamment protégés.

Plus d'informations sur les vulnérabilités de la protection de la couche de transport insuffisante

Pour en savoir plus, vous pouvez consulter le guide de l'OWASP sur la protection des couches de transport. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Les attaques par injection XML sont de méchants petits exploits inventés par les pirates pour les aider à compromettre les systèmes hébergeant des bases de données XML. Il s'agit du genre de choses qui viennent à l'esprit lorsque l'on pense aux bases de données traditionnelles - des stocks détaillés d'informations sur n'importe quel sujet, des médicaments aux films. Certaines bases de données XML sont également utilisées pour vérifier les utilisateurs autorisés, de sorte que l'injection d'un nouveau code XML dans ces bases peut créer de nouveaux utilisateurs que le système hôte acceptera à partir de ce moment-là.

Pour qu'un attaquant puisse mettre en œuvre une injection XML, il faut qu'il y ait une application qui repose sur une base de données XML ou qui y accède au moins. Chaque fois que cela se produit et que l'entrée de l'utilisateur n'est pas correctement contrôlée, un nouveau code XML peut être ajouté à la base de données. Selon l'habileté de l'attaquant, l'ajout d'un nouveau code XML peut causer beaucoup de dégâts, voire donner accès à l'ensemble de la base de données.

En poursuivant votre lecture, vous découvrirez peut-être que l'injection XML est étroitement liée aux attaques par injection SQL que nous avons abordées précédemment. En effet, bien qu'elles ciblent des types de bases de données différents, elles sont extrêmement similaires. Et heureusement, les solutions sont également similaires. En apprenant à vaincre un type d'attaque, vous aurez une longueur d'avance dans la prévention de l'autre.

Dans cet épisode, vous apprendrez

• Comment fonctionnent les injections XML
• Pourquoi ils sont si dangereux
• Comment vous pouvez mettre en place des défenses pour les arrêter complètement.

Comment les attaquants déclenchent-ils des injections XML ?

Les injections XML réussissent lorsqu'un utilisateur non autorisé est en mesure d'écrire un code XML et de l'insérer dans une base de données XML existante. Il suffit de deux choses pour que cela fonctionne : une application qui repose sur une base de données XML ou qui s'y connecte, et un chemin d'accès non sécurisé pour que l'attaquant puisse lancer son attaque.

Les injections XML réussissent presque toujours si l'entrée de l'utilisateur n'est pas assainie ou restreinte d'une autre manière avant d'être envoyée à un serveur pour y être traitée. Cela peut permettre aux attaquants d'écrire leur propre code, ou de l'injecter, à la fin de leur chaîne de requête normale. S'ils y parviennent, ils incitent le serveur à exécuter le code XML, ce qui lui permet d'ajouter ou de supprimer des enregistrements, voire de révéler l'intégralité d'une base de données.

Les pirates mettent en œuvre une attaque par injection XML en ajoutant du code XML à une requête normale. Il peut s'agir de n'importe quoi, d'un champ de recherche ou d'une page de connexion. Il peut même inclure des éléments tels que des cookies ou des en-têtes.

Par exemple, dans un formulaire d'inscription, un utilisateur peut ajouter le code suivant après le champ du nom d'utilisateur ou du mot de passe :

<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>

Dans cet exemple, un nouvel utilisateur nommé John_Smith sera créé avec un accès administrateur. Au moins, le nouvel utilisateur applique de bonnes règles de densité de mot de passe. Dommage qu'il s'agisse en fait d'un attaquant.

Les pirates n'ont pas nécessairement besoin de toujours réussir un coup de circuit comme celui-ci pour réussir avec les injections XML. En manipulant leurs requêtes et en enregistrant les différents messages d'erreur renvoyés par le serveur, ils peuvent être en mesure de déterminer la structure de la base de données XML. Ces informations peuvent être utilisées pour améliorer d'autres types d'attaques.  

Pourquoi les injections XML sont-elles si dangereuses ?

Le degré de dangerosité d'une attaque par injection XML dépend des informations stockées dans la base de données XML ciblée ou de la manière dont ces informations sont utilisées. Par exemple, dans le cas d'une base de données XML utilisée pour authentifier les utilisateurs, une injection XML peut permettre à un pirate d'accéder au système. Elle peut même lui permettre de devenir administrateur du réseau ciblé, ce qui est bien sûr une situation extrêmement dangereuse.

Pour les injections XML visant des bases de données plus traditionnelles, le danger réside dans le vol de ces informations, l'ajout de données incorrectes dans le magasin, voire l'écrasement de bonnes données. Le code XML n'est pas très difficile à apprendre et certaines commandes peuvent être extrêmement puissantes, écrasant des champs d'information entiers ou affichant même le contenu d'un magasin de données.

En règle générale, personne ne construit une base de données si les informations qui y sont stockées n'ont pas de valeur. Les pirates informatiques le savent, c'est pourquoi ils les prennent souvent pour cible. Si ces données comprennent des éléments tels que des informations personnelles sur des employés ou des clients, leur compromission peut entraîner une perte de réputation, des conséquences financières, de lourdes amendes, voire des poursuites judiciaires.  

Arrêter les attaques par injection de XML

Les injections XML sont assez courantes en raison du faible degré de difficulté de l'opération et de la prévalence des bases de données XML. Mais ces attaques existent depuis longtemps. Il existe donc plusieurs correctifs infaillibles qui les empêcheront de s'exécuter.

L'une des meilleures méthodes pour mettre fin aux attaques consiste à concevoir une application de manière à ce qu'elle n'utilise que des requêtes XML précompilées. Cela limite la fonctionnalité des requêtes à un sous-ensemble d'activités autorisées. Tout ce qui arrive avec des arguments supplémentaires ou des commandes qui ne correspondent pas aux fonctions de la requête précompilée ne sera tout simplement pas exécuté. Si vous ne souhaitez pas être aussi restrictif, vous pouvez également utiliser le paramétrage. Cela permet de limiter l'entrée de l'utilisateur à des types spécifiques de requêtes et de données, par exemple en n'utilisant que des nombres entiers. Tout ce qui n'entre pas dans ces paramètres est considéré comme non valide et entraîne l'échec de la requête.

Il est également judicieux d'associer des requêtes précompilées ou paramétrées à des messages d'erreur personnalisés. Au lieu de renvoyer les messages d'erreur descriptifs par défaut en cas d'échec de la requête, les applications devraient intercepter ces réponses et les remplacer par un message plus générique. Idéalement, vous souhaitez indiquer à l'utilisateur la raison de l'échec de la requête, sans lui donner d'informations sur la base de données elle-même. Si vous limitez ces messages personnalisés à quelques choix, les pirates ne seront pas en mesure de compiler des informations utiles à partir des requêtes qui ont échoué.

Les injections XML ont connu un grand succès lorsqu'elles ont été développées pour la première fois. Mais compte tenu de l'ancienneté de cette époque, nous pouvons aujourd'hui facilement mettre en place des défenses qui ne peuvent plus être franchies.

Plus d'informations sur XML Injections

Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les injections XML. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

En explorant les sujets abordés dans ces blogs, nous avons découvert un certain nombre de vulnérabilités dangereuses et d'exploits malveillants que les pirates utilisent pour attaquer les réseaux et contourner les défenses. Ils vont de l'exploitation des faiblesses des langages de programmation à l'injection de code sous différents formats, en passant par le détournement de données en transit. Il s'agit d'un large éventail de menaces, mais chaque fois que l'une d'entre elles réussit, il existe souvent un composant commun aux applications de leurs victimes.

L'insuffisance de la journalisation et de la surveillance est l'une des conditions les plus dangereuses qui puissent exister au sein de la structure défensive d'une application. Si cette vulnérabilité ou cette condition existe, presque toutes les attaques avancées lancées contre l'application finiront par réussir. L'insuffisance de la journalisation et de la surveillance signifie que les attaques ou les tentatives d'attaque ne sont pas découvertes avant très longtemps, voire pas du tout. Cela donne aux attaquants le temps nécessaire pour trouver une vulnérabilité utile et l'exploiter.

Dans cet épisode, vous apprendrez

• Comment les attaquants peuvent utiliser une journalisation et une surveillance insuffisantes
• Pourquoi l'insuffisance de la journalisation et de la surveillance est dangereuse
• Techniques permettant de corriger cette vulnérabilité.

Comment les attaquants exploitent-ils les insuffisances en matière de journalisation et de surveillance ?

Dans un premier temps, les attaquants ne savent pas si un système est correctement surveillé ou si les fichiers journaux sont examinés à la recherche d'activités suspectes. Mais il leur est assez facile de le découvrir. Ce qu'ils feront parfois, c'est lancer une forme d'attaque inélégante, de type force brute, par exemple en interrogeant une base de données d'utilisateurs pour trouver les mots de passe les plus couramment utilisés. Ils attendent ensuite quelques jours et tentent à nouveau le même type d'attaque. S'ils ne sont pas empêchés de le faire la deuxième fois, c'est une bonne indication que personne ne surveille attentivement les fichiers journaux à la recherche d'une activité suspecte.

Même s'il est relativement simple de tester les défenses d'une application et d'évaluer le niveau de surveillance active, ce n'est pas une condition nécessaire à la réussite des attaques. Elles peuvent simplement lancer leurs attaques de manière à faire le moins de bruit possible. Le plus souvent, la combinaison d'un trop grand nombre d'alertes, de la fatigue des alertes, de mauvaises configurations de sécurité ou simplement d'une pléthore de vulnérabilités exploitables signifie qu'ils auront largement le temps d'atteindre leurs objectifs avant même que les défenseurs ne se rendent compte de leur présence.

Pourquoi l'insuffisance de la journalisation et de la surveillance est-elle dangereuse ?

L'insuffisance de la journalisation et de la surveillance est dangereuse car elle donne aux attaquants le temps non seulement de lancer leurs attaques, mais aussi d'atteindre leurs objectifs bien avant que les défenseurs ne puissent lancer une riposte. Le délai dépend du réseau attaqué, mais différents groupes comme l'Open Web Application Security Project (OWASP) estiment que le délai de réaction moyen pour les réseaux victimes d'une violation est de 191 jours ou plus.

Pensez-y un instant. Que se passerait-il si des voleurs braquaient une banque, que les gens appelaient la police et que celle-ci mettait six mois à réagir ?

Les voleurs seraient partis depuis longtemps lorsque la police arriverait. En fait, la même banque peut être cambriolée plusieurs fois avant que la police ne réagisse au premier incident.

Il en va de même dans le domaine de la cybersécurité. La plupart des violations très médiatisées dont vous entendez parler dans les journaux ne sont pas des opérations de type "smash and grab". Souvent, l'organisation ciblée n'apprend l'existence d'une violation qu'après que les attaquants ont eu un contrôle plus ou moins total sur les données pendant des mois, voire des années. L'insuffisance de la journalisation et de la surveillance est donc l'une des situations les plus dangereuses qui puissent se produire lorsque l'on essaie de mettre en œuvre une bonne cybersécurité.

Élimination d'une journalisation et d'une surveillance insuffisantes

La prévention d'une journalisation et d'une surveillance insuffisantes nécessite deux choses principales. Premièrement, toutes les applications doivent être créées avec la capacité de surveiller et de consigner les échecs de validation des entrées côté serveur avec suffisamment de contexte utilisateur pour que les équipes de sécurité puissent identifier les outils et les techniques, voire les comptes d'utilisateur, utilisés par les attaquants. D'autre part, ces données doivent être formatées dans un langage tel que STIX (Structured Threat Information eXpression), qui peut être rapidement traité par les outils de sécurité afin de générer les alertes appropriées.

Deuxièmement, il ne suffit pas de générer de bonnes alertes, même si c'est un début. Les organisations doivent également définir les rôles et les responsabilités afin que ces alertes fassent l'objet d'une enquête en temps utile. De nombreuses violations réussies ont en fait déclenché des alertes sur les réseaux attaqués, mais ces alertes n'ont pas été prises en compte en raison de questions de responsabilité. Personne ne savait à qui revenait la tâche de réagir, ou supposait que quelqu'un d'autre s'occupait du problème.

Un bon point de départ pour l'attribution des responsabilités est l'adoption d'un plan de réponse aux incidents et de récupération, comme celui recommandé par le National Institute of Standards and Technology (NIST) dans sa publication spéciale 800-61. Il existe d'autres documents de référence, y compris des documents spécifiques à divers secteurs d'activité, et il n'est pas nécessaire de les suivre à la lettre. Mais il est essentiel d'élaborer un plan définissant qui, au sein d'une organisation, répond aux alertes et comment il s'y prend pour le faire en temps voulu.

Plus d'informations sur l'insuffisance de la journalisation et de la surveillance

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos de l'insuffisance de la journalisation et de la surveillance. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité pour qu'elles deviennent les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Vous êtes prêt à trouver, corriger et éliminer les insuffisances en matière de journalisation et de surveillance dès maintenant ? Rendez-vous sur notre site de formation : [Commencez ici]

Le codage d'un site web ou d'une application avec la capacité de traiter des redirections et des transferts non validés peut être extrêmement dangereux à la fois pour vos utilisateurs et pour votre organisation. Cette erreur courante est souvent exploitée par des pirates qui cherchent à perpétrer des escroqueries par hameçonnage ou à accéder à des pages et à des informations qui seraient normalement restreintes.

Chaque fois qu'une application web est conçue pour renvoyer les utilisateurs vers de nouvelles pages, il y a un risque que ces requêtes soient manipulées ou détournées. Cela peut se produire s'il n'y a pas de processus de validation en place pour empêcher les paramètres de transfert de pointer vers des destinations non souhaitées.

La bonne nouvelle, c'est que les redirections et les transferts non validés sont l'une des vulnérabilités les plus faciles à éliminer de votre environnement. Une fois qu'ils ont été supprimés, vous pouvez prendre quelques mesures simples pour vous assurer qu'ils ne seront plus jamais générés à l'avenir.

Dans cet épisode, vous apprendrez

• Comment les pirates exploitent les vulnérabilités des redirections et des transferts non validés
• Pourquoi il peut être dangereux d'autoriser des redirections et des transferts non validés ?
• Les politiques et les techniques qui peuvent être employées pour trouver et résoudre ce problème.

Comment les attaquants exploitent-ils les redirections et les transferts non validés ?

Les attaquants doivent d'abord trouver une application web qui est configurée pour rediriger les utilisateurs vers une ou plusieurs pages spécifiques. Si la page de destination est définie dans le code, il n'y a pas de vulnérabilité. Par exemple, en Java, il s'agirait d'un moyen sûr et prédéfini d'envoyer un utilisateur vers un nouvel emplacement sans qu'il ait à effectuer une quelconque action, telle que cliquer sur un lien hypertexte.

response.sendRedirect("http://www.knownsafesite.com") ;

La vulnérabilité se produit si le site est programmé pour accepter la saisie de l'utilisateur pour la redirection, ou si le paramètre est laissé ouvert, peut-être pour obtenir l'information à partir d'une autre source. Par exemple, un développeur pourrait utiliser le paramètre "url'GET".

response.sendRedirect(request.getParameter("url")) ;

Bien que cela offre une plus grande flexibilité, cela crée également une vulnérabilité au niveau des redirections et des transferts non validés. Les pirates peuvent ajouter des informations après les barres obliques pour déclencher une redirection vers le site de leur choix, par exemple dans le cadre d'un courriel d'hameçonnage. Les utilisateurs voient le domaine de confiance dans la première partie du lien et ne réalisent pas que le site web peut les rediriger vers le site du pirate.

Pourquoi les redirections et les renvois non validés sont-ils si dangereux ?

Le danger posé par l'autorisation de redirections et de transferts non validés peut être important. Pour les utilisateurs, le plus grand danger est de devenir victimes d'attaques par hameçonnage. Parce qu'ils voient l'URL de premier niveau, ils sont plus susceptibles de croire un courriel ou une autre communication de phishing et de cliquer sur un lien. Et si la page vers laquelle ils sont redirigés ressemble à la vraie page, la tromperie peut être très efficace. Ils peuvent partager leur nom d'utilisateur, leur mot de passe ou d'autres informations d'identification sans jamais se douter qu'ils sont manipulés.

Éliminer la menace que représentent les redirections et les renvois non validés

Les redirections et les renvois non validés commencent à se développer pendant le développement d'une application. Ils peuvent être éliminés après coup, mais la façon la plus simple de les éliminer est tout simplement de ne pas autoriser les paramètres utilisateur ou les chaînes ouvertes dans le cadre d'une fonction de redirection ou de transfert. Au lieu de cela, définissez précisément les URL où les utilisateurs seront redirigés, en éliminant les variables et en privant les attaquants de toute marge de manœuvre. Mieux encore, envisagez de ne pas utiliser de redirections et de transferts du tout.

S'il n'y a absolument aucun moyen d'éviter les variables dans le cadre d'une redirection ou d'un processus de transfert, un processus de validation doit être mis en place pour s'assurer que la redirection se fait vers l'une des destinations valides. Enfin, utilisez des valeurs de mappage plutôt que des URL réelles. Les pirates essaieront plutôt d'utiliser des informations d'URL et ne seront probablement pas en mesure de deviner le schéma de mappage même s'ils soupçonnent qu'un tel schéma est utilisé.

Plus d'informations sur les redirections et les transferts non validés

Pour en savoir plus, vous pouvez consulter les pages de référence de l'OWASP sur les redirections et les transferts non validés. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité pour qu'elles deviennent les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Prenez soin des redirections et des transferts non validés une fois pour toutes. Appliquez vos nouvelles connaissances et testez vos compétences sur notre plateforme de formation ludique : [Commencez ici]

Les attaques par injection de code sont parmi les plus courantes, et aussi les plus dangereuses, que rencontrent de nombreux sites web et applications. Elles varient en termes de sophistication et de dangerosité, mais presque tous les sites ou applications qui acceptent des données d'entrée de l'utilisateur peuvent être vulnérables. En fait, presque tous les défenseurs de la cybersécurité seront confrontés à ce type d'attaque à un moment ou à un autre de leur carrière, et probablement à plusieurs reprises.

Une attaque par injection de code peut se produire chaque fois qu'une application ou un site web accepte une entrée de la part des utilisateurs. Il peut s'agir simplement de fournir une fonction de recherche ou de demander à un utilisateur de saisir ses informations d'identification. L'attaque se produit lorsqu'un utilisateur malveillant saisit un code dans le champ ouvert au lieu d'une saisie de texte normale. L'objectif est de faire en sorte que le serveur prenne l'entrée pour un code valide, puis exécute les fonctions souhaitées par l'attaquant.

Si les attaques par injection de code sont extrêmement courantes, les défenses disponibles pour les arrêter le sont tout autant. Dans cet épisode, vous apprendrez

• Comment ils fonctionnent
• Pourquoi ils sont si dangereux
• Comment vous pouvez mettre en place des défenses pour les arrêter.

Comment les attaquants utilisent-ils l'injection de code ?

Bien que les détails spécifiques des attaques par injection de code varient en fonction du langage de programmation utilisé, toute application ou site web peut être vulnérable dès lors qu'il permet à un utilisateur de saisir des données. Des attaques par injection de code ont été déclenchées pour SQL, HTML, XML, CSS et tout autre langage de programmation courant.

Tout d'abord, un attaquant doit localiser le code vulnérable dans une application, normalement à un endroit où les utilisateurs sont autorisés à saisir leurs propres données. Par exemple, ce code prend la fonction PHP eval() et la transmet à un utilisateur pour qu'il la modifie, sans aucune sorte de validation de la chaîne de retour.

$myvar = "varname" ;
$x = $_GET[arg] ;
eval("\$myvar = \$x ;") ;

Un attaquant malin pourrait facilement ajouter sa propre chaîne à la fonction eval, et même exécuter des commandes système s'il le souhaite.

/index.php?arg=1 ; system(id)

Il est important de noter que si les attaques par injection de code peuvent impliquer l'envoi de commandes système, elles ne se limitent pas à cela. En fait, avec les attaques par injection de code, les pirates ne sont limités que par la fonctionnalité du langage lui-même. Dans notre exemple, un pirate pourrait programmer le système ciblé pour qu'il fasse presque tout ce qui est autorisé par le framework PHP.

Pourquoi les attaques par injection de code sont-elles si dangereuses ?

Les attaques par injection de code sont potentiellement très dangereuses en fonction des compétences de l'attaquant. Il peut faire tout ce que le langage de programmation permet, ce qui le met sur un pied d'égalité avec les programmeurs de l'application. Un attaquant peut pratiquement écrire sa propre application et la faire exécuter dans l'environnement cible.

Même les attaquants les moins compétents peuvent être dangereux. Au lieu d'écrire leurs propres applications ou chaînes de code, ils peuvent simplement ordonner au système ciblé d'accepter et d'installer des logiciels malveillants préprogrammés. Cela peut conduire à la défiguration d'un site, à des attaques par ransomware ou même devenir la base d'une campagne d'hameçonnage visant les utilisateurs du site.

La plupart du temps, les attaques par injection de code sont utilisées pour voler des éléments tels que des listes d'utilisateurs et des mots de passe, ou pour obtenir une reconnaissance précieuse dans un système ciblé pour une compromission ultérieure. Mais attention, un programmeur habile peut faire presque n'importe quoi avec une attaque par injection de code, c'est pourquoi il est essentiel que chaque instance potentielle de ces attaques soit découverte et supprimée de votre environnement.

Ne faites confiance à personne ! (Ou du moins, pas les utilisateurs)

Lors de l'élimination des vulnérabilités liées aux attaques par injection de code, le premier endroit à examiner est tout endroit où l'on demande ou autorise une entrée de la part de l'utilisateur. Tout ce qui est saisi par un utilisateur n'est en aucun cas digne de confiance. Si vous autorisez l'entrée d'un utilisateur sans filtrage ou examen, vous invitez en fait les attaquants à tenter de compromettre votre système ou même votre réseau.

Bien que cela ne soit pas toujours possible, la meilleure façon de contrecarrer les attaques par injection de code est d'empêcher les fonctions d'exécuter ou d'interpréter directement les entrées de l'utilisateur. Les utilisateurs peuvent se voir proposer un choix d'options statiques au lieu d'être libres de saisir leurs propres requêtes, l'application étant programmée pour n'accepter que ces choix limités comme étant valides. Il n'est pas toujours approprié de procéder de la sorte, mais lorsque c'est possible, cela permet d'éliminer les injections de code avant qu'elles ne commencent.

Dans les domaines où les utilisateurs doivent saisir leurs propres données, des contrôles stricts doivent être mis en place sur ces données. Partir du principe que tout est une attaque potentielle est un bon point de départ. L'application de politiques de moindre privilège, telles que l'accès des utilisateurs en lecture seule, tant du côté client que du côté serveur, peut empêcher l'exécution de la plupart des codes.

L'autre bonne défense consiste à mettre en place des filtres à l'échelle de l'application et à assainir toutes les entrées de l'utilisateur. Les développeurs sont conscients des attaques par injection de code depuis des années, et il existe des bibliothèques de filtres éprouvés pour chaque cadre et chaque langage. Lorsque vous appliquez ces filtres, veillez à le faire non seulement sur les zones d'entrée utilisateur évidentes ou sur les paramètres courants tels que les commandes Get et Post, mais aussi sur les cookies et les en-têtes HTTP.

Application d'une correction pour l'injection de code

En supprimant les zones d'entrée utilisateur inutiles de votre environnement, en appliquant les principes du moindre privilège et en utilisant les derniers outils de filtrage et d'assainissement pour inspecter et détecter les attaques potentielles, vous pouvez fermer la porte à cette dangereuse vulnérabilité. L'attitude consistant à ne jamais faire confiance aux données saisies par l'utilisateur vous sera également très utile à l'avenir. Faites tout cela et vous aurez une longueur d'avance sur ce type d'attaque dangereuse.

Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur l' injection de code. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité pour qu'elles deviennent les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Affrontez l'injection de code de front, dès maintenant. Relevez le défi sur notre plateforme de formation ludique : [Commencez ici]

Lorsque vous créez une application professionnelle, qu'elle soit destinée à un usage interne ou à un usage externe par vos clients, vous ne permettez probablement pas à chaque utilisateur d'exécuter toutes les fonctions. Si c'est le cas, vous risquez d'être vulnérable à un contrôle d'accès défaillant.

Voyons ce qu'est un contrôle d'accès défaillant, pourquoi il est si dangereux et comment y remédier.

Comprendre le contrôle d'accès défaillant

Un contrôle d'accès défaillant se produit lorsque le code de l'application ne comporte pas les contrôles de sécurité ou d'accès appropriés. Il peut également se produire lorsqu'une application est mal configurée d'une manière ou d'une autre, permettant l'accès à des fonctions ou à des pages auxquelles l'utilisateur ne devrait pas avoir accès.

Si vous gérez les finances de votre entreprise, vous avez peut-être la possibilité de déposer de l'argent sur certains comptes ou de transférer de l'argent entre les comptes de votre entreprise. En revanche, vous ne devez pas avoir le droit de retirer de l'argent de ces comptes ou de transférer de l'argent vers d'autres comptes. Si les contrôles d'accès appropriés ne sont pas présents, vos employés peuvent être en mesure d'exécuter plus de fonctions que nécessaire.

Ces contrôles peuvent être effectués dans le code ou dans les fichiers de configuration. Par exemple, il peut y avoir des fichiers de configuration XML qui indiquent au cadre de l'application web quels utilisateurs sont autorisés à accéder à quelles pages. Cela permet de s'assurer que les utilisateurs ne peuvent accéder qu'aux fonctions qu'ils sont autorisés à utiliser.

Pourquoi un contrôle d'accès défaillant est dangereux

Prenons l'exemple suivant : Un attaquant s'est rendu compte que votre code de création de compte utilisateur peut être manipulé, ce qui lui permet de créer un utilisateur admin avec une simple requête post. Il peut envoyer une requête avec le nom d'utilisateur et le mot de passe, puis les modifier en cours de route pour inclure le rôle d'administrateur dans l'URL en tant que paramètre ou dans le corps de la requête. L'attaquant se connecte à l'application et obtient instantanément les droits d'administrateur.

Il n'est pas toujours nécessaire qu'un attaquant malveillant pénètre dans un système. En l'absence de contrôles d'accès appropriés, des informations sensibles qui ne devraient pas être partagées entre les services peuvent être divulguées. Imaginez que n'importe quel employé de l'entreprise puisse consulter les données salariales ou financières des ressources humaines. Que se passerait-il si n'importe quel employé pouvait voir que des licenciements sont à venir en raison de la mauvaise situation financière de l'entreprise ? Cela pourrait nuire à votre moral et à la réputation de votre entreprise.

Les informations sensibles des clients peuvent également être perdues. Les entreprises stockent souvent des informations personnelles sur les clients qui utilisent leurs services. Veillez à ne pas exposer accidentellement ces informations en raison d'un manque de contrôle d'accès. Par exemple, si votre système permet aux utilisateurs de demander leur dossier médical, ont-ils également la possibilité de demander et de consulter les informations médicales d'autres personnes ? Si l'URL contient un numéro d'identification de client, les attaquants pourraient incrémenter ce numéro d'identification de client encore et encore jusqu'à ce qu'ils en trouvent un qui corresponde à un autre client, révélant ainsi leurs données personnelles.

Défier le contrôle d'accès défaillant

Le contrôle d'accès basé sur les rôles (RBAC) est un outil très efficace pour mettre en œuvre un contrôle d'accès solide. Ceux qui utilisent Active Directory connaissent peut-être l'idée de créer des groupes et d'accorder l'accès à certains éléments à l'ensemble du groupe, plutôt qu'à l'individu. Les applications fonctionnent de la même manière, en utilisant des rôles pour définir qui est autorisé à voir quoi.

Cela présente deux avantages. Premièrement, il n'est pas nécessaire de modifier une fonction lorsque quelqu'un quitte le rôle d'administrateur. Si quelqu'un était auparavant administrateur et ne doit plus l'être, il vous suffit de placer une nouvelle personne dans le rôle d'administrateur et de retirer la personne précédente de ce rôle. Le code vérifie si l'utilisateur a le rôle d'administrateur au lieu de vérifier si chaque utilisateur a accès à une certaine page ou fonction.

Le deuxième avantage est d'éviter un cauchemar en matière de maintenance. Un contrôle d'accès si granulaire que chaque personne est associée à toutes les fonctions ou pages possibles sera impossible à gérer au fil du temps. Les rôles facilitent grandement les choses, car plusieurs personnes peuvent être ajoutées à un rôle. Un rôle peut inclure l'ensemble de l'entreprise, tandis qu'un autre peut n'inclure que cinq personnes. Cela rend la gestion des rôles plus efficace, car il y aura moins de rôles à gérer. Une entreprise de 10 000 personnes pourrait n'avoir que 100 rôles au lieu de 10 000 fois le nombre de fonctions de votre application. Faites des recherches sur le cadre d'application que vous avez choisi pour voir quelles sont les options disponibles pour un contrôle d'accès robuste.

Il est également essentiel d'utiliser un contrôle d'accès au niveau des fonctions. Protégez l'accès à toutes les fonctions en exigeant des utilisateurs qu'ils passent certains contrôles d'accès. Utilisez le principe du moindre privilège, en refusant l'accès par défaut et en ne l'autorisant qu'en cas de besoin. Il peut être difficile de se rappeler de mettre en place un contrôle d'accès pour chaque fonction. Utilisez un composant central pour gérer et appliquer le contrôle d'accès.

Protégez vos fonctions sensibles

Un contrôle d'accès défaillant peut rendre vos données et votre application vulnérables aux attaques et à l'exploitation. Les données des clients qui ne sont pas protégées correctement peuvent conduire à une violation massive des données, nuisant à votre réputation et à votre chiffre d'affaires.

Un contrôle d'accès défaillant peut également conduire à la prise de contrôle d'un compte si les attaquants sont en mesure d'accéder à des fonctionnalités auxquelles ils ne devraient pas avoir accès. En utilisant un contrôle d'accès fonctionnel approprié, vous protégerez votre application contre les attaquants malveillants et même contre les initiés accidentels.

Vous pensez maîtriser l'accès fonctionnel ? Vous pouvez vous mettre au défi de réparer un contrôle d'accès défectueux dès maintenant : [Commencez ici]

L'expression"Loose lips sink ships" est devenue populaire aux États-Unis pendant la Seconde Guerre mondiale. En Grande-Bretagne, on entendait "Careless talk costs lives" ("Les paroles imprudentes coûtent des vies"). L'idée principale de ce dicton était qu'une conversation imprudente sur des informations sensibles pouvait être entendue par des espions et entraîner de graves conséquences.

Le même principe s'applique à la création d'applications web. Lorsque votre application web révèle trop d'informations, il peut être plus facile pour les attaquants de s'y introduire.

Dans ce billet, nous verrons ce qu'est l'exposition à l'information, pourquoi elle est dangereuse et comment l'éviter.

Comprendre l'exposition à l'information

L'exposition d'informations fait référence aux applications web qui exposent des informations internes à des personnes qui ne devraient pas les voir. Il peut également s'agir de l'exposition d'informations sensibles sur les clients par le biais de fichiers journaux ou de l'interface utilisateur. Dans les deux cas, les pirates peuvent utiliser les informations qu'ils trouvent pour attaquer vos systèmes ou vos utilisateurs.

Souvent, la première étape pour un attaquant est d'essayer de créer une erreur dans votre application. Une mauvaise gestion des erreurs et une mauvaise configuration de l'application web conduisent à l'exposition d'informations avec des messages d'erreur. Que se passe-t-il si l'attaquant crée une erreur dans votre application ? Si un message d'erreur technique apparaît, avec des détails techniques tels qu'une trace de pile, vous avez révélé trop d'informations. Ces détails peuvent inclure la base de données que vous utilisez ou la version du serveur d'application que vous utilisez.

La divulgation d'informations sensibles peut se faire d'autres manières. Un formulaire contient-il des champs cachés contenant des informations sensibles ? Les attaquants peuvent simplement consulter la source de la page et voir les valeurs.

En résumé, l'exposition à l'information se produit lorsque des informations qui devraient être réservées à vos utilisateurs sont rendues trop facilement accessibles.

Comprendre pourquoi l'exposition à l'information est dangereuse

Que peut faire un pirate avec les informations exposées par l'application ? Si les informations sont de nature sensible, un pirate pourrait voler des identités ou des identifiants d'utilisateurs. Cela peut entraîner des dommages financiers, des violations de la vie privée et des amendes réglementaires.

Si un attaquant utilise les messages d'erreur pour obtenir des informations sur une application, ces informations pourraient être utilisées dans une attaque future. En fait, le guide de test de l'OWASP comporte une section entière consacrée à la collecte d'informations.

Le guide de test de l'OWASP encourage l'utilisation des moteurs de recherche pour trouver des informations sur votre site web que vous n'auriez peut-être pas souhaitées. Par exemple, vos pages administratives sont-elles exposées aux moteurs de recherche ? Utilisez le fichier robots.txt pour indiquer aux moteurs de recherche de ne pas indexer certaines pages. En même temps, le fichier robots.txt peut aussi laisser filtrer des informations. Des URL sensibles peuvent parfois se trouver dans le fichier robots.txt. Les attaquants retirent le fichier et commencent à apprendre une partie de la structure des répertoires du site.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

Les en-têtes HTTP, les bannières de sites web et même les commentaires dans le code HTML et JavaScript peuvent contenir des informations que les attaquants ne devraient pas voir. Les en-têtes HTTP peuvent révéler les serveurs d'application et les numéros de version. Les attaquants peuvent utiliser ces informations pour trouver des exploits à utiliser contre ces versions spécifiques. Assurez-vous de bien comprendre les différents endroits où les attaquants pourraient trouver vos informations et comment les cacher de manière appropriée.

Combattre l'exposition à l'information

La divulgation d'informations est souvent un problème lié à la configuration des applications web. De nombreux serveurs d'application renvoient par défaut des traces de pile dans les messages d'erreur. Veillez à modifier ce paramètre pour les applications de production afin de rediriger vers une page d'erreur générique tout en enregistrant l'erreur à des fins de dépannage. Les messages d'erreur détaillés ne doivent jamais être renvoyés au navigateur de l'utilisateur.

Si des fichiers nécessaires à l'application contiennent des informations sensibles, veillez à ce qu'un contrôle d'accès approprié garantisse que seule l'application elle-même puisse les lire. Désactivez l'énumération des répertoires sur le serveur et déplacez ces fichiers en dehors du répertoire racine du site web. Cela empêche les attaquants de naviguer vers le fichier à l'aide du navigateur en utilisant une attaque de traversée de répertoire.

Les journaux peuvent être utilisés pour recueillir des informations lorsqu'ils ne sont pas configurés correctement. Lorsqu'une erreur se produit, n'enregistrez pas d'informations sensibles telles que des mots de passe, des jetons de session ou des informations personnelles identifiables (IPI). Si un pirate pouvait accéder aux fichiers journaux, il trouverait un trésor d'informations sensibles à voler. N'enregistrez pas plus que ce qui est nécessaire, c'est-à-dire généralement un identifiant de compte, un message d'erreur détaillé et éventuellement la méthode dans laquelle l'erreur s'est produite ou l'opération exécutée. Partez du principe que les fichiers journaux ne sont pas secrets et que vous ne serez pas tenté d'y placer des informations sensibles.

Ne coulez pas vos applications Web

Auriez-vous vraiment pu, alors que vous parliez à un ami, divulguer des informations qui auraient directement entraîné la perte d'un cuirassé lors de la Seconde Guerre mondiale ? Peut-être pas. Mais pourquoi courir le risque ? C'est la leçon que l'on peut tirer de l'adage "Les lèvres ouvertes font couler les navires".

De même, il n'y a aucune raison d'exposer le fonctionnement interne de votre application web au monde extérieur. Il n'y a aucune raison de voir des numéros de carte de crédit ou des mots de passe entiers. Il n'y a aucune raison de conserver des données PII dans les fichiers journaux. Ne le faites donc pas. Consultez nos ressources pédagogiques pour en savoir plus sur l'exposition des informations.

Gardez le fonctionnement interne de vos applications à sa place. Ne coulez pas vos applications web.

Pensez-vous pouvoir mettre fin à l'exposition à l'information dès maintenant ? Relevez le défi, guerrier : [Commencez ici]