L'exposition de données sensibles est à l'origine de certaines des violations de données les plus médiatisées et les plus importantes de ces dernières années, comme la violation catastrophique de Marriott, où plus de 300 millions de dossiers de clients ont été volés, et 150 millions d'autres lors de l'attaque d'Equifax. Un niveau moyen de sophistication est requis, et parfois un équipement spécial de la part de l'attaquant, mais il n'est pas trop difficile pour un pirate de réussir dans de nombreux cas, et il existe des outils pour automatiser certaines des fonctions d'attaque.

L'exposition de données sensibles se produit lorsque des informations qui ne sont destinées qu'à un usage autorisé sont exposées à une personne non autorisée dans un état non crypté, non protégé ou faiblement protégé. La plupart du temps, il s'agit de données que les pirates veulent voler, telles que des numéros de cartes de crédit, des identifiants d'utilisateurs, des secrets d'affaires et des informations personnelles qui pourraient être protégées par des lois et des réglementations sectorielles.

Les pirates peuvent voler des informations sensibles si elles sont stockées sans chiffrement ou en attaquant indirectement le système de chiffrement. Au lieu d'essayer de décrypter directement un chiffrement fort, ils volent les clés de chiffrement ou attaquent les données lorsqu'elles passent à un état non chiffré, par exemple lorsqu'elles sont préparées pour le transport.

Dans cet épisode, vous apprendrez

• Comment les attaquants peuvent-ils déclencher l'exposition de données sensibles ?
• Pourquoi l'exposition aux données sensibles est-elle si dangereuse ?
• Techniques permettant de corriger cette vulnérabilité.

Comment les attaquants exploitent-ils l'exposition aux données sensibles ?

L'exposition de données sensibles se produit généralement lorsque les sites n'utilisent pas un cryptage solide de bout en bout pour protéger les données, ou lorsqu'il y a des failles exploitables dans le système de protection. Elle peut également se produire lorsque le chiffrement utilisé est particulièrement faible ou obsolète.

Les pirates essaieront souvent de trouver des moyens de contourner le chiffrement s'il n'est pas généralisé. Par exemple, si une base de données d'identité d'utilisateur stocke des informations dans un état crypté, mais les décrypte automatiquement lorsqu'elles sont récupérées, un pirate pourrait être en mesure d'utiliser l'une des attaques que nous avons couvertes précédemment dans ces blogs, telles que l'injection SQL ou XML, pour ordonner à la base de données d'effectuer le processus de décryptage. Les données seraient alors décryptées pour le pirate, sans effort supplémentaire. Pourquoi essayer d'enfoncer une porte en acier quand vous pouvez simplement voler la clé ?

La faiblesse du cryptage est également un problème. Par exemple, si les cartes de crédit sont stockées à l'aide d'un système de cryptage obsolète, cela peut poser un problème si un pirate informatique est en mesure d'utiliser une vulnérabilité telle que l'inclusion d'un fichier local pour transférer l'ensemble de la base de données sur son ordinateur. Si les données capturées sont protégées à l'aide d'un système de cryptage puissant, tel que le cryptage AES-256 bits, il sera beaucoup plus difficile de les pirater si elles tombent entre les mains d'un hacker. Mais si un cryptage plus faible ou obsolète est utilisé, comme l'ancienne norme DES, un pirate disposant d'un équipement spécial tel qu'un rack d'unités de traitement graphique (GPU) peut s'atteler à casser le cryptage en un temps relativement court.

Pourquoi l'exposition aux données sensibles est-elle dangereuse ?

L'exposition des données sensibles est dangereuse car elle permet à des utilisateurs non autorisés de voir des informations protégées. Si les données n'étaient pas importantes, elles ne seraient pas protégées, de sorte que toute violation de cette protection entraînera des problèmes. Ce n'est jamais une situation à laquelle une organisation souhaite être confrontée.

L'ampleur des problèmes causés par l'exposition de données sensibles dépend du type de données exposées. Si les données relatives à l'utilisateur ou au mot de passe sont volées, elles peuvent être utilisées pour lancer d'autres attaques contre le système. L'exposition d'informations personnelles peut exposer les utilisateurs à des attaques secondaires telles que l'usurpation d'identité ou l'hameçonnage. Les organisations peuvent même se retrouver exposées à de lourdes amendes et à des actions gouvernementales si les données exposées sont légalement protégées par des lois telles que le Health Insurance Portability and Accountability Act (HIPAA) aux États-Unis ou le Règlement général sur la protection des données (RGPD) en Europe.

Éliminer l'exposition aux données sensibles

Pour mettre fin à l'exposition des données sensibles, il faut d'abord assurer un chiffrement solide, actualisé et de bout en bout des données sensibles dans toute l'entreprise. Cela concerne à la fois les données au repos et en transit. Il ne suffit pas de chiffrer les données sensibles lorsqu'elles sont stockées. Si elles ne sont pas chiffrées avant d'être utilisées ou transportées, elles peuvent être exposées à l'aide d'une attaque secondaire qui incite un serveur à les déchiffrer.

Les données en transit doivent toujours être protégées à l'aide de la technologie Transport Layer Security (TLS) afin d'éviter que l'homme du milieu ou d'autres attaques contre les données en mouvement ne les exposent à des risques. Les données sensibles ne doivent jamais être mises en cache, où que ce soit dans le réseau. Les données sensibles doivent être soit stockées avec un cryptage fort, soit envoyées en utilisant la protection TLS, ce qui ne laisse aux attaquants aucun point faible à exploiter.

Enfin, faites l'inventaire des types de données sensibles qui sont protégées par votre organisation. S'il n'y a aucune raison pour que votre organisation stocke ces données, jetez-les. Pourquoi vous exposer à des problèmes potentiels sans aucun avantage possible ? Les données qui ne sont pas conservées par une organisation ne peuvent pas lui être volées.

Plus d'informations sur l'exposition aux données sensibles

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos de l'exposition des données sensibles. 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 .

L'attaque par injection d'entité externe XML, parfois simplement abrégée en injection XXE, est relativement récente par rapport à certaines vulnérabilités classiques qui font encore parler d'elles des années après leur apparition. Mais elle est extrêmement populaire parmi les communautés de pirates informatiques et le devient de plus en plus au fur et à mesure qu'elle accumule les succès.

En fait, l'OWASP classe désormais l'injection XXE parmi les dix principales vulnérabilités que les sites doivent surveiller et contre lesquelles ils doivent se défendre activement. Mais ne vous inquiétez pas, l'injection XXE n'est pas plus puissante que les autres exploits déployés dans les cyberattaques. Elle est simplement un peu plus récente et un peu moins bien comprise. Il est possible de l'éviter et, en fait, de l'arrêter complètement.

Dans cet épisode, vous apprendrez

• Comment les attaquants utilisent les injections XXE
• Pourquoi l'injection XXE est-elle dangereuse ?
• Techniques permettant d'éviter cette vulnérabilité.

Comment les attaquants déclenchent-ils une injection XXE ?

La vulnérabilité de l'injection XXE peut se produire lorsqu'un utilisateur malveillant a la possibilité de soumettre un code XML. Il utilise cette capacité pour créer une référence à une entité externe. La référence externe et le code sont conçus pour contourner un analyseur XML avec des paramètres par défaut ou faiblement configurés.

L'attaquant exploite le fait que la norme XML définit le concept d'entité comme une unité de stockage d'un certain type, mais que ce stockage peut être externe ou interne. Utilisé correctement, il peut permettre aux processeurs XML d'accéder à des ressources distantes. Le plus souvent, les attaquants utilisent cette capacité pour sonder la structure interne d'un site web, lancer une attaque par déni de service en déclenchant de gros processus système essayant d'accéder à des ressources distantes, ou même décharger des données d'un hôte local vers un hôte distant qu'ils contrôlent " ce qui en fait une bonne technique pour exfiltrer des données importantes comme les mots de passe ou les informations personnelles contenues dans la base de données XML.

Le code utilisé pour l'attaque est souvent assez simpliste, se contentant d'exploiter la fonctionnalité de l'entité. Par exemple, cela pourrait permettre à un pirate d'accéder au fichier du mot de passe principal :

<!ENTITY hackwithxxe SYSTEM file:///etc/password>

Pourquoi l'injection XXE est-elle dangereuse ?

Il y a plusieurs raisons pour lesquelles les attaques par injection XXE sont si dangereuses et si répandues. Tout d'abord, il s'agit d'une vulnérabilité moins bien comprise à l'heure actuelle. Et les gains qu'un attaquant peut réaliser en l'exploitant sont considérables. D'une part, elle peut permettre à des attaquants persistants de cartographier lentement tous les chemins d'un réseau interne ou même de scanner les ports. Bien que cela puisse prendre un certain temps, il n'y a pratiquement aucune chance que l'activité d'un pirate soit découverte par des défenses actives sur le réseau cible parce qu'il envoie simplement du code XML dans un serveur qui est nettoyé par l'analyseur XML de confiance.

Une fois qu'ils ont établi leur plan, les attaquants peuvent utiliser les mêmes techniques d'injection XXE pour s'emparer des fichiers dont ils ont besoin, soit en volant directement des informations, soit en compromettant les informations d'identification des utilisateurs valides et en les utilisant pour des attaques secondaires. Enfin, les attaquants qui veulent simplement faire du bruit et être malveillants peuvent par exemple déclencher des attaques par déni de service, en ordonnant à l'application d'essayer d'accéder à des ressources distantes conçues pour bloquer le système.  

Élimination de la vulnérabilité de l'injection XXE

En raison de l'augmentation rapide des attaques par injection XXE, de nombreux analyseurs XML commencent à désactiver complètement par défaut les entités externes, parfois appelées DTD. Pour ceux-là, la clé consiste simplement à ne pas activer cette fonctionnalité.

Mais même les analyseurs qui autorisent les DTD peuvent avoir cette fonctionnalité désactivée. En général, une instruction comme la suivante est nécessaire pour la bloquer complètement, mais vérifiez la documentation de votre framework local pour obtenir le code exact nécessaire.

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) ;

Conformément aux principes de sécurité, toutes les entrées utilisateur doivent être assainies et validées à l'aide de filtres applicables à l'ensemble de l'application. N'oubliez pas d'inclure les paramètres GET et POST, les en-têtes HTTP et les cookies. Vous pouvez également créer une liste blanche de DTD et de commandes spécifiques que vous souhaitez que l'analyseur traite, et interdire tout le reste.

Bien que la liste blanche et le filtrage fonctionnent, en raison du nombre croissant d'attaques par injection de XXE, il est recommandé de désactiver complètement la prise en charge de la DTD si cette fonctionnalité n'est pas nécessaire.

Plus d'informations sur XXE Injections

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP sur les attaques par injection XXE. 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 .

Dans les blogs ou les articles comme celui-ci, les lecteurs sont aidés par les signes de ponctuation. Par exemple, les points indiquent aux lecteurs où se termine une phrase, tandis que les virgules séparent les articles dans des listes ou insèrent des pauses dures pour aider à séparer les idées. Dans un blog bien écrit (comme celui-ci), la ponctuation est presque invisible, elle fait simplement partie du code standard que nous avons tous appris à traiter il y a de nombreuses années.

Mais que se passe-t-il si un pirate informatique s'introduit dans cet article et insère des signes de ponctuation bizarres aux mauvais endroits ? Comme ceci :

Sans même modifier le texte, il peut rendre le traitement de l'information beaucoup plus difficile.

C'est essentiellement ce qui se produit lors d'une attaque par injection de CRLF. Les lettres CRLF signifient Carriage Return (retour chariot) et Line Feed (saut de ligne), qui sont utilisées individuellement ou ensemble pour marquer la fin d'une ligne. Si un attaquant parvient à insérer un code CR ou LF dans une application existante, il peut parfois en modifier le comportement. Les effets sont moins faciles à prévoir que ceux de la plupart des attaques, mais ils peuvent être tout aussi dangereux pour l'organisation cible.

Dans cet épisode, vous apprendrez

• Comment les attaquants peuvent-ils déclencher une injection de CRLF ?
• Pourquoi les injections de CRLF sont dangereuses
• Techniques permettant de corriger cette vulnérabilité.

Comment les attaquants déclenchent-ils une injection de CRLF ?

Injecter des caractères CRLF dans un code existant et essayer de produire un résultat spécifique est plutôt difficile, mais pas impossible. C'est d'autant plus difficile qu'un attaquant devrait utiliser différentes combinaisons de CRLF en fonction du système d'exploitation et d'autres facteurs du système ciblé. Par exemple, les machines Windows modernes nécessitent à la fois un CR et un LF pour terminer une ligne, alors que sous Linux, seul le code LF est nécessaire. Les requêtes HTTP nécessitent toujours un code CRLF précis pour terminer une ligne.

Outre le fait que les attaques par CRLF sont difficiles à mettre en œuvre et qu'il est encore plus difficile d'en prévoir les résultats, elles sont lancées de la même manière que les autres attaques par injection. Un utilisateur malveillant saisit simplement des données dans n'importe quelle zone d'un site web ou d'une application qui le permet, sauf qu'il saisit le code CRLF à la place ou à la suite des données d'entrée normales.

Par exemple, un pirate pourrait saisir le code ASCII représentant un retour chariot (%0d) suivi du code ASCII représentant un saut de ligne (%0a) à la fin d'un en-tête HTTPS. L'ensemble de la requête ressemblerait alors à ceci :

https://validsite.com/index.php?page=home%0d%0a

Si les données ne sont pas nettoyées ou filtrées, le code ci-dessus peut permettre à des choses étranges de se produire sur l'application ou le site web cible.

Pourquoi les injections de CRLF sont-elles dangereuses ?

Bien que les attaques par injection de CRLF soient moins précises que la plupart des autres, elles peuvent être assez dangereuses, du moins dans certains cas. Au bas mot, l'ajout d'une ligne supplémentaire peut perturber les fichiers journaux, ce qui peut déclencher des défenses automatiques de cybersécurité pour alerter les administrateurs d'un problème qui n'en est pas un. Cependant, cela pourrait être utilisé pour détourner les ressources d'une incursion réelle se produisant au même moment.

Mais les attaques par CRLF peuvent aussi être directement préjudiciables. Par exemple, si une application est conçue pour accepter des commandes et rechercher ensuite un fichier spécifique, l'ajout d'un code CRLF à la requête peut inciter l'application à afficher ce processus à l'écran au lieu de le garder caché, ce qui pourrait fournir des informations précieuses à un attaquant.

Les injections de CRLF peuvent également être utilisées pour créer ce que l'on appelle une attaque par fractionnement de la réponse, où les codes de fin de ligne divisent une réponse valide en plusieurs morceaux. Cela peut donner aux pirates le contrôle de l'en-tête après le code CRLF, qui peut être utilisé pour injecter du code supplémentaire. Il peut également être utilisé pour créer une ouverture où l'attaquant peut injecter son propre code, et probablement déclencher une autre forme d'attaque, sur n'importe quelle ligne suivant la partie brisée par l'attaque CRLF.

Élimination de la vulnérabilité de l'injection de CRLF

S'il y a un message clé à retenir de cette série, c'est qu'il ne faut jamais, au grand jamais, faire confiance à la saisie de l'utilisateur. La plupart des vulnérabilités que nous avons couvertes dans cette série impliquaient d'une manière ou d'une autre des zones d'entrée utilisateur, et la faille d'injection CRLF ne fait pas exception à la règle.

À tout moment où un utilisateur peut saisir des données, des filtres doivent être appliqués pour empêcher l'injection de code non autorisé qui pourrait être mal interprété par l'application ou le serveur. Pour les attaques CRLF, le verrouillage des en-têtes HTTP est particulièrement important, mais vous ne pouvez pas non plus oublier les paramètres GET et POST ou même les cookies. Un excellent moyen d'empêcher spécifiquement les codes CRLF de contribuer à déclencher d'autres injections consiste à appliquer le codage HTML à tout ce qui est renvoyé au navigateur de l'utilisateur.

Plus d'informations sur CRLF Injections

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP sur les injections de CRLF. 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 .

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]