Le Open Web Application Security Project tient une liste régulièrement mise à jour des soucis les plus pressants en matière de sécurité des applications web.
Cet article s'articule autour des points suivants :
Contenu associé
Qu'est-ce que la sécurité des applications web ?
Attaque par force brute
violation de données
Attaque de l'homme du milieu
Attaque par débordement de tampon (buffer overflow)
Abonnez-vous à theNET, le récapitulatif mensuel de Cloudflare des idées les plus populaires concernant Internet !
Copier le lien de l'article
L'Open Web Application Security Project, ou OWASP, est une organisation internationale à but non lucratif qui se consacre à la sécurité des applications web. L'un des principes fondamentaux de l'OWASP est que tout son contenu soit disponibles gratuitement et facilement accessibles sur son site web, ce qui permet à chacun d'améliorer la sécurité de ses propres applications web. Le contenu qu'elle propose comprend de la documentation, des outils, des vidéos et des forums. Leur projet le plus connu est peut-être le Top 10 de l'OWASP.
Le Top 10 de l'OWASP est un rapport régulièrement mis à jour qui expose les préoccupations en matière de sécurité des applications web, en se concentrant sur les 10 risques les plus critiques. Le rapport est rédigé par une équipe d'experts en sécurité du monde entier. L'OWASP considère le Top 10 comme un « document de sensibilisation » et recommande à toutes les entreprises d'intégrer le rapport dans leurs processus afin de minimiser et/ou d'atténuer les risques de sécurité.
Vous trouverez ci-dessous les risques de sécurité signalés dans le rapport 2017 du Top 10 de l'OWASP.
Les attaques par injection se produisent lorsque des données non fiables sont envoyées à un interpréteur de code par le biais du contenu d'un formulaire ou d'une autre soumission de données à une application web. Par exemple, un attaquant pourrait saisir du code de base de données SQL dans un formulaire qui attend un nom d'utilisateur en texte clair. Si les données de ce formulaire ne sont pas correctement sécurisées, le code SQL sera exécuté. C'est ce qu'on appelle une attaque par injection SQL.
Les attaques par injection peuvent être évitées en validant et/ou en assainissant les données soumises par les utilisateurs. (La validation signifie le rejet des données suspectes, tandis que l'assainissement consiste à nettoyer les parties suspectes des données). En outre, un administrateur de base de données peut définir des contrôles pour minimiser la quantité d'informations qu'une attaque par injection peut exposer.
En savoir plus sur la manière de prévenir les attaques par injection SQL.
Les vulnérabilités des systèmes d'authentification (login) peuvent donner aux pirates l'accès à des comptes d'utilisateurs et même la possibilité de compromettre un système entier en utilisant un compte administrateur. Par exemple, un attaquant peut prendre une liste contenant des milliers de combinaisons connues de noms d'utilisateur/mots de passe obtenues lors d'une violation de données et utiliser un script pour essayer toutes ces combinaisons sur un système de connexion afin de voir si certaines fonctionnent.
Certaines stratégies visant à atténuer les vulnérabilités de l'authentification consistent à exiger une authentification à deux facteurs (2FA) ainsi qu'à limiter ou à retarder les tentatives de connexion répétées en utilisant la limitation du taux.
Si les applications web ne protègent pas les données sensibles telles que les informations financières et les mots de passe, les attaquants peuvent accéder à ces données et les vendre ou les utiliser à des fins malveillantes. L'une des méthodes les plus populaires pour voler des informations sensibles est l'attaque sur le chemin.
Le risque d'exposition des données peut être minimisé en chiffrant toutes les données sensibles ainsi qu'en désactivant la *mise en cache de toute information sensible. En outre, les développeurs d'applications web doivent veiller à ne pas stocker inutilement des données sensibles.
*La mise en cache est la pratique consistant à stocker temporairement des données en vue de leur réutilisation. Par exemple, les navigateurs web mettent souvent en cache des pages web de sorte que si un utilisateur visite à nouveau ces pages dans un délai déterminé, le navigateur n'a pas besoin d'aller les chercher sur le web.
Il s'agit d'une attaque contre une application web qui analyse les contenus XML*. Ce contenu peut faire référence à une entité externe, en essayant d'exploiter une vulnérabilité dans l'analyseur. Une "entité externe" dans ce contexte fait référence à une unité de stockage, comme un disque dur. Un analyseur XML peut être utilisé pour envoyer des données à une entité externe non autorisée, ce qui peut transmettre des données sensibles directement à un pirate.
Le meilleur moyen de prévenir les attaques XEE est de faire en sorte que les applications web acceptent un type de données moins complexe, comme JSON**, ou tout au moins de corriger les analyseurs XML et de désactiver l'utilisation d'entités externes dans une application XML.
*XML ou Extensible Markup Language est un langage de balisage conçu pour être à la fois lisible par l'homme et par la machine. En raison de sa complexité et de ses vulnérabilités en matière de sécurité, il est en train d'être progressivement abandonné dans de nombreuses applications web.
**La notation d'objet JavaScript (JSON) est un type de notation simple, lisible par l'homme, souvent utilisé pour transmettre des données sur Internet. Bien qu'il ait été créé à l'origine pour JavaScript, JSON ne dépend d'aucun langage et peut être interprété par de nombreux langages de programmation différents.
Le contrôle d'accès désigne un système qui contrôle l'accès aux informations ou aux fonctionnalités. Les contrôles d'accès rompus permettent aux pirates de contourner l'autorisation et d'effectuer des tâches comme s'ils étaient des utilisateurs privilégiés tels que les administrateurs. Par exemple, une application web pourrait permettre à un utilisateur de modifier son compte en modifiant simplement une partie de son url, sans autre vérification.
Les contrôles d'accès peuvent être sécurisés en s'assurant qu'une application web utilise des jetons d'autorisation* et les soumette à des contrôles stricts.
*De nombreux services émettent des jetons d'autorisation lorsque les utilisateurs se connectent. Toute demande privilégiée faite par un utilisateur nécessite la présence du jeton d'autorisation. C'est un moyen sûr de s'assurer que l'utilisateur est bien celui qu'il prétend être, sans avoir à saisir constamment ses identifiants de connexion.
La mauvaise configuration de la sécurité est la vulnérabilité la plus courante sur la liste, et résulte souvent de l'utilisation de configurations par défaut ou de l'affichage d'erreurs excessivement verbeuses. Par exemple, une application peut présenter à l'utilisateur des erreurs trop descriptives qui peuvent révéler des vulnérabilités dans l'application. Il est possible d'atténuer ce problème en supprimant toute fonctionnalité inutilisée dans le code et en veillant à ce que les messages d'erreur soient plus généraux.
Les vulnérabilités du script de site à site se produisent lorsque des applications web permettent aux utilisateurs d'ajouter un code personnalisé dans un chemin d'accès ou sur un site Web qui sera vu par d'autres utilisateurs. Cette vulnérabilité peut être exploitée pour exécuter un code JavaScript malveillant sur le navigateur d'une victime. Par exemple, un attaquant pourrait envoyer un courriel à une victime, qui semble provenir d'une banque de confiance, avec un lien vers le site Web de cette banque. Ce lien pourrait comporter un code JavaScript malveillant marqué à la fin de l'url. Si le site de la banque n'est pas correctement protégé contre le script de site à site, alors ce code malveillant sera exécuté dans le navigateur web de la victime lorsqu'elle cliquera sur le lien.
Les stratégies d'atténuation pour le script de site à site consistent à éviter les requêtes HTTP non fiables ainsi qu'à valider et/ou à assainir le contenu généré par les utilisateurs. L'utilisation de plateformes de développement web modernes comme ReactJS et Ruby on Rails offre également une protection intégrée du script de site à site.
Cette menace vise les nombreuses applications web qui sérialisent et désérialisent fréquemment les données. La sérialisation consiste à prendre des objets dans le code de l'application et à les convertir dans un format qui peut être utilisé à d'autres fins, comme le stockage des données sur disque ou la diffusion en continu. La désérialisation est tout le contraire : elle consiste à reconvertir les données sérialisées en objets que l'application peut utiliser. La sérialisation est un peu comme l'emballage des meubles dans des boîtes avant un déménagement, et la désérialisation est comme le déballage des boîtes et l'assemblage des meubles après le déménagement. Une attaque de désérialisation non sécurisée revient à demander aux déménageurs de manipuler le contenu des boîtes avant de les déballer.
Un exploit de désérialisation non sécurisé est le résultat de la désérialisation de données provenant de sources non fiables, et peut entraîner de graves conséquences comme des attaques DDoS et des attaques d'exécution de code à distance. Bien que des mesures puissent être prises pour tenter d'attraper les attaquants, telles que la surveillance de la désérialisation et la mise en place de contrôles de type, la seule façon sûre de se protéger contre les attaques de désérialisation non sécurisées est d'interdire la désérialisation de données provenant de sources non fiables.
De nombreux développeurs web modernes utilisent des composants tels que des bibliothèques et des cadres dans leurs applications web. Ces composants sont des logiciels qui aident les développeurs à éviter le travail redondant et à fournir les fonctionnalités nécessaires ; des exemples courants sont les cadres de front-end comme React et les petites bibliothèques qui avaient l'habitude d'ajouter des icônes de partage ou des tests a/b. Certains pirates recherchent des vulnérabilités dans ces composants qu'ils peuvent ensuite utiliser pour orchestrer des attaques. Certains des composants les plus populaires sont utilisés sur des centaines de milliers de sites Web ; un pirate trouvant une faille de sécurité dans l'un de ces composants pourrait laisser des centaines de milliers de sites vulnérables à une exploitation.
Les développeurs de composants proposent souvent des correctifs de sécurité et des mises à jour pour remédier aux vulnérabilités connues, mais les développeurs d'applications web ne disposent pas toujours des versions les plus récentes ou des correctifs de composants qui s'exécutent sur leurs applications. Pour réduire au minimum le risque d'exécuter des composants présentant des vulnérabilités connues, les développeurs doivent supprimer les composants inutilisés de leurs projets, tout en s'assurant qu'ils reçoivent des composants d'une source fiable et qu'ils sont à jour.
De nombreuses applications web ne prennent pas suffisamment de mesures pour détecter les violations de données. Le délai moyen de découverte d'une violation est d'environ 200 jours après qu'elle se soit produite. Cela donne aux pirates beaucoup de temps pour causer des dommages avant qu'il n'y ait une riposte. L'OWASP recommande aux développeurs web de mettre en place un système de journalisation et de surveillance ainsi que des plans de réponse aux incidents afin de s'assurer qu'ils sont informés des attaques dont leurs applications font l'objet.
Pour un regard plus technique et plus approfondi sur le Top 10 de l'OWASP, voir le rapport officiel.