1. Introduction

Chaque année, l'OWASP (Open Web Application Security Project) publie le Top 10 des vulnérabilités de sécurité. Il représente un large consensus sur les risques de sécurité les plus critiques pour les applications Web. Comprendre les dix principaux types de vulnérabilités WEB et être doué pour découvrir les vulnérabilités dans les tests d'intrusion sont les exigences de base pour le personnel de l'industrie de la sécurité.

2. TOP 10 OWASP

2.1 Top10 OWASP 2022

1. Contrôle d'accès cassé
2. Mécanisme de cryptage inefficace
3. Injection
4. Conception non sécurisée
5. Mauvaise configuration de la sécurité 6.
Composants vulnérables et obsolètes
7. Échecs d'identification et d'authentification
8. Échecs d'intégrité des logiciels et des données
9. Échec de la journalisation et de la surveillance de la sécurité
10. Serveur Contrefaçon de demande parallèle (SSRF)

2.2 Brève introduction du Top10 de l'OWASP

2.2.1 Contrôle d'accès brisé

Le contrôle d'accès applique des politiques pour empêcher les utilisateurs d'opérer en dehors de leurs autorisations spécifiées. En raison de vulnérabilités d'accès, des utilisateurs non authentifiés ou indésirables peuvent accéder à des données et processus confidentiels et à des paramètres de privilèges utilisateur. La manipulation des métadonnées, y compris la falsification ou la relecture des jetons de contrôle d'accès JSON Web Token (JWT), ou la modification des cookies ou des champs masqués pour élever les privilèges ou exploiter l'invalidation JWT, sont des exemples de vulnérabilités de contrôle d'accès. Le deuxième exemple est une violation du principe de refus par défaut. L'accès doit être accordé uniquement à des rôles, capacités ou utilisateurs spécifiques, mais tout le monde y a accès. De tels bogues pourraient donner aux attaquants un accès facile à tout ce qu'ils veulent. Cependant, des mécanismes de sécurité d'accès inadéquats et des problèmes de gestion des identités ou des mots de passe peuvent être évités en appliquant des méthodes de codage sécurisées et en prenant des précautions telles que la désactivation des comptes et des restrictions d'administrateur et l'installation d'une authentification multifacteur.

D'autres techniques de prévention comprennent:

- N'appliquez les mécanismes de contrôle d'accès qu'une seule fois et réutilisez-les lors de l'application pour réduire le partage des ressources cross-origin (CORS).
- Le modèle de domaine doit imposer des contraintes différentes des contraintes métier de l'application.
- Restreindre l'accès aux interfaces de programmation d'applications (API) et aux contrôleurs pour atténuer l'impact des outils d'attaque automatisés.
- Enregistrez les échecs dans le contrôle d'accès et alertez les administrateurs si nécessaire.
- Les contrôles d'accès du modèle doivent appliquer la propriété des enregistrements, plutôt que d'accorder aux utilisateurs l'autorisation de créer, d'afficher, de modifier ou de supprimer des informations.

2.2.2 Défaillance du mécanisme de confidentialité

Le point ici est que les erreurs de mot de passe, ou leur absence, exposent souvent des données sensibles. Voici des exemples typiques de divulgation d'informations sensibles

        Jetons de session
        Identifiants de connexion et mots de passe
        Transactions en ligne
        Informations personnelles (Switching Service Network ou SSN, Health Records, etc.)
        Par exemple, une application peut utiliser le cryptage automatique de la base de données pour crypter en toute sécurité les données de carte de crédit. Malheureusement, lorsque ces informations sont consultées, elles sont immédiatement décryptées, provoquant des erreurs d'injection SQL pour extraire les informations de carte de crédit en texte clair, qui pourraient être exploitées par des intrus.

Ces défaillances peuvent être évitées en utilisant les techniques préventives suivantes :

- Vous devez stocker les mots de passe à l'aide d'un algorithme de hachage robuste, salé et adaptatif avec un facteur de retard, tel que scrypt, Argon2, PBKDF2 ou bcrypt - Le protocole de transfert de fichiers (FTP) et le protocole de transfert de courrier simple (SMTP
) doivent être évités lors du transfert de données sensibles Les protocoles plus anciens comme SMTP)
- il est recommandé d'implémenter un cryptage authentifié au lieu d'utiliser simplement le cryptage
- doivent générer une clé aléatoire cryptographique et la stocker sous forme de tableau d'octets. Si vous utilisez une phrase de passe, vous devez la changer en quelque chose comme une clé à l'aide d'un algorithme de création de clé basé sur la phrase de passe

2.2.3 Injection

L'injection (ou injection SQL) est une attaque de base de données contre un site Web qui utilise le langage SQL (Structured Query Language) pour obtenir des informations ou effectuer des activités qui nécessitent généralement un compte d'utilisateur authentifié. Il est difficile pour les programmes d'interpréter ces codes à partir de leur propre code, ce qui permet aux attaquants d'effectuer des attaques par injection pour accéder à des zones protégées et à des données sensibles se faisant passer pour des utilisateurs de confiance. L'injection comprend l'injection SQL, l'injection de commande, l'injection CRLF, l'injection LDAP, etc.

Certaines techniques de prévention comprennent:

- Une alternative de loin préférable consiste à utiliser une API qui évite entièrement l'interpréteur, fournit une API paramétrée ou translocation vers un outil de mappage objet-relationnel (ORM).
- Une validation agressive côté serveur des entrées est recommandée. De nombreuses applications, y compris les champs de texte et les API pour les applications mobiles, nécessitent des caractères spéciaux.
-L'utilisation de LIMIT et d'autres contraintes SQL dans les requêtes est un excellent moyen d'éviter l'exposition de grandes quantités de données en cas d'injection SQL.

2.2.4 Conception dangereuse

Il s'agit d'une toute nouvelle catégorie pour 2021 qui se concentre sur les défauts de conception et d'architecture et nécessite une plus grande utilisation de la modélisation des menaces, des recommandations de sécurité de conception et des architectures de référence. La conception non sécurisée est une vaste catégorie englobant des problèmes tels que "la conception de contrôle manquante ou inadéquate". Cela ne signifie pas que la conception non sécurisée est à l'origine de toutes les dix autres principales catégories de risques.

Une conception non sécurisée n'est pas la même chose qu'une implémentation non sécurisée. Même lorsque la conception est sécurisée, les défauts de mise en œuvre peuvent entraîner des vulnérabilités. D'un autre côté, une conception défectueuse ne peut pas être compensée par une implémentation parfaite, car les protections de sécurité nécessaires n'existent pas pour se protéger contre des menaces spécifiques.

Ces menaces peuvent être évitées en utilisant les techniques préventives suivantes :

-Configurez et utilisez un cycle de vie de développement sécurisé avec l'aide d'experts AppSec pour évaluer et créer des protections de sécurité et de confidentialité.
- La modélisation des menaces est recommandée pour l'authentification des clés, le contrôle d'accès, la logique d'application et les processus fondamentaux.
- Incluez des termes et des contrôles de sécurité dans les user stories.
- La conception de l'isolement des locataires à tous les niveaux est également considérée comme une approche préventive pratique.

2.2.5 Erreur de configuration de la sécurité

Les problèmes généraux de configuration de la sécurité, tels que les contrôles d'accès mal configurés, créent des dangers importants en offrant aux attaquants un accès rapide et facile aux données critiques et aux zones du site.

Solutions courantes :

- Un processus de durcissement systématique permet un déploiement rapide et facile d'environnements sécurisés. La configuration des environnements de développement, de contrôle qualité et d'exploitation doit être similaire, avec des autorisations utilisateur différentes.
- Il est idéal pour automatiser le processus de mise en place d'un nouvel environnement sécurisé, en économisant le temps et les efforts nécessaires. Les fonctionnalités et frameworks inutilisés doivent être supprimés ou non installés. Une plate-forme principale sans fonctionnalités, composants, documentation ou démos inutiles réduit la probabilité de vulnérabilités de configuration.

2.2.6 Composants vulnérables et obsolètes

Solutions courantes :

2.2.7 Échec de l'identification et de l'authentification

Inclut maintenant les CWE liés aux problèmes d'identification. Des problèmes de sécurité surviennent lorsque les attaquants accèdent aux informations de l'utilisateur, à la récupération du mot de passe, aux sessions d'identification et à d'autres identifiants de connexion. Comme son nom l'indique, les échecs d'identité et d'authentification incluent les pirates exploitant ces vulnérabilités pour exploiter une authentification insuffisante.

Si l'application permet des attaques automatisées telles que le credential stuffing (lorsque l'attaquant a accès à de véritables listes d'utilisateurs et de mots de passe) ou des mots de passe prédéfinis, faibles et courants (tels que "Mot de passe1" ou "admin/admin"), ceux-ci peuvent être des signes d'un faille d'authentification

Pour éviter de tels écueils, les précautions suivantes doivent être prises :

-L'authentification multifacteur doit être utilisée dans la mesure du possible pour éviter le bourrage d'informations d'identification automatisé, les attaques par force brute et la réutilisation des informations d'identification volées.
- Améliore la sécurité des mots de passe en vérifiant les mots de passe nouveaux ou modifiés par rapport à une base de données de 10 000 pires mots de passe.
- L'utilisation du même message pour chaque résultat permet d'éviter les attaques d'énumération de compte sur la récupération de mot de passe, l'enregistrement et les chemins d'API.
N'installez aucune information d'identification par défaut, en particulier pour les utilisateurs administratifs.

2.2.8 Problèmes d'intégrité des logiciels et des données

Alors que de plus en plus d'informations sensibles sont stockées dans des bases de données, vulnérables aux failles de sécurité, la question de l'intégrité des données devient critique pour les logiciels.

Il s'agit d'une nouvelle catégorie qui se concentre sur l'assurance de l'intégrité des mises à jour logicielles, des données critiques et des programmes CI/CD sans les valider. Par exemple, lorsqu'une application utilise des extensions, des modules ou des référentiels provenant de réseaux de diffusion de contenu (CDN) ou de sources non autorisées. Les processus d'intégration continue/livraison continue ( CI/CD ) non protégés peuvent augmenter le risque de code malveillant, de systèmes compromis ou d'accès non autorisé.

Les techniques de prévention comprennent :

- On peut utiliser des mesures telles que les signatures numériques pour confirmer que les données ou les logiciels proviennent de la source prévue sans aucune falsification.
- Des outils de sécurité pour la chaîne d'approvisionnement logicielle, tels que OWASP CycloneDX ou OWASP Dependency-Check, peuvent être utilisés pour s'assurer que les composants ne contiennent pas de défauts de conception.
- Il est nécessaire de s'assurer que les flux de travail CI/CD disposent de la segmentation, du contrôle d'accès et du paramétrage requis pour protéger l'intégrité du code tout au long des opérations de configuration et de déploiement.
- Les données compilées non signées ou non cryptées ne doivent pas être envoyées à des clients non fiables à moins qu'elles n'aient été testées en intégrité ou signées numériquement pour identifier les modifications ou les duplications de données.

2.2.9 Échec de la surveillance et de l'enregistrement du journal de sécurité

L'absence de suivi en présence de comportements et d'événements suspects peut élargir l'intervalle de temps non surveillé, permettant aux failles de sécurité de passer inaperçues plus longtemps qu'avec une meilleure journalisation. Cette section OWASP Top 10 2021 est conçue pour aider à identifier, escalader et résoudre les violations récentes. Sans journalisation et surveillance, il est impossible de détecter les failles de sécurité.

- Confirmez que tous les problèmes d'authentification, de sécurité d'accès et de vérification des données côté serveur sont enregistrés avec suffisamment d'informations sur les utilisateurs pour détecter les comptes suspects ou frauduleux et stockés suffisamment longtemps pour permettre une enquête complète retardée.
-Assurez-vous que les journaux sont créés dans un format consommable par le système de gestion des journaux.
-Créer ou appliquer des politiques pour les efforts de récupération et de réponse aux incidents, telles que NIST 800-61r2 ou version ultérieure.
-Assurez-vous que les données du journal sont correctement encodées pour éviter les intrusions ou les cybermenaces aux systèmes de surveillance.

2.2.10 Contrefaçon de demande de serveur (SSRF)

Les résultats pour cette catégorie montrent une couverture de test supérieure à la moyenne, une incidence raisonnablement faible et des taux d'impact et d'utilisation supérieurs à la moyenne. SSRF a été développé là où la requête côté serveur n'authentifie pas l'URL fournie par l'utilisateur. Cela permet à un attaquant de tromper une application pour qu'elle transmette des requêtes falsifiées vers un emplacement indésirable, même si cet emplacement est protégé par un réseau privé virtuel (VPN), un pare-feu ou une liste de contrôle d'accès réseau (ACL).

L'obtention d'URL est devenue une situation courante, car les nouvelles applications en ligne offrent des fonctionnalités pratiques aux utilisateurs finaux. Par conséquent, la prévalence de SSRF augmente. De plus, en raison des services cloud et de la complexité de la conception, la force de SSRF augmente. Dans cet esprit, de telles attaques peuvent être évitées en utilisant les techniques préventives suivantes :

- Afin de limiter l'impact de SSRF, les fonctions d'accès aux ressources distantes doivent être séparées en différents réseaux.
- Installez un paramètre de pare-feu "refusé par défaut" ou une règle de contrôle d'accès au réseau pour bloquer tout le trafic Web, à l'exception du trafic interne requis.
- Dans le cas de (TOCTOU), pour empêcher le remappage DNS et les attaques "check time, use time", il est bon de faire attention à la précision des URL.

2.3 Référence

Top 10 des vulnérabilités de sécurité des applications Web_Ten Web Vulnerabilities_crazy_itman's Blog-CSDN Blog

Introduction au Top 10 OWASP 2022 - La fin du monde et votre blog - Blog CSDN

3. Un enregistrement d'un test d'intrusion WEB

J'ai récemment fait un test d'intrusion WEB. Faites un résumé des problèmes détectés ici.

1. Copiez une certaine URL d'un utilisateur autorisé, et après avoir constaté qu'un utilisateur non autorisé s'est connecté, modifiez l'URL du contenu que vous venez de copier et constatez qu'il est possible de se connecter. (contrôle d'accès cassé)

2. Connectez-vous avec le compte du client A, utilisez la fonction de journal de recherche, utilisez postman pour modifier l'ID de compte dans la requête HTTP vers le compte du client B et constatez que le journal de B peut être consulté. (contrôle d'accès cassé)

3. Peut falsifier arbitrairement la charge utile jwt, trouver que le message peut être décodé et encodé par BASE64, et obtenir le décodage des accolades où se trouve "alg", changer la valeur de "alg" dans le texte brut en "aucun ", et réencodez-le en "ey****" , remplacez la valeur de l'en-tête jwt (Autorisation) par "ey****", et la charge utile jwt peut être définie arbitrairement. (contrôle d'accès cassé)

4. Utilisez un ID de rôle pour appeler n'importe quelle API publique. Obtenez l'ID de rôle à partir de l'en-tête de réponse. Appelez à nouveau l'API avec le nouvel ID de rôle, en plaçant le nouvel ID de rôle dans l'en-tête de la demande. Les résultats vont changer. (contrôle d'accès cassé)

5. L'ID client d'entrée de l'API publique peut être injecté via l'en-tête "client - ID". Les en-têtes d'entrée ne sont pas validés avant utilisation. Il s'agit d'un problème important de fuite de données. Ce n'est que lorsque l'ID client est récupéré qu'un locataire peut appeler l'API publique pour récupérer les données d'un autre locataire. (contrôle d'accès cassé)

Préparez deux locataires : le locataire A et le locataire B.
Utilisez "cid": "cid of A" pour appeler l'API "https://....../audit/logs"
Ajoutez "***-customer-id": "cid of B" dans l'en-tête.
Obtention réussie des informations du journal d'audit de B.

6. Les en-têtes d'entrée ne sont pas validés avant utilisation. Il s'agit d'un problème de fuite de données important. Tant que l'ID client peut être récupéré, un locataire peut appeler l'API publique pour obtenir des données d'autres locataires. (contrôle d'accès cassé)

Utilisez le bon uic_token dans l'en-tête pour appeler l'API "http://......./notifications/counts"
Obtenir l'identifiant client à partir de la réponse
Mettez l'identifiant client obtenu à l'étape 2 dans l'en-tête pour appeler l'API

7. L'attaquant peut obtenir différentes autorisations de rôle en modifiant l'ID de rôle. (contrôle d'accès cassé)

1. Utilisez l'autorisation d'un ID de rôle pour appeler l'API.

2. Obtenez l'ID de rôle à partir de l'en-tête de réponse.

3. Utilisez le nouvel ID de rôle pour appeler à nouveau l'API (obtenu à l'étape 2) et placez le nouvel ID de rôle dans l'en-tête de la demande. Les autorisations vont changer.

8. Lors de l'exécution d'une requête sans spécifier le jeton d'interface utilisateur, la requête peut toujours être interrogée. (contrôle d'accès cassé)

Le jeton Uic est utilisé pour la vérification CSRF, si ce jeton n'est pas spécifié, il peut y avoir une attaque CSRF

9. La session n'a pas été correctement terminée. Après la déconnexion, la session est toujours valide et peut être utilisée pour effectuer des demandes d'API d'interface utilisateur. (l'identification et l'authentification ont échoué)

1. Déconnectez-vous d'abord de la session en cours.

2. Appelez l'API avec l'ancien cookie et le jeton d'interface utilisateur, la demande est toujours réussie.

10. En mode débogage, le mot de passe est affiché sur la console (l'identification et l'authentification ont échoué)

Le mot de passe est une information sensible, l'attaquant peut directement se connecter à la console après avoir obtenu ce mot de passe

1. Connectez-vous au portail avec le rôle "pas d'autorisation".

2. Ouvrez le lien https://....../#/admin/logs

3. Activez le mode débogage et sélectionnez console.

4. Entrez quelques mots-clés et "rechercher", il affichera le mot de passe dans la console Web.

11. Lors de l'appel de l'API d'authentification frontale sans cookie, la réponse indiquera que "x-account-id" est manquant. Si l'authentification n'est pas requise, l'ID de compte peut être défini via l'en-tête x-account-id. (l'identification et l'authentification ont échoué)

12. Appelez l'API du connecteur de produit frontal, il y a un champ de jeton dans la réponse qui n'est pas utilisé dans la page. Problème de fuite d'identifiants. (l'identification et l'authentification ont échoué)

13. Les journaux d'audit peuvent être supprimés (conception non sécurisée)

Les pirates peuvent supprimer les journaux d'audit (DELETE https://…) lorsqu'ils effectuent certaines opérations risquées.

14. Les attaquants peuvent envoyer fréquemment des e-mails de test, ce qui peut provoquer des DOS et des spams. (conception dangereuse)

Lancez le portail via "Camp Admin". Accédez à Comptes-> Notifications, sélectionnez un élément et cliquez sur "Envoyer un e-mail de test" fréquemment en 1 minute.

15. Injection de script intersite réfléchissant (XSS). (injection)

Il s'agit d'une injection de script intersite réflexive. XSS peut être utilisé pour voler des cookies dans un domaine vulnérable et potentiellement obtenir un accès non autorisé à la session d'authentification d'un utilisateur, modifier/détruire le contenu d'une page Web vulnérable ou compromettre le navigateur Web d'un utilisateur. Si un attaquant modifie le champ de fuseau horaire dans la requête, en insérant du JavaScript voleur de cookies, il est possible de prendre le contrôle s'il parvient à amener la victime à visiter son URL.

1. Dans les paramètres de la console, lors de l'enregistrement des paramètres. Il existe une valeur de champ dans la charge utile de la requête POST qui peut être utilisée pour injecter

16. Les composants des applications Web sont vulnérables aux attaques de script intersite (XSS). (injection)

Les composants des applications Web sont vulnérables aux attaques de script intersite (XSS). En exploitant ce problème, un attaquant peut fournir un code de site côté client arbitraire (JavaScript, VBScript, etc.) dans les paramètres d'entrée de l'application qui seront éventuellement rendus et exécutés dans le navigateur Web de l'utilisateur final.

La page info.html est vulnérable à l'injection de liens basée sur DOM, qui, lorsqu'on clique dessus, peut conduire à une attaque intersite. XSS peut être utilisé pour voler des cookies dans le domaine vulnérable et potentiellement obtenir un accès non autorisé à la session d'authentification de l'utilisateur après avoir compromis le contenu de la page Web vulnérable ou compromis le navigateur Web de l'utilisateur. Une tactique courante consiste à repeindre les pages vulnérables sur les domaines de confiance afin d'usurper le délai d'expiration de la session réelle et les pages de connexion pour obtenir les mots de passe des utilisateurs.

1. Connectez-vous au portail avec le rôle "Camp Admin". ,

2. Déconnectez-vous du portail

3. Entrez l'url https://********/info.html#/redirect?url=javascript:alert(0) pour injecter le script

17. Les détails de la réponse peuvent révéler des informations sur l'application, ce qui augmente les chances de découvrir des vulnérabilités existantes. (mauvaise configuration de la sécurité)

Les détails de la réponse peuvent révéler des informations sur l'application, ce qui augmente les chances de découvrir des vulnérabilités existantes.

Lors de l'appel de l'API avec un corps erroné, le résultat de la réponse contient les détails de l'application.

18. L'en-tête CSP n'est pas ajouté ou configuré en tant que valeur sûre, ce qui chargera les ressources vers des informations de site non approuvées, entraînant XSS et d'autres vulnérabilités associées. (mauvaise configuration de la sécurité)

La politique de sécurité du contenu (CSP) est une couche de sécurité supplémentaire qui permet de détecter et d'atténuer certains types d'attaques. Y compris (mais sans s'y limiter) les scripts intersites (XSS) et les attaques par injection de données. Ces attaques sont utilisées pour tout, du vol de données à la dégradation de sites Web ou à la distribution de logiciels malveillants. CSP fournit un ensemble standard d'en-têtes HTTP qui permettent aux propriétaires de sites Web de déclarer les sources de contenu que les navigateurs sont autorisés à charger sur cette page - les types couverts incluent JavaScript, CSS, les cadres HTML, les polices, les images et les objets intégrables.

19. En raison d'une mauvaise configuration de Cross Origin Resource Sharing (CORS) sur le serveur Web, le navigateur Web peut ne pas être en mesure de charger les données. Access-Control-Allow-Origin : *Non sécurisé pour les données sensibles. (mauvaise configuration de la sécurité)

Une mauvaise configuration CORS sur le serveur Web permet des demandes de lecture cross-origin provenant de domaines tiers arbitraires où des API non authentifiées sont utilisées. Cependant, les implémentations de navigateur Web ne permettent pas à des tiers arbitraires de lire les réponses des API authentifiées. Cela réduit le risque dans une certaine mesure. Cette mauvaise configuration pourrait être utilisée par des attaquants pour accéder à des données disponibles de manière non authentifiée, mais qui utilisent d'autres formes de sécurité, telles que la liste blanche d'adresses IP.

20. Ne pas utiliser la politique de sécurité HSTS (mauvaise configuration de la sécurité)

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité Web par lequel les agents utilisateurs (tels que les navigateurs Web) qu'un serveur Web déclare obéir interagissent uniquement avec lui à l'aide de connexions HTTPS sécurisées (c'est-à-dire que la couche HTTP est sur TLS/SSL). HSTS est un protocole de suivi des normes IETF, spécifié dans la RFC 6797.

L'absence de cet en-tête expose le serveur Web au risque d'être utilisable pour le trafic HTTP normal.

21. Tout le monde peut télécharger n'importe quel fichier sur le serveur, cela peut remplacer le fichier et affecter l'application, d'autres clients peuvent faire exécuter le fichier avec un virus. (mauvaise configuration de la sécurité)

1. Ouvrez le portail v1 avec le rôle "Administrateur".

2. Recherchez l'URL du fichier d'obtention à partir du portail.

3. Utilisez la méthode PUT pour envoyer n'importe quel fichier à l'url, par exemple test.js. Il peut obtenir ce fichier avec la méthode get.

22. Http peut être utilisé pour effectuer des appels API (erreur de configuration de sécurité)

Une API peut utiliser Postman pour envoyer des requêtes http

Il n'y a pas d'en-tête "Strict-Transport-Security" dans les en-têtes de réponse. L'en-tête "Strict-Transport-Security" limite le site à HTTPS uniquement, et toute tentative future d'y accéder via HTTP doit être automatiquement convertie en HTTPS.

4. Enfin

Les principaux types de sécurité Web changent légèrement d'une année à l'autre. La maîtrise des types de vulnérabilités WEB les plus courants est une base importante pour le développement des travaux de pénétration.

Vulnérabilités de sécurité WEB Ten (OWASP Top 10) et enregistrements de tests de pénétration