QU’est-ce que OWASP?
Open Web Application Security Project, ou OWASP, est une organisation internationale à but non lucratif dédiée à la sécurité des applications web. L’un des principes fondamentaux D’OWASP est que tous leurs documents soient librement disponibles et facilement accessibles sur leur site web, ce qui permet à quiconque d’améliorer la sécurité de sa propre application web. Le matériel qu’ils offrent comprend de la documentation, des outils, des vidéos et des forums. Leur projet le plus connu est peut-être le Top 10 OWASP.
Qu’est-ce que le Top 10 OWASP?,
le Top 10 OWASP est un rapport régulièrement mis à jour décrivant les problèmes de sécurité pour la 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. OWASP se réfère au Top 10 comme un « document de sensibilisation » et ils recommandent que toutes les entreprises intègrent le rapport dans leurs processus afin de minimiser et/ou atténuer les risques de sécurité.
Voici les risques de sécurité signalés dans le rapport OWASP Top 10 2017:
1., Injection
Les attaques par Injection se produisent lorsque des données non fiables sont envoyées à un interpréteur de code via une entrée de formulaire ou une autre soumission de données à une application web. Par exemple, un attaquant peut entrer du code de base de données SQL dans un formulaire qui attend un nom d’utilisateur en texte brut. Si cette entrée de formulaire n’est pas correctement sécurisée, cela entraînerait l’exécution de ce code SQL. Ceci est connu comme une attaque par injection SQL.
Les attaques par Injection peuvent être évitées en validant et/ou en assainissant les données soumises par l’utilisateur., (La Validation signifie rejeter les données d’apparence suspecte, tandis que la désinfection consiste à nettoyer les parties d’apparence suspecte 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.
2. Authentification brisée
Les vulnérabilités des systèmes d’authentification (login) peuvent donner aux attaquants l’accès aux comptes d’utilisateurs et même la possibilité de compromettre l’ensemble d’un système à l’aide d’un compte administrateur., Par exemple, un attaquant peut prendre une liste contenant des milliers de combinaisons de nom d’utilisateur/mot de passe connues obtenues lors d’une violation de données et utiliser un script pour essayer toutes ces combinaisons sur un système de connexion pour voir s’il y en a qui fonctionnent.
certaines stratégies visant à atténuer les vulnérabilités d’authentification nécessitent une authentification à deux facteurs (2FA) ainsi que de limiter ou de retarder les tentatives de connexion répétées à l’aide de la limitation de débit.
3., Exposition aux données sensibles
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 sellor les utiliser à des fins néfastes. Une méthode populaire pour voler des informations sensibles utilise une attaque sur le chemin.
le risque d’exposition aux données peut être minimisé en chiffrant toutes les données sensibles et en désactivant la mise en cache* de toute information sensible. De plus, 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 pour les réutiliser. Par exemple, les navigateurs Web mettent souvent en cache des pages Web de sorte que si un utilisateur revisite ces pages dans un laps de temps fixe, le navigateur n’a pas à récupérer les pages du web.
4. XML External Entities (XEE)
Il s’agit d’une attaque contre une application web qui analyse L’entrée XML*. Cette entrée peut référencer une entité externe, tentant d’exploiter une vulnérabilité dans l’analyseur. Une « entité externe » dans ce contexte fait référence à une unité de stockage, telle qu’un disque dur., Un analyseur XML peut être dupé pour envoyer des données à une entité externe non autorisée, qui peut transmettre des données sensibles directement à un attaquant.
Les meilleurs moyens de prévenir les attaques XEE sont de demander aux applications web d’accepter un type de données moins complexe, tel que JSON**, ou à tout le moins de patcher 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 destiné à être à la fois lisible par l’homme et lisible par la machine. En raison de sa complexité et de failles de sécurité, il est maintenant progressivement d’utilisation dans de nombreuses applications web.,
**JavaScript Object Notation (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 est indépendant du langage et peut être interprété par de nombreux langages de programmation différents.
5. Contrôle d’accès cassé
Le contrôle d’accès fait référence à un système qui contrôle l’accès à des informations ou à des fonctionnalités. Les contrôles d’accès brisés permettent aux attaquants 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 le compte auquel il est connecté simplement en modifiant une partie d’une url, sans aucune 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 définit des contrôles stricts sur eux.
*de nombreux services émettent des jetons d’autorisation lorsque les utilisateurs se connectent. Chaque demande privilégiée qu’un utilisateur fait nécessitera que le jeton d’autorisation soit présent. Il s’agit d’un moyen sécurisé de s’assurer que l’utilisateur est bien ce qu’il dit être, sans avoir à saisir constamment ses informations de connexion.
6., Erreur de configuration de sécurité
la mauvaise configuration de sécurité est la vulnérabilité la plus courante de 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 montrer à un utilisateur des erreurs trop descriptives qui peuvent révéler des vulnérabilités dans l’application. Cela peut être atténué en supprimant toutes les fonctionnalités inutilisées du code et en veillant à ce que les messages d’erreur soient plus généraux.
7., Cross-Site Scripting
Cross-site scripting vulnérabilités se produisent lorsque les applications web permettent aux utilisateurs d’ajouter du code personnalisé dans un chemin d’url ou sur un site web qui sera vu par d’autres utilisateurs. Cette vulnérabilité peut être exploitée pour exécuter du code JavaScript malveillant sur le navigateur d’une victime. Par exemple, un attaquant pourrait envoyer un e-mail à une victime qui semble provenir d’une banque de confiance, avec un lien vers le site Web de cette banque. Ce lien pourrait avoir du code JavaScript malveillant étiqueté à la fin de l’url., Si le site de la banque n’est pas correctement protégé contre les scripts inter-sites, 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 les scripts inter-sites incluent l’échappement des requêtes HTTP non approuvées ainsi que la validation et / ou la désinfection du contenu généré par l’utilisateur. L’utilisation de frameworks de développement web modernes tels que ReactJS et Ruby on Rails fournit également une protection de script intersite intégrée.
8. Désérialisation non sécurisée
cette menace cible les nombreuses applications web qui sérialisent et désérialisent fréquemment les données., La sérialisation signifie prendre des objets du code de l’application et les convertir dans un format qui peut être utilisé à d’autres fins, telles que le stockage des données sur le disque ou leur diffusion en continu. La désérialisation est tout le contraire: convertir des données sérialisées en objets que l’application peut utiliser. La sérialisation est un peu comme emballer des meubles dans des boîtes avant un déménagement, et la désérialisation est comme déballer les boîtes et assembler les meubles après le déménagement. Une attaque de désérialisation non sécurisée est comme si les déménageurs trafiquaient le contenu des boîtes avant qu’elles ne soient déballées.,
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 des conséquences graves telles que des attaques DDoS et des attaques d’exécution de code à distance. Bien que des mesures puissent être prises pour essayer d’attraper les attaquants, telles que la surveillance de la désérialisation et la mise en œuvre de contrôles de type, le seul moyen sûr de se protéger contre les attaques de désérialisation non sécurisées est d’interdire la désérialisation des données provenant de sources non fiables.
9., Utilisation de composants avec des vulnérabilités connues
de nombreux développeurs web modernes utilisent des composants tels que des bibliothèques et des frameworks 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; exemple commun incluent des frameworks frontaux comme React et des bibliothèques plus petites qui ajoutaient des icônes de partage ou des tests a/B. Certains attaquants 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 attaquant trouvant une faille de sécurité dans l’un de ces composants pourrait laisser des centaines de milliers de sites vulnérables à exploiter.
Les développeurs de composants proposent souvent des correctifs de sécurité et des mises à jour pour combler les vulnérabilités connues, mais les développeurs d’applications web n’ont pas toujours les versions patchées ou les plus récentes des composants en cours d’exécution sur leurs applications., Pour minimiser le risque d’exécuter des composants avec des vulnérabilités connues, les développeurs doivent supprimer les composants inutilisés de leurs projets, ainsi que s’assurer qu’ils reçoivent des composants d’une source fiable et s’assurer qu’ils sont à jour.
10. Journalisation et surveillance insuffisantes
de nombreuses applications web ne prennent pas suffisamment de mesures pour détecter les violations de données. Le temps moyen de découverte d’une violation est d’environ 200 jours après son apparition. Cela donne aux attaquants beaucoup de temps pour causer des dégâts avant toute réponse., OWASP recommande aux développeurs web de mettre en œuvre la journalisation et la surveillance ainsi que des plans de réponse aux incidents pour s’assurer qu’ils sont informés des attaques sur leurs applications.
pour un aperçu plus technique et approfondi du Top 10 de L’OWASP, voir le rapport officiel .