L'Open Worldwide Application Security Project® (OWASP) est une fondation à but non lucratif qui travaille à l'amélioration de la sécurité des logiciels. Grâce à des projets de logiciels open source dirigés par la communauté, des dizaines de milliers de membres et des conférences éducatives et de formation de premier plan, la Fondation OWASP est la source pour les développeurs et les technologues pour sécuriser le Web.
Les 10 principales catégories de risques de sécurité des applications Web
cf : https://owasp.org/www-project-top-ten/
1- Broken access control
https://owasp.org/Top10/fr/A01_2021-Broken_Access_Control/
Ce type de faille est avéré lorsque l'utilisateur obtient des informations qu'il n'est pas censé voir. Il peut par exemple s'agir :
- d'url qui ne sont pas protégées et que le hacker déduit parce que les chemins et les valeurs passées dans les query string sont souvent simples et logiques
- d'identifiant qui s'appuient sur le localstorage et il suffit alors de changer la valeur dans le navigateur pour obtenir des infos d'autres utilisateurs, ...
2- Cryptographic Failures
https://owasp.org/Top10/fr/A02_2021-Cryptographic_Failures/
Anciennement connue sous le nom d'exposition de données sensibles, l'accent est maintenant mis sur les défaillances liées à la cryptographie (ou son absence). Ce qui conduit souvent à l'exposition de données sensibles. L'énumaration des faiblesses notables (Notable Common Weakness Enumerations ou CWEs) donne comme failles principales :
- CWE-259 : Utilisation d'un mot de passe codé en dur,
- CWE-327 : Algorithme cryptographique cassé ou risqué
- CWE-331 : Entropie insuffisante (aléa insuffisant)
3- Injection
https://owasp.org/Top10/fr/A03_2021-Injection/
Une application est vulnérable quand :
- les données venant de l'utilisateur ne sont pas validées, filtrées ou nettoyées par l'application ;
- des requêtes dynamiques ou des appels non paramétrés sans échappement par rapport au contexte sont envoyés à l'interpréteur ;
- des données hostiles sont utilisées au sein de paramètres de recherche de mapping objet - relationnel (ORM) pour extraire des données supplémentaires sensibles ;
- des données hostiles sont utilisées directement ou concaténées, par exemple lors de la construction de requêtes dynamiques, de commandes ou de procédures stockées pour des requêtes SQL ou des commandes OS.
Les injections les plus courantes se font dans le SQL, le NoSQL, les commandes OS, le mapping objet - relationnel, le LDAP, l'Expression Language et le Object Graph Navigation Library (OGNL). La façon de faire est la même pour tous les interpréteurs. La revue de code source est la meilleure manière de détecter si une application est vulnérable à l'injection. Le test automatique de toutes les données d'entrée via les paramètres, en-têtes, URL, cookies, JSON, SOAP et XML est fortement encouragé. Les organisations peuvent tirer profit de la puissance des outils d'analyse statique de code (SAST) ou d'analyse dynamique de l'application (DAST) en les intégrant dans leur chaine d'intégration continue (CI / CD) pour identifier avant déploiement en production les vulnérabilités liées aux injections.
Injection SQL contre injection XSS (cross-site scripting)
La principale différence entre une attaque par injection SQL et XSS est que les attaques par injection SQL sont utilisées pour voler des informations dans des bases de données, tandis que les attaques XSS sont utilisées pour rediriger les utilisateurs vers des sites Web où les attaquants peuvent leur voler des données. L'injection SQL est axée sur la base de données, tandis que XSS vise à attaquer les utilisateurs finaux.
Une attaque par injection SQL se produit lorsque du code de langage de requête structuré (SQL) est injecté dans des formulaires, des cookies ou des en-têtes http qui n'utilisent pas de méthodes de nettoyage ou de validation des données pour vérifier que les informations correspondent aux paramètres GET ou POST prescrits.
En revanche, une attaque XSS utilise un code malveillant pour rediriger les utilisateurs vers des sites Web malveillants, voler des cookies ou des informations d'identification, ou défigurer des sites Web. Cela est généralement accompli à l'aide de scripts malveillants qui sont exécutés dans les navigateurs clients à la suite d'une entrée utilisateur, d'instructions fonctionnelles, de demandes client ou d'autres expressions. Par exemple, les attaquants peuvent attaquer des URL conçues de manière malveillante via des tentatives d'hameçonnage par e-mail, des pièces jointes d'e-mail avec des liens intégrés, des cadres sur des sites Web légitimes et des forums Web connus pour être fréquemment visités par des utilisateurs ciblés. Alors que les attaques par injection SQL ciblent les informations dans les bases de données back-end, les attaques XSS se concentrent sur le vol de données du front-end du site Web.
Injection d'octets nuls
"Null Byte Injection" est une technique d'exploitation active utilisée pour contourner les filtres de vérification de l'intégrité dans l'infrastructure Web en ajoutant des caractères d'octet nul codés en URL (c'est-à-dire %00 ou 0x00 en hexadécimal) aux données fournies par l'utilisateur. Ce processus d'injection peut modifier la logique prévue de l'application et permettre à un adversaire malveillant d'obtenir un accès non autorisé aux fichiers système.
4- Insecure design
https://owasp.org/Top10/fr/A04_2021-Insecure_Design/
Insecure design peut se traduire par "Conception non sécurisée". C'est une vaste catégorie représentant différentes insuffisances, exprimées par « contrôles de conception manquants ou inefficaces ». La conception non sécurisée n'est pas la source de toutes les autres catégories de risques du Top 10. Il existe une différence entre une conception non sécurisée et une implémentation non sécurisée. Nous différencions les défauts de conception et les défauts d'implémentation pour une raison, ils ont des causes racines et des mesures correctives différentes. Une conception sécurisée peut toujours présenter des défauts d'implémentations conduisant à des vulnérabilités pouvant être exploitées. Une conception non sécurisée ne peut pas être corrigée par une implémentation parfaite car, par définition, les contrôles de sécurité nécessaires n'ont jamais été créés pour se défendre contre des attaques spécifiques. L'un des facteurs qui contribuent à la conception non sécurisée est le manque de profilage des risques commerciaux inhérent au logiciel ou au système en cours de développement, et donc l'incapacité à déterminer le niveau de sécurité requis.
Exemple de scénarios d'attaque
- Scénario 1 : Un processus de récupération d'informations d'identification peut inclure des « questions secrètes », ce qui est interdit par le NIST 800-63b, l'OWASP ASVS et le Top 10 de l'OWASP. Les questions et les réponses ne peuvent pas être considérées comme une preuve d'identité, car plus d'une personne peut connaître les réponses, c'est pourquoi elles sont interdites. Un tel code doit être supprimé et remplacé par une conception plus sécurisée.
- Scénario 2 : Une chaîne de cinéma permet des réductions sur les réservations de groupe et compte un maximum de quinze participants avant d'exiger un acompte. Les attaquants pourraient modéliser ce cas d'usage et tester s'ils peuvent réserver six cents places et tous les cinémas à la fois en quelques demandes, provoquant une perte massive de revenus.
- Scénario 3 : Le site e-commerce d'une chaîne de vente au détail n'est pas protégé contre les robots qui achètent des cartes vidéo haut de gamme pour les revendre sur le marché noir. Cela crée une mauvaise publicité pour les fabricants de cartes vidéo et les propriétaires de chaînes de vente au détail, provoque du ressentiment de la part des acheteurs qui ne peuvent pas se procurer ces cartes quel qu'en soit le prix. Des règles prudentes de conception anti-bot, telles que les achats effectués dans les quelques secondes suivant la disponibilité, peuvent identifier des achats non authentiques et rejeter de telles transactions.
5- Security Misconfiguration
https://owasp.org/Top10/fr/A05_2021-Security_Misconfiguration/
En progression depuis la sixième place, 90 % des applications ont été testées pour une forme de mauvaise configuration, avec un taux d'incidence moyen de 4,51 % et plus de 208 000 occurrences de Common Weakness Enumeration (CWE) dans cette catégorie. Avec une plus grande part de logiciels offrant une configuration riche, il n'est pas surprenant de voir cette catégorie gagner une place. Les CWEs notables incluses sont CWE-16 Configuration et CWE-611 Improper Restriction of XML External Entity Reference.
Par exemple, l'application peut être vulnérable si la version du logiciel est obsolète ou vulnérable (voir A06:2021-Composants vulnérables et obsolètes).
6- Vulnerable and outdated components
https://owasp.org/Top10/fr/A06_2021-Vulnerable_and_Outdated_Components/
Les composants vulnérables sont un problème connu pour lequel nous avons du mal à tester et à évaluer les risques. Elle est la seule catégorie à ne pas avoir de Common Vulnerability and Exposures (CVEs) associées aux CWEs concernées, en conséquence les coefficients d'impact et de poids ont été renseignés à 5.0 par défaut. Les CWEs notables incluses sont CWE-1104: Use of Unmaintained Third-Party Components.
7- Identification and authentification failure
https://owasp.org/Top10/fr/A07_2021-Identification_and_Authentication_Failures/
La confirmation de l'identité, de l'authentification et de la session de l'utilisateur sont essentielles pour se protéger des attaques liées à l'authentification. Il peut y avoir des faiblesses d'authentification si l'application :
- autorise les attaques automatisées telles que le bourrage des informations d'identification, où l'attaquant dispose d'une liste de noms d'utilisateurs valides et mots de passe ;
- permet la force brute* ou d'autres attaques automatisées ;
- autorise les mots de passe par défaut, faibles ou bien connus, tels que "Password1" ou "admin / admin" ;
- ...
* Une attaque par force brute (bruteforce attack) consiste à tester, l’une après l’autre, chaque combinaison possible d’un mot de passe ou d’une clé pour un identifiant donné afin se connecter au service ciblé. Il s’agit d’une méthode ancienne et répandue chez les pirates. Le temps nécessaire à celle-ci dépend du nombre de possibilités, de la vitesse que met l’attaquant pour tester chaque combinaison et des défenses qui lui sont opposées. Ce type d’attaque étant relativement simple, un organisme peut disposer de systèmes permettant de se protéger de ce type de comportement. La première ligne du système de défense est le blocage de comptes après un nombre limité d’échecs d’authentification pour un même identifiant. Le fonctionnement de l’attaque par force brute est proche de l’attaque par credential stuffing, mais est moins élaborée.
8- Software and Data Integrety Failures
https://owasp.org/Top10/fr/A08_2021-Software_and_Data_Integrity_Failures/
La catégorie "Manque d'intégrité des données et du logiciel" est apparue en 2021. Elle se concentre sur la formulation d'hypothèses relatives aux mises à jour logicielles, aux données critiques et aux pipelines CI/CD sans vérification de l'intégrité. Il s'agit de l'un des impacts pondérés les plus élevés des données CVE/CVSS (Common Vulnerability and Exposures/Common Vulnerability Scoring System). Les Common Weakness Enumerations (CWE) notables comprennent CWE-829 : Inclusion of Functionality from Untrusted Control Sphere, CWE-494 : Download of Code Without Integrity Check, et CWE-502 : Deserialization of Untrusted Data.
Les défaillances de l'intégrité des logiciels et des données sont liées au code et à l'infrastructure qui ne sont pas protégés contre les violations de l'intégrité. C'est le cas, par exemple, lorsqu'une application s'appuie sur des plugins, des bibliothèques ou des modules provenant de sources, de dépôts et de réseaux de diffusion de contenu (CDN) non fiables. Un pipeline CI/CD non sécurisé peut introduire un risque d'accès non autorisé, de code malveillant ou de compromission du système. Enfin, de nombreuses applications intègrent désormais une fonctionnalité de mise à jour automatique, où les mises à jour sont téléchargées sans vérification d'intégrité suffisante et appliquées à l'application précédemment fiable. Les attaquants pourraient potentiellement télécharger leurs propres mises à jour pour les distribuer et les exécuter sur toutes les installations. Un autre exemple est celui des objets ou des données qui sont codés ou sérialisés dans une structure qu'un attaquant peut voir et modifier et qui sont vulnérables à une désérialisation non sécurisée.
9- Security Logging and Monitoring Failures
https://owasp.org/Top10/fr/A09_2021-Security_Logging_and_Monitoring_Failures/
La journalisation et la surveillance de la sécurité sont issues de l'enquête de la communauté Top 10 (n°3), en légère hausse par rapport à la dixième position dans le Top 10 2017 de l'OWASP. La journalisation et la surveillance peuvent être difficiles à tester, impliquant souvent des entretiens ou demandant si des attaques ont été détectées lors d'un test d'intrusion. Il n'y a pas beaucoup de données CVE/CVSS pour cette catégorie, mais la détection et la réponse aux brèches sont essentielles. Il n'en reste pas moins qu'elle peut avoir un impact considérable sur la responsabilité, la visibilité, l'alerte en cas d'incident et la forensique. Cette catégorie s'étend au-delà de CWE-778 Insufficient Logging pour inclure
- CWE-117 Improper Output Neutralization for Logs,
- CWE-223 Omission of Security-relevant Information,
- CWE-532 Insertion of Sensitive Information into Log File.
Par exemple, si l’application est incapable de détecter, de générer des remontées d'information et des alertes en temps réel, ou assimilé, en cas d’attaque active, elle se trouve dans le cas d'un manque de surveillance.
10- Server-Side Request Forgery (SSRF)
https://owasp.org/Top10/fr/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
La "falsification de requête côté serveur" a été ajoutée à partir de l'enquête communautaire Top 10 (n°1). Les données montrent un taux d'incidence relativement faible avec une couverture de test supérieure à la moyenne et des évaluations du potentiel d'exploitation et d'impact supérieures à la moyenne. Comme les nouvelles entrées sont susceptibles d'être une seule ou un petit groupe de Common Weakness Enumerations (CWE) pour l'attention et la sensibilisation, l'espoir est qu'elles fassent l'objet d'une attention particulière et qu'elles puissent être intégrées dans une catégorie plus importante dans une prochaine édition.
Une faille SSRF se produit lorsqu'une application web récupère une ressource distante sans valider l'URL fournie par l'utilisateur. Elle permet à un attaquant de contraindre l'application à envoyer une requête élaborée à une destination inattendue, même si elle est protégée par un pare-feu, un VPN ou un autre type de liste de contrôle d'accès au réseau (ACL).
Comme les applications Web modernes offrent aux utilisateurs finaux des fonctions pratiques, la récupération d'une URL devient un scénario courant. Par conséquent, l'incidence d'une SSRF augmente. De même, la gravité de ce phénomène augmente en raison des services en nuage et de la complexité des architectures.
OWASP Juice Shop
Tester OWASP Juice Shop : https://demo.owasp-juice.shop/
OWASP Juice Shop est une application web qui peut être utilisée dans les formations à la sécurité, les démonstrations de sensibilisation, les CTF et comme cobaye pour les outils de sécurité. Juice Shop englobe les vulnérabilités de l'ensemble du Top Ten OWASP ainsi que de nombreuses autres failles de sécurité trouvées dans les applications du monde réel !
Installer OWASP Juice Shop localement
Source : https://github.com/juice-shop/juice-shop#from-sources
Vous devez préalablement avoir installé node (node -v et npm -v dans git bash pour vérifier)
git clone https://github.com/juice-shop/juice-shop.git cd juice-shop npm install npm start
Voir l'application sur http://localhost:3000
Voir tous les types de failles de sécurité qu'il sera possible de retrouver sur l'application
Exercice 1 : Partez à la chasse aux challenges !
Le premier challenge consiste à trouver la page score-board : https://pwning.owasp-juice.shop/part2/score-board.html
Les autres challenges sont décrits dans cette page cachée. Ils sont classés par thématique et par difficulté.
Vous verrez que l'on peut assez facilement trouver de l'aide pour découvrir les différentes failles.
Exercice 2 : Montrez vos failles !
Par groupe de 2, choisissez une famille faille de sécurité et mettez en place une application (html, js ou php) qui contient au moins 2 failles de cette famille. Vous donnez des explication sur la façon dont il faut s'y prendre pour installer votre application et des indices pour trouver les failles. Chaque application sera scrutée par l'ensemble du groupe pendant 20mn pour trouver les failles un peu comme sur "Juice Shop"