Les attaques par injection XQuery sont parfois considérées comme le petit frère des attaques par injection SQL, plus répandues. Leurs causes profondes sont similaires et les commandes que les attaquants exploitent pour les déclencher sont également très proches. Les attaques par injection XQuery ne peuvent toutefois se produire que lors d'une requête XPath portant sur des données XML. C'est pourquoi elles sont parfois appelées "injections XPath" ou simplement "attaques XPath", car c'est la méthode de livraison utilisée.

Une grande majorité de sites web utilisent des bases de données XML pour remplir des fonctions critiques telles que la conservation des identifiants de connexion des utilisateurs, des informations sur les clients, des informations sur l'identité personnelle et des données confidentielles ou sensibles, ce qui laisse aux attaques XQuery une empreinte d'attaque assez importante.

Dans cet épisode, vous apprendrez

• Comment les attaquants utilisent les injections XQuery
• Pourquoi les injections XQuery sont dangereuses
• Techniques permettant de corriger cette vulnérabilité.

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

Comme pour la plupart des langages informatiques, le code de XPath a été conçu pour être simple. En fait, XPath est un langage standard, et toutes les notations et déclarations syntaxiques sont inchangées quelle que soit l'application qui les utilise. Cela signifie que les commandes utilisées pour manipuler une requête XPath sont bien connues et peuvent même être automatisées.

À la base, une requête XPath est une simple déclaration qui indique à la base de données XML les informations à rechercher. Dans l'un des exemples les plus simples, elle est utilisée pour vérifier si un enregistrement d'utilisateur existe, puis pour récupérer ses identifiants de connexion. Le problème est qu'étant donné que les requêtes XPath comprennent une entrée utilisateur, les pirates peuvent manipuler la requête pour renvoyer des informations qui devraient être protégées.

Par exemple, lorsqu'il tente de contourner la sécurité de la connexion, un attaquant peut ajouter des variables à la fin de sa requête XPath, ce qui permet de contourner l'ensemble du processus. Un exemple pourrait ressembler à ceci :

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

Ici, le champ Nom d'utilisateur peut correspondre à n'importe quel utilisateur grâce à la déclaration 1=1 ou a=a. Le champ mot de passe n'a pas d'importance, puisque seule la première partie de la requête doit être vraie.

Pourquoi l'injection XQuery est-elle dangereuse ?

L'une des principales raisons pour lesquelles les attaques par injection XQuery sont si dangereuses est qu'elles permettent aux attaquants de contourner la sécurité des connexions et des comptes. De plus, elles permettent de le faire de manière automatisée à l'aide d'un langage standard qui ne varie pas d'une application à l'autre. Les attaquants peuvent analyser automatiquement les sites web et les applications à la recherche de cette vulnérabilité et agir dès qu'elle est découverte. Si votre application est vulnérable, les attaquants la compromettront. En plus de compromettre la sécurité des comptes, les attaques XQuery peuvent également être utilisées pour exfiltrer des données. Par exemple, un attaquant pourrait transférer tous les enregistrements hors de la base de données XML.

Élimination des attaques par injection de XQuery

Comme pour les vulnérabilités similaires, l'un des principaux moyens de défense consiste simplement à ne pas faire confiance aux données saisies par l'utilisateur. Chaque fois qu'un utilisateur est en mesure de saisir des informations, qu'il interroge une base de données ou non, le processus doit être examiné de près. C'est un peu comme sécuriser les fenêtres et les portes d'un bâtiment physique, puisque ce sont les principaux moyens d'accès.

Pour la protection contre les injections XQuery, cela se fait en nettoyant l'entrée de l'utilisateur par le filtrage, ou en utilisant la validation de l'entrée de l'utilisateur par une liste blanche. Vous pouvez également utiliser une interface XPath paramétrée, similaire aux instructions préparées pour les requêtes SQL.

Enfin, veillez à appliquer le principe du moindre privilège à toutes les applications. Cela peut signifier la création d'un utilisateur avec des privilèges de lecture seule pour effectuer toutes les requêtes de l'application.

En utilisant ces techniques, il est possible d'arrêter toutes les tentatives d'injection de XQuery contre votre site web ou votre application.

Plus d'informations sur les injections XQuery

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos des injections XQuery. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à une démonstration 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 blog Secure Code Warrior.

Le terme "mauvaise configuration de sécurité" est un peu un fourre-tout qui englobe les vulnérabilités courantes introduites en raison des paramètres de configuration de l'application, plutôt que d'un mauvais code. Les plus courantes impliquent généralement de simples erreurs qui peuvent avoir de lourdes conséquences pour les organisations qui déploient des applications avec ces configurations erronées.

Parmi les erreurs de configuration les plus courantes en matière de sécurité, citons le fait de ne pas désactiver les processus de débogage des applications avant de les déployer dans l'environnement de production, de ne pas laisser les applications se mettre à jour automatiquement avec les derniers correctifs, d'oublier de désactiver les fonctions par défaut, ainsi qu'une foule d'autres petites choses qui peuvent entraîner de gros problèmes à l'avenir.

La meilleure façon de lutter contre les failles de configuration de la sécurité est de les éliminer de votre réseau avant qu'elles ne soient déployées dans l'environnement de production.

Dans cet épisode, vous apprendrez

• Comment les pirates informatiques trouvent et exploitent les failles de sécurité les plus courantes
• Pourquoi les erreurs de configuration en matière de sécurité peuvent-elles être dangereuses ?
• Politiques et techniques qui peuvent être utilisées pour trouver et corriger les erreurs de configuration de la sécurité.

Comment les attaquants exploitent-ils les failles de sécurité les plus courantes ?

Il existe un grand nombre d'erreurs de configuration en matière de sécurité. Les plus populaires sont bien connues des communautés de hackers et sont presque toujours recherchées lors de la recherche de vulnérabilités. Parmi les erreurs de configuration les plus courantes, on peut citer, entre autres, les suivantes :

• Ne pas désactiver les comptes par défaut dont les mots de passe sont bien connus.
• Laisser les fonctions de débogage activées dans la production qui révèlent les traces de pile ou d'autres messages d'erreur aux utilisateurs.
• Fonctionnalités inutiles ou par défaut laissées activées, telles que des ports, des services, des pages, des comptes ou des privilèges inutiles.
• Ne pas utiliser d'en-têtes de sécurité ou utiliser des valeurs non sécurisées pour ces en-têtes.

Certaines mauvaises configurations sont bien connues et faciles à exploiter. Par exemple, si un mot de passe par défaut est activé, un pirate n'aurait qu'à le saisir avec le nom d'utilisateur par défaut pour obtenir un accès de haut niveau à un système.

D'autres erreurs de configuration nécessitent un peu plus de travail, par exemple lorsque les fonctions de débogage restent activées après le déploiement d'une application. Dans ce cas, un pirate tente de déclencher une erreur et enregistre les informations renvoyées. Armé de ces données, il peut lancer des attaques très ciblées qui peuvent révéler des informations sur le système ou l'emplacement des données qu'il tente de voler.

Pourquoi les erreurs de configuration en matière de sécurité sont-elles si dangereuses ?

En fonction de la mauvaise configuration de sécurité exploitée, les dommages peuvent aller de l'exposition d'informations à la compromission complète d'une application ou d'un serveur. Toute mauvaise configuration de la sécurité constitue une faille dans les défenses que des attaquants compétents peuvent exploiter. Pour certaines vulnérabilités, telles que l'activation des mots de passe par défaut, même un pirate inexpérimenté peut les exploiter. Après tout, il ne faut pas être un génie pour chercher des mots de passe par défaut et les saisir !

Éliminer la menace que représentent les erreurs de configuration en matière de sécurité

La meilleure façon d'éviter les erreurs de configuration en matière de sécurité est de définir des paramètres sécurisés pour toutes les applications et tous les programmes déployés au sein d'une organisation. Il s'agit notamment de désactiver les ports inutiles, de supprimer les programmes et fonctionnalités par défaut qui ne sont pas utilisés par l'application et de désactiver ou de modifier tous les utilisateurs et mots de passe par défaut. Il s'agit également de vérifier et de traiter les erreurs de configuration les plus courantes, par exemple en désactivant systématiquement le mode de débogage d'un logiciel avant qu'il n'atteigne l'environnement de production.

Une fois ces éléments définis, il convient de mettre en place un processus que toutes les applications doivent suivre avant d'être déployées. Idéalement, une personne devrait être chargée de ce processus, dotée de pouvoirs suffisants pour le faire respecter et responsable en cas d'erreur de configuration de la sécurité.

Plus d'informations sur les erreurs de configuration de la sécurité

Pour en savoir plus, vous pouvez consulter la liste OWASP des erreurs de configuration les plus courantes en matière de sécurité. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à une démonstration 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 .

Prêt à déjouer une mauvaise configuration de sécurité dès maintenant ? Rendez-vous sur notre plateforme et mettez-vous au défi [Commencez ici]

Susie ouvre son courrier électronique pour échapper à un méchant rapport qu'elle doit rendre dans deux jours. Elle voit apparaître dans sa boîte de réception un lien vers un iPad gratuit. Après avoir cliqué sur ce lien, elle accède à un site web comportant une grande bannière indiquant : "Cliquez ici pour obtenir votre iPad gratuit". Elle clique sur le bouton, mais rien ne semble se passer. Le problème, c'est qu'il s'est passé quelque chose.

Après avoir navigué jusqu'à sa boîte de réception, elle se rend compte que tous ses courriels ont été supprimés. Elle n'a même pas appuyé sur "supprimer". Que se passe-t-il ?

Le site de messagerie a été piraté. Le clickjacking incite les utilisateurs à effectuer des actions qu'ils n'avaient pas l'intention de faire, ce qui peut entraîner de graves problèmes.

Voyons maintenant comment fonctionne le clickjacking, pourquoi il est dangereux et ce que les développeurs comme vous peuvent faire pour l'éviter :

Comprendre le détournement de clics

Le clickjacking, également appelé "UI redressing attack", se produit lorsqu'un pirate utilise plusieurs couches transparentes sur une page web pour inciter l'utilisateur à cliquer sur un bouton ou un lien sur lequel il n'a pas l'intention de cliquer.

Avez-vous déjà eu un insecte coincé dans votre voiture ? Ils volent contre la vitre en essayant furieusement de s'envoler vers l'extérieur. L'intention de l'insecte est de voler vers ce qui ressemble à des arbres et à l'air libre, sans se soucier de la vitre qui bloque son chemin.

Le clickjacking est similaire dans sa conception, sauf que l'utilisateur est l'insecte et votre site web est la vitre qui bloque le passage. L'utilisateur voit quelque chose qu'il veut, par exemple un iPhone gratuit. L'attaquant place votre site dans un cadre transparent au-dessus de l'annonce de l'iPhone gratuit. Lorsque l'utilisateur clique sur le bouton pour obtenir le prix prétendument "gratuit", il clique en fait sur un bouton de votre site, effectuant ainsi une action qu'il n'avait pas prévue.

Pourquoi le détournement de clics est dangereux

Que peut faire un pirate avec le clickjacking ? Cela dépend en grande partie de la fonctionnalité du site web en question.

Le pirate peut amener un utilisateur à aimer ou à partager le site du pirate sur les médias sociaux. Cette opération est facile à réaliser, car de nombreuses personnes restent connectées à leurs comptes de médias sociaux pour des raisons de commodité.

Si votre site peut être placé dans un cadre, une opération sensible peut être effectuée en cliquant sur un bouton, ce qui peut constituer un vecteur d'attaque. Par exemple, un utilisateur clique pour obtenir un iPad gratuit, mais au lieu de cela, il modifie les paramètres de son compte sur votre site, ce qui le rend moins sûr. Une attaque de ce type a été menée contre la page des paramètres du plugin Adobe Flash. Les paramètres pouvaient être placés dans un cadre transparent, ce qui incitait l'utilisateur à permettre à toute animation Flash d'accéder au microphone et à la caméra. Les attaquants peuvent alors enregistrer la victime, ce qui constitue une atteinte majeure à la vie privée.

Un client de messagerie peut être piégé dans un site, ce qui amène l'utilisateur à supprimer tous les courriels de sa boîte aux lettres ou à les transférer vers une adresse électronique contrôlée par l'attaquant.

L'essentiel est que l'utilisateur ne peut pas voir ce qu'il clique, il peut donc être convaincu de cliquer sur n'importe quoi. Qu'il s'agisse d'un partage social ou du téléchargement d'un logiciel malveillant, les possibilités sont vastes.

Comment vaincre le détournement de clics

Le détournement de clics peut être évité. La méthode recommandée pour empêcher le détournement de clics consiste à définir une politique de sécurité du contenu (Content Security Policy ou CSP) pour votre site. En utilisant l'en-tête de réponse HTTP "frame ancestors", vous pouvez contrôler la manière dont votre site peut être encadré.

• "frame-ancestors none'- Aucun autre site n'est autorisé à encadrer le vôtre. C'est le paramètre recommandé.
• "frame-ancestors self'- Les pages de votre site ne peuvent être encadrées que par d'autres pages de votre site.
• "frame-ancestors self <uri list=""> - Your site can be framed by the sites in the URI lists and no others.</uri>

Le système CSP frame-ancestors n'est actuellement pas pris en charge par tous les principaux navigateurs. Utilisez l'en-tête HTTP "X-Frame-Options" comme option de repli pour ces navigateurs.

• DENY - Personne ne peut encadrer votre site. C'est le paramètre recommandé
• SAMEORIGIN - Identique à "self" pour CSP. Vous pouvez encadrer votre propre contenu, mais personne d'autre ne peut le faire.
• ALLOW-FROM <uri> - Allow the specified URI to frame your content.</uri>

Ne vous faites pas pirater

Le clickjacking est une attaque intelligente et trompeuse qui peut nuire à la réputation et entraîner des pertes de revenus si votre produit peut être manipulé par les attaquants. Consultez nos ressources d'apprentissage gratuites pour en savoir plus sur le clickjacking.

Utilisez une politique de sécurité du contenu et un en-tête "X-Frame-Options" pour empêcher les autres d'utiliser votre site à des fins malveillantes. Ne permettez pas aux attaquants de manipuler vos utilisateurs. Ne vous laissez pas détourner par les clics.

Une attaque par injection de commande du système d'exploitation peut se produire lorsqu'une application permet aux utilisateurs de saisir des données dans un shell, mais ne prend aucune mesure pour vérifier que les chaînes de caractères saisies sont valides. Cela permet à un attaquant d'introduire des commandes directement dans le système d'exploitation hébergeant l'application, et ce quel que soit le niveau d'autorisation défini pour l'application compromise.  

Les attaques par injection de commandes du système d'exploitation peuvent être réalisées par des pirates débutants ou peu qualifiés, ce qui en fait l'une des faiblesses les plus courantes auxquelles les équipes de sécurité sont confrontées. Heureusement, il existe plusieurs moyens très efficaces d'empêcher ces attaques de réussir. Dans cet épisode, nous allons apprendre :

       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 commandes dans le système d'exploitation ?

La première chose qu'un attaquant doit faire pour lancer une attaque par injection de commande de système d'exploitation est de localiser les entrées de l'utilisateur dans une application. Les formulaires que les utilisateurs remplissent sont potentiellement de bons points de départ. Les attaquants les plus astucieux peuvent également utiliser des éléments tels que les cookies ou même les en-têtes HTTP comme point de départ, un élément utilisé par presque toutes les applications ou tous les sites web.

La deuxième chose à faire est de déterminer le système d'exploitation qui héberge l'application. Étant donné qu'il n'existe qu'une poignée de choix, la méthode des essais et des erreurs peut très bien fonctionner pour cette phase. La plupart des serveurs d'application seront soit basés sur Windows (la version de Windows n'a normalement pas d'importance), soit sur un boîtier Linux, soit éventuellement sur Unix.

À ce stade, le pirate modifie l'entrée pour injecter une commande du système d'exploitation dans une entrée apparemment inoffensive. Cela peut inciter le système d'exploitation hôte à exécuter des commandes non souhaitées, quel que soit le niveau d'autorisation de l'application.

Par exemple, la commande suivante peut être utilisée par des utilisateurs valides au sein d'une application pour voir le contenu d'un fichier, dans ce cas les notes d'une réunion mensuelle du conseil d'administration.

exec("cat " + nom de fichier)

Dans notre exemple, la commande suivante sera exécutée et les notes de réunion seront renvoyées à l'utilisateur.

./cat MeetingNotes.txt

Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.

C'est ce qui se produit lorsqu'un attaquant ajoute des commandes supplémentaires à la fin de l'entrée, comme celle utilisée pour lister le contenu d'un répertoire sous Linux. Dans ce cas, la commande originale, qui consiste à afficher les notes de réunion, est toujours exécutée. Mais l'utilisateur malveillant voit également tout ce qui se trouve dans le répertoire et les autres commandes qu'il peut utiliser dans le cadre d'attaques par injection de commandes du système d'exploitation. Il entre :

$ ./cat MeetingNotes.txt && ls

Et obtenez ceci à la place :

Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.

MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c

Comme vous pouvez le voir, dans ce cas, non seulement le pirate a vu le contenu du répertoire, mais il a également reçu un menu d'autres commandes qu'il pouvait utiliser " des commandes qu'il sait maintenant pouvoir exécuter sur le système d'exploitation hôte ".

Pourquoi les attaques par injection de commande du système d'exploitation sont-elles si dangereuses ?

Permettre aux utilisateurs de contourner l'objectif de l'application ciblée et de l'utiliser pour exécuter des commandes du système d'exploitation est extrêmement risqué. Un pirate peut facilement réaliser des actions dévastatrices telles que le vol de données confidentielles ou le formatage de l'ensemble du disque du serveur, par exemple. Les options dont dispose un pirate ne sont limitées que par les commandes autorisées dans le système d'exploitation et par la créativité dont il fait preuve pour les utiliser.

Les commandes du système d'exploitation sont exécutées au même niveau d'autorisation que l'application. Les applications fonctionnant avec des privilèges administratifs signifient que les pirates qui les compromettent peuvent exécuter toutes les commandes du système d'exploitation.

Les schémas d'attaque pour l'injection de commandes dans les systèmes d'exploitation sont bien connus et documentés. Une application vulnérable est tout aussi susceptible d'être attaquée par des "script kiddies" que par des pirates professionnels. Les attaquants ayant très peu de compétences peuvent essayer de copier et de coller des commandes de système d'exploitation dans des applications pour voir ce qui se passe.

Obtenir un OK de sécurité contre les injections de commandes du système d'exploitation

Il existe plusieurs techniques efficaces pour empêcher les injections de commandes dans le système d'exploitation. La première étape consiste à exécuter les applications avec le minimum de privilèges nécessaires à l'accomplissement de leur fonction. Cela n'empêchera pas une attaque, mais si une brèche se produit, les dommages seront minimisés.

La plupart des langages de programmation et des frameworks fournissent des appels API pour les méthodes courantes du système d'exploitation, telles que l'énumération du contenu des répertoires, la création ou la lecture de fichiers sur le disque dur. Un moyen idéal d'éliminer les injections de commandes du système d'exploitation de votre environnement consiste à faire en sorte que toutes les applications utilisent ces appels d'API au lieu des commandes du système d'exploitation directement.

Lorsque cela n'est pas possible, validez les entrées de l'utilisateur avant de les utiliser dans les commandes du système d'exploitation. Les listes blanches peuvent être utilisées pour s'assurer que seul un petit ensemble de valeurs de confiance peut être utilisé. Techniquement, il est également possible d'utiliser une liste noire, mais les commandes autorisées étant probablement beaucoup moins nombreuses, l'établissement d'une liste blanche est presque toujours plus facile. N'oubliez pas d'inclure les paramètres POST et GET valides dans votre liste blanche, ainsi que les vecteurs d'entrée utilisateur souvent négligés comme les cookies.

Enfin, s'il n'existe pas d'API de programmation et qu'il n'est pas possible d'utiliser une liste blanche, utilisez une bibliothèque d'assainissement pour échapper à tout caractère spécial dans les entrées utilisateur avant de les utiliser dans les commandes du système d'exploitation.

Plus d'informations sur les attaques par injection de commandes du système d'exploitation

Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les attaques par injection de commandes du système d'exploitation. 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 .

Vous vous rendez sur un site web et vous vous connectez. Comme d'habitude, vous remplissez votre panier avec les produits que vous souhaitez acheter. Puis, oups, votre main glisse et ferme l'onglet du navigateur. Après une petite panique, vous entrez à nouveau l'URL du site dans le navigateur et appuyez sur la touche "Entrée". Vous revenez sur le site, vous êtes connecté et tous vos articles sont encore dans le panier. C'est bien.

Comment le site a-t-il su qui vous étiez sans vous ré-authentifier ? Il vous a identifié parce qu'il utilisait des sessions. Les sessions sont la clé d'une bonne expérience utilisateur sur le web. Cependant, une mauvaise gestion des sessions peut entraîner des failles de sécurité que les pirates peuvent exploiter.

Voyons maintenant ce que signifie la gestion des sessions, comment une gestion insuffisante des sessions peut vous nuire et ce que vous pouvez faire pour gérer correctement les sessions.

Comprendre les faiblesses de la gestion des sessions

Une session fait référence à une valeur stockée sur le serveur, spécifique à un seul utilisateur de l'application. Cela est nécessaire pour deux raisons : Premièrement, HTTP est un protocole sans état. Chaque demande est distincte et ne connaît pas les demandes qui l'ont précédée ou suivie. Une session permet au serveur de savoir qui a envoyé la requête. Sinon, vous devriez vous connecter chaque fois que vous cliquez sur un bouton ou un lien.

La deuxième raison d'être des sessions est l'autorisation de l'utilisateur. L'identifiant de session peut être utilisé pour reconnaître un utilisateur spécifique disposant de droits spécifiques au sein du système. L'application saura qui est cette personne et ce qu'elle est autorisée à faire.

Une session se compose de deux éléments. Un magasin de données côté serveur stocke un identifiant de session et l'associe à des informations sur l'utilisateur, telles que son nom d'utilisateur ou les informations relatives à son panier. Le même identifiant de session est envoyé au navigateur dans un cookie. Les cookies sont stockés par le navigateur sur le système de l'utilisateur. Le client transmet le cookie à chaque demande, ce qui permet au serveur de savoir que cette demande provient du même utilisateur. La plupart des applications utilisent les sessions pour suivre les utilisateurs avant et après l'authentification.

Une bonne gestion des sessions est essentielle à la sécurité d'une application. Un identifiant de session valide a le même niveau de confiance qu'un nom d'utilisateur/mot de passe, ou même qu'un jeton d'authentification à deuxième facteur.

Pourquoi une mauvaise gestion des sessions est dangereuse

Une mauvaise gestion des sessions peut conduire à une prise de contrôle totale du compte. Cela signifie que les données des clients peuvent être volées ou que des produits peuvent être achetés frauduleusement. Les attaquants disposent de plusieurs moyens pour obtenir un identifiant de session valide.

Une attaque par fixation de session se produit lorsque les sessions ne sont pas modifiées à des moments clés, comme lorsqu'un utilisateur se connecte au système, et si les identifiants de session peuvent être définis à l'aide de l'URL. La définition d'identifiants de session de cette manière peut être utilisée pour maintenir la connexion des utilisateurs dans différentes applications qui utilisent la même source d'authentification. Dans ce cas, un pirate peut naviguer sur un site web et obtenir un identifiant de session. Il envoie ensuite un URL à une victime peu méfiante par courrier électronique, avec l'identifiant de session dans l'URL. La victime clique sur l'URL du courriel et se connecte au site web. Si l'identifiant de session n'est pas modifié lors de la connexion, le pirate dispose alors d'un identifiant de session valide et authentifié. Cela permet une prise de contrôle complète du compte.

Une autre attaque contre une mauvaise gestion des sessions est une attaque par force brute. Lorsque les développeurs essaient de créer leurs propres systèmes de gestion de session, ils utilisent souvent des identifiants de session qui sont assez faciles à deviner. Il peut s'agir d'une séquence (1, 2, 3) ou d'un schéma prévisible. L'attaquant continue simplement à deviner les identifiants de session jusqu'à ce qu'il en découvre un valide. Cela conduit également à la prise de contrôle d'un compte.

Les sessions qui ne sont pas invalidées automatiquement après un certain temps peuvent être exploitées pour attaquer les utilisateurs. La réussite d'une attaque de type "cross-site request forgery " dépend des sessions qui sont encore valides après que l'utilisateur a quitté le site. Supposons qu'un pirate place une iframe ou une image sur un site visité par l'utilisateur. L'attribut "src" (source) est défini sur l'URL du site vulnérable et exécute une action au nom de l'utilisateur. Par exemple, une application bancaire vulnérable pourrait être utilisée pour transférer de l'argent sur le compte d'un attaquant sans l'autorisation de l'utilisateur.

La gestion des sessions peut être délicate et les faiblesses peuvent être dévastatrices. Il s'agit toutefois d'un problème bien connu qui peut être résolu.

Déjouer la gestion des sessions non sécurisées

La gestion des sessions est un élément essentiel de toute application web. C'est pourquoi de nombreux cadres de développement web intègrent une fonctionnalité de gestion des sessions. Ces systèmes ont été examinés de près par des experts afin de détecter et d'éliminer les problèmes. Utilisez-les.

Voici quelques-unes des caractéristiques communes d'une bonne gestion de session:

     Génération d'identifiants de session aléatoires que les attaquants ne peuvent pas deviner

     Les sessions sont invalidées lorsqu'un utilisateur se déconnecte.

     Les sessions sont automatiquement invalidées après un certain temps.

     Les identifiants de session sont modifiés après la connexion de l'utilisateur.

     Les identifiants de session ont une longueur d'au moins 128 bits afin d'éviter les attaques par force brute.

Les frameworks web tels que Spring, ASP.NET Core, Rails et Django possèdent ces propriétés et devraient être utilisés pour leurs normes de sécurité plus élevées dans ce cas.

Conclusion : Ne créez pas votre propre système de gestion des sessions à partir de zéro.

Une fois les identifiants de session créés, ils doivent être protégés. Attribuez la valeur "true" aux indicateurs Secure et HttpOnly pour les cookies de session. Cela garantit que leur valeur ne peut pas être récupérée avec JavaScript et que le navigateur n'enverra le cookie que via HTTPS, empêchant ainsi les attaquants de voler la session de quelqu'un en cours de route.

Sécurisez vos sessions

Consultez nos ressources d'apprentissage gratuites pour en savoir plus sur la gestion sécurisée des sessions. Apprendre à sécuriser vos sessions vous aidera à prévenir la prise de contrôle des comptes utilisateurs, les atteintes à la réputation et les pertes de revenus dues aux failles de sécurité. Sécurisez vos sessions et protégez vos utilisateurs.

Bien que Padding Oracle semble être un très mauvais nom pour un groupe de rock alternatif, il s'agit en fait d'une vulnérabilité qui peut être utilisée par des attaquants pour décrypter des informations sans connaître la clé de cryptage.

En termes de difficulté globale pour un attaquant, celle-ci se situe en haut de l'échelle. Il ne s'agit pas d'un bouton magique de décryptage, mais d'un processus laborieux par lequel les pirates peuvent examiner les messages d'erreur qui leur sont envoyés concernant le remplissage des cellules et s'en servir pour déterminer où les données cryptées se terminent et où le remplissage commence. Ils peuvent ensuite déterminer les différents bits du chiffrement et éventuellement le déchiffrer s'ils disposent de suffisamment de temps et d'informations pour l'examiner.

Heureusement, il existe plusieurs étapes relativement simples qui permettent à un attaquant de ne plus pouvoir utiliser l'oracle pour déchiffrer des données cryptées. Dans cet épisode, nous allons apprendre :

• Comment cela fonctionne-t-il ?
• Pourquoi cette vulnérabilité est-elle si dangereuse ?
• Comment vous pouvez mettre en place des défenses pour l'éviter.

Comment fonctionne l'Oracle Padding ?

L'enchaînement de blocs de chiffrement (CBC) est un moyen de créer un chiffrement par blocs dans lequel une séquence entière de bits d'information, tels que des cellules stockées dans une base de données, est chiffrée à l'aide d'une clé de chiffrement qui s'applique à l'ensemble de la chaîne d'information. Lors de l'utilisation du CBC, le cryptage d'un seul bloc de texte chiffré dépend de tous les blocs précédents. En théorie, cela rend le cryptage extrêmement solide, puisque tout, même le réarrangement des blocs, corrompra les données.

Le problème des algorithmes de chiffrement CBC (et de tous les algorithmes de chiffrement par blocs, d'ailleurs) est qu'ils ne peuvent être chiffrés qu'à l'aide de blocs de taille exacte. Normalement, cela se fait par blocs de 8 ou 16 octets. Que se passe-t-il donc lorsque le CBC doit faire entrer 2 octets de données dans une unité de texte chiffré de 16 octets ? Il utilisera des caractères de remplissage, c'est-à-dire des caractères absurdes, pour combler les lacunes et donner à l'unité une taille appropriée.

La plupart des schémas de remplissage sont bien connus, le PKCS#7 étant l'un des plus populaires, de sorte que les attaquants peuvent savoir quel type de remplissage est utilisé. Par exemple, si le CBC doit remplir cinq caractères dans un bloc, le PKCS#7 utilisera la valeur d'octet 0x05 répétée cinq fois après le texte en clair.

Les attaquants utilisent leur connaissance des schémas CBC et de remplissage pour envoyer des requêtes à un serveur hôte, également appelé oracle. S'ils ont accès aux bons outils, ils peuvent être en mesure de forcer le serveur à leur dire si le remplissage de leur requête est incorrect. Pour ce faire, il peut passer de zéro à 255 pour chaque octet du chiffrement jusqu'à ce que le serveur lui dise que le remplissage est correct. Il passe alors à l'unité suivante et répète le processus, en notant à chaque fois où commence le remplissage.

Cela ne leur permet pas de décrypter le message ni même la cellule, mais pourrait leur permettre de cartographier chaque maillon de la chaîne pour savoir où se termine le texte en clair et où commence le rembourrage. Ils peuvent également utiliser des calculs XOR pour déterminer la valeur du dernier octet du texte en clair original.

Pourquoi le Padding Oracle est-il si dangereux ?

La raison pour laquelle un pirate informatique consacre autant d'efforts à briser le cryptage est le gain potentiel. Peu de gens chiffrent des données qui n'ont pas de valeur. Le danger pour l'organisation hôte dépend des données compromises. Il peut s'agir de mots de passe, de comptes d'utilisateurs, d'informations financières, de numéros de cartes de crédit, de dossiers de patients, de communications sensibles ou de toute autre information précieuse et très recherchée.

L'utilisation du padding oracle peut également être la porte d'entrée pour des attaques ultérieures. Si un attaquant peut utiliser le padding oracle pour voler des mots de passe par exemple, l'élévation de ses privilèges et la pénétration plus profonde dans un réseau est une tâche secondaire facile.

Tout le monde considère le chiffrement comme la défense ultime contre l'espionnage ou la compromission. Cependant, le va-et-vient entre la science du chiffrement et ceux qui veulent le casser dure depuis des siècles. L'oracle de la capitalisation n'est qu'une des méthodes qui donnent l'avantage aux attaquants.

Les attaques d'Oracle contre le rembourrage ne sont pas à l'abri d'un atterrissage brutal

Heureusement, il existe plusieurs façons d'éviter l'oracle de remplissage. L'une des meilleures consiste à utiliser un mode de chiffrement plus puissant, tel que le mode Galois/compteur (GCM) ou le mode Offset Codebook (OCB). Ce mode diffère du CBC en ce qu'il utilise une taille de bloc de chiffrement de 128 bits. Il utilise également un compteur pour chaque bloc de données, puis utilise ce nombre pour créer le texte chiffré. En d'autres termes, il n'est pas sensible aux attaques par oracle de remplissage.

La mise en œuvre de contrôles efficaces de gestion des erreurs peut également réduire considérablement les chances de succès d'un attaquant. Étant donné que les attaques par oracle de remplissage reposent sur la fuite d'informations, renvoyez des messages d'erreur génériques au lieu d'erreurs de remplissage spécifiques en cas d'échec du chiffrement ou du déchiffrement.

Vous pouvez également mettre en œuvre le code d'authentification des messages (MAC). Les valeurs MAC protègent l'intégrité et l'authenticité des données en permettant aux vérificateurs de détecter toute modification du contenu du message à l'aide d'une clé secrète.

Enfin, toutes les attaques par l'oracle du remplissage nécessitent des requêtes répétées. Il peut y avoir plus de 200 requêtes pour déterminer le schéma de remplissage d'une seule cellule, multiplié par le nombre d'unités d'information protégées dans la chaîne. En limitant le nombre de demandes provenant de la même source, vous pouvez mettre fin aux attaques par oracle de remplissage en refusant l'accès à un attaquant avant qu'il ne puisse réellement commencer sa tentative.

Étude complémentaire sur l'Oracle Padding

Toute méthode permettant à un pirate de décrypter des informations sensibles peut devenir un véritable cauchemar. Mais nous espérons que vous avez appris quelques bonnes méthodes pour éviter que cela ne se produise.

Pour en savoir plus, vous pouvez consulter la définition et la liste de contrôle de l'OWASP sur padding oracle. 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 façon de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Vous pensez être à la hauteur pour déjouer les attaques de l'oracle du padding ? Essayez sur la plateforme Secure Code Warrior :

La grande majorité des systèmes informatiques utilisent le protocole LDAP (Lightweight Directory Access Protocol). Il est utilisé pour maintenir des services d'information d'annuaire distribués sur n'importe quel réseau IP (Internet Protocol). Il s'agit donc essentiellement d'un moyen de suivre les utilisateurs.

LDAP est souvent utilisé comme source d'authentification par les applications pour vérifier si un utilisateur a le droit d'effectuer diverses actions, notamment en fonction de son rôle défini au sein d'une organisation. Par exemple, seules les personnes travaillant dans le domaine de la comptabilité peuvent être autorisées à utiliser le logiciel de comptabilité de l'entreprise. Les applications sont souvent programmées pour vérifier une table LDAP afin de s'assurer que les utilisateurs agissent dans le cadre des autorisations qui leur ont été accordées.

Des problèmes peuvent survenir lorsque des utilisateurs malveillants peuvent manipuler une requête LDAP. Cela peut inciter le serveur récepteur à exécuter des requêtes non valides qui ne seraient normalement pas autorisées, voire à accorder un accès de haut niveau ou d'administrateur à des utilisateurs non valides ou peu sûrs sans mot de passe.  

Les injections LDAP peuvent être délicates, mais dans cet épisode, nous allons apprendre :

• 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 LDAP ?

L'une des raisons pour lesquelles les attaques basées sur LDAP sont restées populaires pendant des années est le fait que presque tous les systèmes informatiques l'utilisent. LDAP est un logiciel libre qui fonctionne très bien, de sorte que peu d'alternatives ont été créées.

À la base, LDAP est une base de données qui permet de suivre les utilisateurs valides au sein d'un système informatique ou d'un réseau basé sur IP. Il peut permettre aux utilisateurs de partager des informations sur les systèmes, les réseaux, les serveurs, les applications et même d'autres utilisateurs sur le même réseau.

Les informations sont stockées par LDAP dans l'équivalent d'une ligne de base de données ou d'un enregistrement appelé nom distinctif, souvent abrégé en DN. Chaque DN est unique. Voici, à titre d'exemple, à quoi pourrait ressembler un DN pour un utilisateur travaillant au bureau de comptabilité de Chicago d'une grande entreprise.

cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview  

Pour s'assurer que chaque DN est unique, divers codes peuvent être ajoutés à l'enregistrement, tels que "+", "/", "=" et quelques autres. Des espaces avant ou après un enregistrement peuvent également être insérés pour s'assurer que même si deux James Smiths travaillent dans les comptes d'entreprise au bureau de Chicago Parkview, ils auront chacun leur propre numéro d'identification.

Les applications utilisent généralement LDAP pour permettre aux utilisateurs d'envoyer des requêtes sur des DN spécifiques, comme, par exemple, lorsqu'ils essaient de localiser le bon contact dans le service des salaires pour parler d'une erreur sur leur chèque. Les injections LDAP peuvent se produire lorsqu'il n'y a pas de validation des paramètres fournis par l'utilisateur dans les requêtes de recherche. Dans ce cas, les pirates peuvent manipuler des recherches bénignes pour contourner les mécanismes d'authentification ou exécuter des requêtes arbitraires supplémentaires. Cela peut inciter le serveur à afficher des résultats qui ne devraient pas être autorisés, tels que des mots de passe d'utilisateurs, ou même amener une application à accorder l'accès à des zones de haute sécurité au sein du réseau, avec ou sans mot de passe valide.

Pourquoi les injections LDAP sont-elles si dangereuses ?

Le plus grand danger des injections LDAP est probablement la prolifération du protocole dans la majorité des réseaux informatiques IP du monde entier. Il constitue un tremplin facile pour les pirates qui cherchent à voler des informations ou à élever leurs privilèges sur un réseau. Aucun pirate informatique expérimenté ne manquera de vérifier si les injections LDAP sont possibles, c'est pourquoi les équipes de sécurité doivent s'assurer que ces failles sont toujours fermées.

Plus précisément, un certain nombre d'applications sont programmées pour aider les utilisateurs valides à trouver des informations limitées sur les utilisateurs et les groupes au sein d'une organisation, ou toute autre information contenue dans les DN. Par exemple, une application pourrait permettre à quelqu'un d'utiliser LDAP pour rechercher les coordonnées de comptables d'entreprise travaillant à Chicago, ce qui renverrait à notre ami James Smith de l'exemple ci-dessus. En fonction des autorisations, il s'agit probablement d'une utilisation parfaitement valide d'une requête LDAP.

Le danger survient lorsqu'un utilisateur malveillant peut ajouter des paramètres non filtrés à la requête, modifiant ainsi la nature de la recherche et incitant le serveur à fournir des informations qui ne devraient normalement pas être données. Par exemple, en ajoutant une chaîne user=*, les attaquants pourraient obtenir des informations sur chaque utilisateur d'une organisation entière, ce qui ne devrait probablement jamais être autorisé.

Pour les applications qui utilisent LDAP pour l'authentification, le problème peut être encore plus grave. Les attaquants peuvent utiliser, par exemple, la chaîne (&) à la fin d'une requête LDAP pour tromper le serveur et lui faire croire que l'argument est vrai. Si une application utilise LDAP pour valider un mot de passe, forcer un argument True par une injection LDAP peut permettre à un utilisateur non autorisé de se connecter au réseau en tant qu'administrateur, même sans mot de passe.

Faire de l'injection LDAP un L-DON'T dans votre réseau

L'une des meilleures façons d'empêcher les injections LDAP est de mettre en œuvre un outil tel que LINQtoAD ou d'autres cadres conçus spécifiquement pour y résister. Cela peut s'avérer impossible si un réseau dispose déjà d'applications qui exploitent les requêtes LDAP. Cependant, même dans ce cas, c'est une bonne idée pour chaque nouvelle application d'utiliser des frameworks résistants aux injections à l'avenir.

Les applications existantes qui utilisent LDAP peuvent également être renforcées contre les injections par l'utilisation de la validation de la liste blanche et de l'assainissement des entrées. Dans la mesure du possible, limitez les entrées des utilisateurs à un ensemble restreint de valeurs de confiance. N'oubliez pas d'inclure les paramètres GET et POST, les cookies et les en-têtes HTTP, car ils peuvent également servir de vecteurs d'attaque. N'écrivez pas vos propres fonctions pour effectuer la vérification des entrées ; utilisez plutôt une bibliothèque tierce de confiance axée sur la sécurité ou les API intégrées du cadre de travail.

Au-delà des correctifs ciblés, de bonnes pratiques informatiques telles que l'attribution aux applications d'interrogation du LDAP du moindre privilège nécessaire sur un réseau peuvent également s'avérer utiles. Ainsi, si le pire devait se produire et qu'une injection LDAP parvenait à passer, les dommages seraient atténués.

Plus d'informations sur les injections LDAP

Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les injections LDAP ou l'aide-mémoire sur la prévention des injections. 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 façon de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Le problème des téléchargements de fichiers sans restriction n'est pas une attaque en soi, mais plutôt une situation ou un état courant qui permet aux attaquants d'accéder facilement aux applications et aux ressources du réseau. C'est un peu comme si vous vous promeniez dans le froid avec des vêtements mouillés. Bien que cela ne vous rende pas nécessairement malade en soi, cela diminue votre résistance au point que n'importe quel virus opportuniste dépassera facilement les défenses de votre corps.

En matière de cybersécurité, les attaquants peuvent être prompts à exploiter n'importe quelle application ou n'importe quel programme qui a été autorisé à prendre en charge des téléchargements de fichiers sans restriction. Les résultats peuvent être dévastateurs. Des attaquants astucieux peuvent utiliser leur accès illimité pour télécharger des fichiers malveillants, mettre en place des scripts pour voler des informations d'identification ou lancer des attaques plus profondes dans un réseau en utilisant les propres autorisations d'une application. Même un attaquant relativement peu sophistiqué pourrait utiliser ce type d'accès illimité pour effectuer des attaques par déni de service ou pour faire planter une application.

Heureusement, il existe plusieurs façons de résoudre le problème des téléchargements de fichiers sans restriction et d'arrêter les attaquants potentiels dans leur élan. À cette fin, nous allons examiner trois aspects essentiels des téléchargements de fichiers sans restriction :

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

Comment les attaques exploitent-elles les téléchargements de fichiers sans restriction ?

Il existe de nombreuses raisons pour lesquelles les sites souhaitent permettre au public de télécharger des fichiers. Peut-être une entreprise cherche-t-elle à embaucher des personnes et souhaite-t-elle leur permettre de télécharger leur curriculum vitae dans le cadre du processus de candidature. Les banques peuvent encourager leurs clients à remplir des documents importants chez eux, par exemple lors d'une demande de prêt ou d'ouverture de compte. Les sites de tourisme ou de médias sociaux peuvent inviter les utilisateurs à télécharger leurs photos pour les partager avec d'autres.

Il existe de nombreuses raisons valables d'autoriser le téléchargement de fichiers. Et par défaut, la plupart des nouvelles applications vont probablement autoriser tout type de téléchargement de fichiers, sans aucune restriction. Les problèmes commencent lorsqu'un attaquant potentiel remarque que ces téléchargements ne sont soumis à aucune restriction.

L'absence de restrictions sur les téléchargements expose les sites à trois types d'attaques. En commençant par le moins sophistiqué, un utilisateur malveillant peut simplement télécharger d'énormes fichiers tels que des archives zippées contenant des centaines de gigaoctets d'informations. Outre l'engorgement de la bande passante, cela peut entraîner une surcharge de la zone de stockage attribuée à l'application.

L'utilisateur qui télécharge un fichier malveillant, comme un virus ou quelque chose de plus sinistre comme un ransomware, est le prochain sur l'échelle de l'infamie. C'est un peu comme cette vieille superstition qui veut que l'on invite spécifiquement un vampire dans sa maison. Si vous affichez un panneau indiquant que tout le monde peut entrer librement, c'est comme si les téléchargements de fichiers étaient illimités. Vous ne contrôlez plus ce qui franchit votre porte et vous devez vous attendre à ce que tous les visiteurs, ou fichiers, ne soient pas inoffensifs. Certains d'entre eux peuvent être des monstres.

Enfin, un attaquant habile peut utiliser les téléchargements sans restriction pour s'introduire dans un réseau et y mener des attaques plus profondes. Étant donné qu'il n'y a aucune restriction sur ce qu'une personne peut télécharger, un attaquant peut envoyer son propre shell web par le biais de ce processus. Il peut ensuite envoyer des commandes dans son shell, qui seront exécutées sur le serveur avec le même niveau de permission que l'application.

Pourquoi l'accès illimité aux fichiers est-il si dangereux ?

Si le déploiement d'une application avec un accès illimité aux fichiers n'est pas immédiatement dangereux, cela revient à ouvrir une brèche dans vos défenses de cybersécurité et à inviter quelqu'un à attaquer votre organisation. Tôt ou tard, quelqu'un réagira.

Au niveau le plus élémentaire, les attaquants n'ont même pas besoin de beaucoup de compétences pour faire des ravages. Le simple fait de compresser des fichiers extrêmement volumineux et de les télécharger peut suffire à priver de service des utilisateurs valides. Avec le temps, l'application ou un site entier peut même tomber en panne, en fonction de la façon dont l'application est programmée et mise en réseau.

L'accès illimité aux fichiers peut également ouvrir une brèche dans les pare-feux et autres protections du réseau. Peu importe que vous disposiez d'un scanner surveillant votre courrier électronique entrant ou l'activité de navigation de vos employés sur le web si vous avez créé une voie permettant aux attaquants de télécharger des logiciels malveillants directement sur votre réseau central. Le logiciel malveillant peut faire planter l'application ou même le serveur sur lequel il s'exécute, mais c'est probablement le meilleur résultat possible. Dans le pire des cas, un programme réellement malveillant comme un ransomware peut utiliser le serveur compromis pour se propager à l'ensemble du réseau.

Des attaquants plus habiles ne seront probablement pas aussi évidents lorsqu'ils exploiteront une application avec un accès illimité aux fichiers. Au lieu de cela, ils peuvent utiliser la vulnérabilité pour compromettre l'application et l'utiliser pour pénétrer plus profondément dans le réseau, en se déplaçant lentement et en essayant d'éviter d'être détectés. Pour ce faire, ils peuvent télécharger un shell web ou un autre fichier de type .exe, puis lui envoyer des commandes directement une fois qu'il a atterri. Tout ce que l'utilisateur exécute via son shell sera normalement exécuté par le serveur, en utilisant les niveaux d'autorisation définis pour l'application qui l'héberge. Pour le serveur, ces commandes proviennent de l'application et ne sont pas susceptibles d'être vérifiées ou examinées plus avant.

Tout cela fait de la vulnérabilité de l'accès illimité aux fichiers l'une des plus dangereuses à avoir sur votre réseau. La question n'est probablement pas de savoir si elle posera un problème, mais quand.

Comment éliminer la vulnérabilité liée à l'accès illimité aux fichiers ?

Alors, comment résoudre le problème de l'accès illimité aux fichiers ? Le plus simple est d'ajouter une ou plusieurs restrictions sur les types de fichiers qui peuvent être téléchargés. Ces restrictions peuvent être communiquées à l'utilisateur si vous le souhaitez, par exemple en lui indiquant que le site n'accepte que les fichiers Word ou texte, ou, dans le cas d'un site de partage d'images, que les fichiers .jpgs ou .gifs. En arrière-plan, vous devrez créer une liste blanche des extensions de fichiers acceptables et refuser toutes les autres. Des restrictions doivent également être imposées sur la longueur maximale des noms de fichiers. Si le nom d'un fichier contient des caractères spéciaux, ce qui pourrait indiquer une tentative de déclenchement d'une commande exécutable, le fichier doit également être rejeté.

Outre les types de fichiers et les règles de dénomination, vous voudrez également limiter la taille maximale de chaque fichier. La taille maximale doit être raisonnable et adaptée au type de fichier que l'application est censée collecter. Cela peut signifier un plafond de 10 mégaoctets environ pour les fichiers Word et une taille un peu plus importante, de l'ordre de 50 mégaoctets, pour les fichiers graphiques. Il est également possible de fixer des règles relatives à la taille minimale des fichiers, mais uniquement si la fourchette de taille des fichiers attendus est bien connue, ce qui peut être le cas si les utilisateurs remplissent et téléchargent un formulaire spécifique.

Les attaquants peuvent toujours trouver un moyen astucieux de faire passer un shell ou un autre programme potentiellement malveillant au-delà des restrictions relatives au type et à la taille des fichiers. Pour compenser, les fichiers collectés doivent toujours être stockés dans un répertoire privé sans privilèges d'exécution. Pour plus de sécurité, les fichiers peuvent être renommés par le système en une série de caractères aléatoires. Cela empêcherait les utilisateurs non autorisés extérieurs au réseau de rechercher l'emplacement du fichier qu'ils ont téléchargé, ce qui pourrait leur donner accès à votre réseau. Toutefois, si vous faites cela, vous devrez probablement mettre en place et maintenir un tableau reliant les noms de fichiers aléatoires à leurs désignations d'origine.

Enfin, tout ce qui arrive sur le réseau par le biais d'un téléchargement doit être analysé à la recherche de logiciels malveillants et de virus par les programmes défensifs que l'organisation utilise pour ces tâches. Cela ne permettra peut-être pas de tout détecter, mais il s'agit d'une couche de sécurité importante qui pourrait être utilisée pour détecter jusqu'à 90 % ou plus des fichiers malveillants les plus courants qui tentent d'entrer par le biais d'un téléchargement de fichiers.

Restreindre le problème du téléchargement de fichiers sans restriction

Une fois que plusieurs couches de sécurité sont mises en place au niveau du backend, le problème du téléchargement de fichiers sans restriction cesse d'être un problème. En fait, vous éliminez le problème en imposant des restrictions à vos téléchargements de fichiers, qui ne sont donc plus illimités. Seuls les bons fichiers sont autorisés à entrer, tandis que les vampires et les logiciels malveillants sont laissés à l'écart.

Pour en savoir plus, vous pouvez consulter l'aide-mémoire de l'OWASP Unrestricted File Upload Prevention, qui décrit certains des problèmes les plus courants lorsque ce type de situation est autorisé sur un réseau. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la présentation 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 façon de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Vous pensez être prêt à vous attaquer à cette vulnérabilité dès maintenant ? Rendez-vous sur le champ de bataille et testez vos compétences :

Les bases de données NoSQL sont de plus en plus populaires. Il est difficile de nier leur rapidité et leur facilité à traiter les données non structurées, en particulier pour les équipes de développement qui travaillent selon des méthodologies de plus en plus agiles.

Il faut du temps aux développeurs pour éliminer les vulnérabilités et autres difficultés des technologies émergentes. Ce n'est qu'après avoir été utilisée pendant un certain temps dans des applications de production que les problèmes commencent à remonter à la surface.

Les bases de données NoSQL sont similaires. Les développeurs doivent être conscients de certains risques clés afin de garantir la sécurité de leurs applications. L'un de ces risques est l'injection NoSQL.

Voyons ce qu'est une injection NoSQL, quels sont les dommages qu'elle peut causer et comment y remédier :

Comprendre l'injection NoSQL

L'injection NoSQL est causée par un grand nombre des mêmes vulnérabilités d'injection telles que l'injection XML ou SQL.

L'injection NoSQL permet aux attaquants de placer des commandes arbitraires dans une requête NoSQL. Cela leur permet de voler des données et même d'apporter des modifications à la base de données si leurs privilèges sont suffisamment élevés.

Lorsqu'une application place des données contrôlées par l'utilisateur directement dans une expression de requête NoSQL, ces expressions prennent souvent des fonctions ou ont des opérateurs intégrés qui peuvent être manipulés pour voler ou modifier des données. Et lorsqu'une telle chose est exécutée avec une intention malveillante, les conséquences peuvent être désastreuses.

Les bases de données MongoDB sont l'un des terrains de jeu les plus populaires pour exploiter cette vulnérabilité. "$ne : """ est l'opérateur équivalent à 1=1 dans le monde SQL. Ainsi, par exemple, un attaquant pourrait placer les caractères "$ne : ""' dans les champs nom d'utilisateur et mot de passe d'une interface utilisateur. Si le code est vulnérable à l'injection NoSQL, la base de données recherchera tous les enregistrements où le nom d'utilisateur et le mot de passe ne sont pas égaux à une chaîne vide. En d'autres termes : tous. Vous avez raison.

Si cette base de données n'est pas cryptée, l'attaquant peut voler les noms d'utilisateur et les mots de passe de chacun des utilisateurs qu'elle contient. Cela inclut les noms d'utilisateur et les mots de passe des administrateurs, ce qui leur donne un accès illimité à l'ensemble de la base de données.

Les attaquants tentent souvent d'introduire des valeurs qui sont toujours vraies. Une autre attaque courante consiste à injecter du code malveillant dans les propriétés définies comme des fonctions.

Par exemple, MongoDB utilise une fonction de recherche qui prend un objet avec une propriété appelée $where. La propriété $where est définie comme une fonction qui doit être évaluée à true ou false. Si cette fonction est modifiée de quelque manière que ce soit par l'utilisateur, il est probable qu'une injection NoSQL s'y cache.

Pour un aperçu détaillé des subtilités de l'injection NoSQL, consultez cet article d'InfoQ.

Pourquoi l'injection NoSQL est-elle dangereuse ?

L'injection NoSQL est dangereuse principalement parce qu'elle n'a pas encore reçu l'attention qu'elle mérite de la part de la communauté de la sécurité.

Les conséquences de l'injection NoSQL sont sensiblement les mêmes que celles de l'injection SQL traditionnelle. Des données peuvent être volées ou modifiées, des comptes peuvent être compromis par le vol de données et, ce qui est peut-être le plus grave, des données peuvent être complètement effacées si une commande d'effacement est lancée avec succès.

En définitive, MongoDB et les autres moteurs de base de données NoSQL sont vulnérables aux attaques. "Pas de SQL" ne signifie pas pas d'injections.
Heureusement, certains membres de la communauté en prennent note et font passer le message. Davantage de développeurs doivent s'informer afin de pouvoir protéger leurs applications contre des dangers peu connus qui peuvent devenir un véritable casse-tête s'ils sont exploités.

Vaincre l'injection NoSQL

L'injection NoSQL peut être difficile à vaincre. Malheureusement, il n'est pas possible d'utiliser des requêtes paramétrées comme dans le cas de l'injection SQL. Cependant, ce n'est pas impossible. Il existe quelques options pour vous aider :

• Les fuzzers peuvent être utilisés comme une méthode pour détecter les vulnérabilités. Cependant, comme c'est le cas pour beaucoup de choses dans la vie, l'approche la plus simple peut être la plus efficace. Dans ce cas, le bon vieil examen du code est votre meilleur allié.
• Lorsque vous révisez le code, recherchez les endroits où l'entrée de l'utilisateur pourrait fixer la valeur d'une expression ou modifier une fonction. Ne permettez pas à l'utilisateur de modifier vos requêtes.
• Veillez à attribuer à l'entrée de l'utilisateur la classe qui lui revient. Si c'est un nombre, transformez-le en nombre, si c'est une chaîne, transformez-la en chaîne et ainsi de suite.
• N'utilisez jamais $where ou d'autres fonctions d'évaluation similaires en même temps que les données saisies par l'utilisateur. Dans la plupart des cas, vous pouvez contourner le problème en modifiant le modèle de données ou le schéma.
• Essayez d'utiliser Mongoose comme pilote MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous indiquez à Mongoose que vos entrées sont des chaînes, elles seront converties en chaînes. Ainsi, tout objet transmis par un attaquant ne sera pas traité comme un objet, mais comme une chaîne de caractères.
• Renforcez votre base de données ! Créez des comptes utilisateurs à faibles privilèges, maximisez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité qui s'appliquent à votre organisation.

La facilité d'utilisation des bases de données NoSQL a pour inconvénient que les développeurs ont tendance à les mettre en place et à les utiliser sans se soucier de la sécurité.

Il est essentiel que vous preniez le temps d'apprendre à mettre en place une base de données NoSQL en toute sécurité et à vous protéger contre les injections NoSQL.

Par exemple, MongoDB Enterprise Edition dispose de capacités avancées de contrôle d'accès à vos documents. L'application du principe du "moindre privilège" peut constituer une bonne stratégie de défense en profondeur au cas où quelqu'un découvrirait une vulnérabilité dans votre application.

Pour résumer, voici ce que nous avons :

• Assainissez vos données avant de les utiliser dans une expression de requête NoSQL.
• Utilisez des pilotes qui vous aident, comme Mongoose
• Effectuer des revues de code portant spécifiquement sur la manière dont les données d'entrée sont utilisées dans les requêtes.
• Utilisez des fuzzers et des scanners pour essayer de trouver des vulnérabilités dans votre code.

NoSQL n'est pas No Injections

Les bases de données NoSQL gagnent rapidement en popularité en raison de leurs caractéristiques évolutives et de leur rapidité d'installation. La nouveauté de la technologie peut conduire les développeurs à utiliser les bases de données NoSQL sans penser à la manière de les sécuriser.

Les bases de données NoSQL peuvent être tout aussi vulnérables que les bases de données SQL aux attaques par injection, alors agissez avec prudence et faites attention à vos requêtes. Si vous souhaitez en savoir plus, consultez nos ressources d'apprentissage ou testez vos compétences avec notre démo gratuite.

Préparez-vous à l'avance et vous n'aurez plus à vous soucier des injections NoSQL dans vos applications. Trop facile !

Vous pensez être prêt à localiser, identifier et réparer une injection NoSQL dès maintenant ? Entrez dans l'arène du code sécurisé, guerrier :

Et c'est terminé pour 2018 ! Ce sera notre dernier billet pour l'année, mais nous serons de retour avec le prochain guide Coders Conquer Security le 10 janvier 2019. À bientôt !