Add distribution files

odt and pdf files from rendered markdown and minor edits (typos/broken md etc)

Author: datakime

2019/fr/dist/owasp-api-security-top-10.odt

@@ -4,12 +4,12 @@ OWASP Top 10 Risques de sécurité des API – 2019
 | Risque | Description |
 | ------ | ----------- |
 | API1:2019 - Broken Object Level Authorization | Les API ont tendance à exposer des points d'accès (endpoints) qui gèrent les identifiants d'objets (OID), créant une large surface d'attaque des contrôles de niveaux d'accès. Des contrôles d'autorisation doivent être effectués pour toute fonction qui accède à une source de données à partir d'entrées fournies par un utilisateur. |
-| API2:2019 - Broken User Authentication | Les mécanismes d'authentification sont souvent implémentés incorrectement, permettant à des attaquants de compromettre des jetons (Token) d'authentification ou d'exploiter des failles d'implémentation afin d'endosser temporairement ou de manière permanente l'identité d'autres utilisateurs. L'incapacité, pour un système, à identifier le client / utilisateur de manière fiable compromet la sécurité de l'API dans son ensemble. |
+| API2:2019 - Broken User Authentication | Les mécanismes d'authentification sont souvent implémentés incorrectement, permettant à des attaquants de compromettre des jetons (tokens) d'authentification ou d'exploiter des failles d'implémentation afin d'endosser temporairement ou de manière permanente l'identité d'autres utilisateurs. L'incapacité, pour un système, à identifier le client / utilisateur de manière fiable compromet la sécurité de l'API dans son ensemble. |
 | API3:2019 - Excessive Data Exposure | En effectuant des implémentations génériques rapides, les développeurs ont tendance à exposer tous les attributs des objets sans prendre en considération leur confidentialité individuelle, se reposant sur les clients d'API pour effectuer un filtrage des données avant présentation à l'utilisateur. |
 | API4:2019 - Lack of Resources & Rate Limiting | Bien souvent, les API n'imposent pas de restrictions sur la taille ou le nombre de ressources qui peuvent être requises par le client / l'utilisateur. Ceci impacte non seulement la performance du serveur d'API, aboutissant à un Déni de Service (DoS), mais cela constitue aussi une porte ouverte pour des failles d'authentification par force brute. |
 | API5:2019 - Broken Function Level Authorization | Les politiques de contrôle d'accès complexes avec des hiérarchies, groupes et rôles différents, et la séparation non claire entre les fonctions normales et d'administration tendent à occasionner des failles d'authentification. En exploitant ces problèmes, les attaquants parviennent à accéder aux ressources d'autres utilisateurs et / ou aux fonctions d'administration. |
 | API6:2019 - Mass Assignment | La connexion de données fournies par le client (ex : JSON) aux modèles de données sans filtrage approprié par une liste de validation conduit généralement à l'assignation massive. En devinant les attributs des objets, en explorant les autres points d'accès de l'API, en lisant la documentation ou en incluant des attributs supplémentaires dans la charge utile (payload) des requêtes, les attaquants parviennent à modifier les attributs d'objets qu'ils ne devraient pas pouvoir modifier. |
 | API7:2019 - Security Misconfiguration | Une mauvaise configuration de sécurité est souvent le résultat de configurations par défauts non sécurisées, de configurations incomplètes ou ad-hoc, de stockages ouverts dans le cloud, d'en-têtes HTTP mal configurés, de méthodes HTTP non nécessaires, de partage de ressources intersites permissives (CORS), et de messages d'erreurs verbeux contenant des informations sensibles. |
 | API8:2019 - Injection | Les failles d'injection telles que SQL, NoSQL, injection de commandes, etc, se produisent lorsque des données non fiables sont transmises à un interpréteur comme partie d'une commande ou d'une requête. Les données malveillantes de l'attaquant peuvent tromper l'interpréteur et lui faire exécuter des commandes non prévues ou accéder à des données sans disposer des autorisations nécessaires. |
-| API9:2019 - Improper Assets Management | Les API ont tendance à exposer plus de points d'accès que les applications web traditionnelles, rendant très importante la nécessité d'une documentation appropriée et actualisée. Un inventaire précis des hôtes et des versions d'API déployées joue également un rôle important pour prévenir les problèmes tels que les versions obsolètes d'API et les points de déboggage vulnérables. |
+| API9:2019 - Improper Assets Management | Les API ont tendance à exposer plus de points d'accès que les applications web traditionnelles, rendant très importante la nécessité d'une documentation appropriée et actualisée. Un inventaire précis des hôtes et des versions d'API déployées joue également un rôle important pour prévenir les problèmes tels que les versions obsolètes d'API et l'exposition des points de déboggage. |
 | API10:2019 - Insufficient Logging & Monitoring | L'insuffisance de logging et de monitoring, couplée à une intégration insuffisante ou absente à la réponse aux incidents, permet aux attaquants de poursuivre leurs attaques sur les systèmes, de s'y maintenir de manière persistante, et de rebondir sur d'autres systèmes pour compromettre, extraire ou détruire des données. La plupart des études de failles montrent que le temps nécessaire pour détecter une intrusion est supérieur à 200 jours, typiquement découverte par des tiers externes plutôt que par des processus ou un monitoring interne. |

2019/fr/dist/owasp-api-security-top-10.pdf

@@ -45,8 +45,8 @@ Un attaquant commence le processus de récupération de mot de passe en émettan
   d'API non plus.
 * Ne réinventez pas la roue en matière d'authentification, de génération de tokens,
   de stockage de mots de passe. Utilisez les standards.
-* Les points d'accès de récupération / d'oubli de mot de passe doivent être traités 
-  comme des points d'accès de login en termes de force brute, limitation de requêtes 
+* Les points d'accès de récupération / d'oubli de mot de passe doivent être traités
+  comme des points d'accès de login en termes de force brute, limitation de requêtes
   et de protection par blocage.
 * Utilisez la [cheatsheet OWASP Authentication ][3].
 * Quand c'est possible, implémentez l'authentification multi-facteurs.
@@ -58,7 +58,7 @@ Un attaquant commence le processus de récupération de mot de passe en émettan
   l'emploi de force brute contre des utilisateurs spécifiques. Implementez des
   mesures pour une meilleure robustesse des mots de passe.
 * Les clés d'API ne doivent pas être utilisées pour authentifier un utilisateur,
-  mais pour d'autres [applications clientes / authentification de projet][5].
+  mais pour les [applications clientes / authentification de projets][5].
 
 ## Références
 

2019/fr/src/0x11-t10.md

@@ -4,7 +4,7 @@ API9:2019 Improper Assets Management
 | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact |
 | - | - | - |
 | Spécifique API : Exploitabilité **3** | Prévalence **3** : Détectabilité **2** | Technique **2** : Spécifique à l'organisation |
-| Les anciennes versions des API n'ont souvent pas bénéficié des correctifs de sécurité et sont un moyen facile pour compromettre des systèmes sans avoir à affronter des mécanismes de sécurité de pointe, qui peuvent avoir été mis en place pour protéger les versions les plus récentes de l'API. | Une documentation obsolète rend plus difficile la recherche et / ou la correction de vulnérabilités. L'absence d'inventaire des points actifs et de stratégies de retrait pour ceux ne devant plus être utilisés, conduit à faire tourner des systèmes dépourvus de correctifs de sécurité, entrainant la divulgation de données sensibles. Des hôtes d'API inutilement exposés sont fréquemment trouvés du fait des concepts modernes comme les micro-services, qui rendent les applications faciles à déployer et indépendantes (ex : Cloud, aussi appelé informatique en nuage, Kubernetes). | Les attaquants peuvent obtenir accès à des données sensibles, et même prendre le contrôle du serveur via d'anciennes versions non corrigées de l'API connectées à la même base de données. |
+| Les anciennes versions des API n'ont souvent pas bénéficié des correctifs de sécurité et sont un moyen facile pour compromettre des systèmes sans avoir à affronter des mécanismes de sécurité de pointe, qui peuvent avoir été mis en place pour protéger les versions les plus récentes de l'API. | Une documentation obsolète rend plus difficile la recherche et / ou la correction de vulnérabilités. L'absence d'inventaire des points actifs et de stratégies de retrait pour ceux ne devant plus être utilisés, conduit à faire tourner des systèmes dépourvus de correctifs de sécurité, entrainant la divulgation de données sensibles. Des hôtes d'API inutilement exposés sont fréquemment trouvés du fait des concepts modernes comme les micro-services, qui rendent les applications faciles à déployer et indépendantes (ex : cloud, aussi appelé informatique en nuage, Kubernetes). | Les attaquants peuvent obtenir accès à des données sensibles, et même prendre le contrôle du serveur via d'anciennes versions non corrigées de l'API connectées à la même base de données. |
 
 ## L'API est-elle vulnérable ?
 
@@ -21,7 +21,7 @@ L'API peut être vulnérable si :
   * Quel est le flux des données ?
 * Il n'y a pas de documentation, ou la documentation existante n'est pas mise
   à jour.
-* Il n'y a pas de plan pour le retrait / la désactivation (des points d'accès 
+* Il n'y a pas de plan pour le retrait / la désactivation (des points d'accès
   devenus obsolètes) par version d'API.
 * L'inventaire des hôtes est manquant ou obsolète.
 * L'inventaire des services intégrés, en propre ou par des tiers, est manquant
@@ -77,7 +77,7 @@ utilisant la force brute pour deviner le token à 6 chiffres.
   autres que ceux de production. Si vous ne pouvez l'évitez, ces points d'accès
   doivent bénéficier du même niveau de sécurité que ceux de production.
 * Lorsque de nouvelles versions d'API intègrent des améliorations de
-  sécurité, effectuez une analyse de risque pour décider les actions 
+  sécurité, effectuez une analyse de risque pour décider les actions
   d'atténuation requises pour l'ancienne version : par exemple, s'il est ou non
   possible de rétro-porter les améliorations sans rompre la compatibilité ou si
   vous devez retirer rapidement l'ancienne version et forcer tous les clients à

2019/fr/src/0xa2-broken-user-authentication.md

@@ -4,8 +4,7 @@ API10:2019 Insufficient Logging & Monitoring
 | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact |
 | - | - | - |
 | Spécifique API : Exploitabilité **2** | Prévalence **3** : Détectabilité **1** | Technique **2** : Spécifique à l'organisation |
-| Les attaquants exploitent l'absence de logging et de monitoring pour utiliser frauduleusement des systèmes sans se faire repérer. | En l'absence de logging et de monitoring, ou si le logging et le monitoring sont insuffisants, il est pratiquement
-il est pratiquement impossible de suivre des activités suspectes et d'y répondre rapidement. | Sans visibilité sur les activités malveillantes en cours, les attaquants disposent de beaucoup de temps et peuvent compromettre complètement les systèmes. |
+| Les attaquants exploitent l'absence de logging et de monitoring pour utiliser frauduleusement des systèmes sans se faire repérer. | En l'absence de logging et de monitoring, ou si le logging et le monitoring sont insuffisants, il est pratiquement impossible de suivre des activités suspectes et d'y répondre rapidement. | Sans visibilité sur les activités malveillantes en cours, les attaquants disposent de beaucoup de temps et peuvent compromettre complètement les systèmes. |
 
 ## L'API est-elle vulnérable ?
 
@@ -22,7 +21,7 @@ L'API is vulnérable si :
 
 ### Scénario #1
 
-Les clés d'accès d'une API d'administration ont fuitées sur un répertoire public.
+Les clés d'accès d'une API d'administration ont fuité sur un répertoire public.
 Le propriétaire du répertoire a été notifié par e-mail à propos de cette fuite
 potentielle, mais a mis plus de 48 heures à réagir à l'incident, et
 l'exposition des clés d'accès peut avoir permis l'accès à des données

2019/fr/src/0xa9-improper-assets-management.md

@@ -12,7 +12,7 @@ L'OWASP propose de nombreuses ressources gratuites et libres pour aborder la sé
 | **Éducation** | Vous pouvez commencer par lire les [projets de la catégorie OWASP Education][2] en fonction de votre profession de votre intérêt. Pour une approche plus pratique, nous avons ajouté le projet **crAPI** - **C**ompletely **R**idiculous **API** à  [notre roadmap][3]. En attendant, vous pouvez vous entrainer à la sécurité des applis web avec le [module OWASP DevSlop Pixi][4], une WebApp et un service d'API volontairement vulnérables destinés à apprendre aux utilisateurs comment tester la sécurité des applications web modernes et des services d'API, et comment développer des API plus sécurisées à l'avenir. Vous pouvez également participer à des sessions de formation de [conférence OWASP AppSec][5], ou [rejoindre une section OWASP locale][6]. |
 | **Besoins de Sécurité** | La sécurité doit faire partie de chaque projet dès le début. Lors de la formulation des besoins, il est important de définir ce que "sécurisé" signifie pour ce projet. L'OWASP vous recommande d'utiliser le [OWASP Application Security Verification Standard (ASVS)][7] comme guide pour définir vos besoins de sécurité. Si vous sous-traitez, envisagez le projet [OWASP Secure Software Contract Annex][8], qui devra être adapté aux lois et réglementations locales. |
 | **Architecture de Sécurité** | La sécurité doit rester une préoccupation durant toutes les étapes du projet. Les [OWASP Prevention Cheat Sheets][9] sont un bon point de départ pour guider la conception de la sécurité durant la phase d'architecture. Parmi beaucoup d'autres, vous trouverez la [REST Security Cheat Sheet][10] et la [REST Assessment Cheat Sheet][11]. |
-| **Contrôles de Sécurité Standards** | L'adoption de contrôles de sécurité standards réduit le risque d'introduire des vulnérabilités de sécurité lorsque vous implémentez votre logique métier. Bien que de nombreux frameworks modernes incluent désormais des contrôles standards efficaces,[OWASP Proactive Controls][12] vous fournit un bon résumé des contrôles de sécurité que vous devriez inclure dans votre projet. L'OWASP fournit aussi quelques bibliothèques et outils que vous pourrez trouver utiles, tels que des contrôles de validation. |
+| **Contrôles de Sécurité Standards** | L'adoption de contrôles de sécurité standards réduit le risque d'introduire des vulnérabilités de sécurité lorsque vous implémentez votre logique métier. Bien que de nombreux frameworks modernes incluent désormais des contrôles standards efficaces, [OWASP Proactive Controls][12] vous fournit un bon résumé des contrôles de sécurité que vous devriez inclure dans votre projet. L'OWASP fournit aussi quelques bibliothèques et outils que vous pourrez trouver utiles, tels que des contrôles de validation. |
 | **Cycle de Développement Logiciel Sécurisé** | Vous pouvez utiliser le [OWASP Software Assurance Maturity Model (SAMM)][13] pour améliorer le processus de développement d'API. Plusieurs autres projets OWASP sont disponibles pour vous aider durant les différentes phases de développement d'API, par ex. le [OWASP Code Review Project][14]. |
 
 [1]: https://www.owasp.org/index.php/Category:OWASP_Project

2019/fr/src/0xaa-insufficient-logging-monitoring.md

@@ -19,7 +19,6 @@ En cas de doute, tenez-vous informé et consultez souvent le [DevSecOps Manifest
 | **Compréhension du modèle de menaces** | Les priorités de tests sont déterminées par le modèle de menaces. Si vous n'en avez pas, envisagez d'utiliser notre [OWASP Application Security Verification Standard (ASVS)][2], et notre [OWASP Testing Guide][3] comme bases. Impliquer l'équipe de développement peut contribuer à les rendre plus conscients de la sécurité. |
 | **Comprendre le SDLC** | Joignez-vous à l'équipe de développement pour mieux comprendre le cycle de développement logiciel (SDLC - Software Development Life Cycle). Votre contribution aux tests de sécurité continus doit être compatible avec les personnes, les procédés et les outils. Tout le monde doit adhérer à la démarche, afin d'éviter des frictions ou de la résistance inutiles. |
 | **Stratégies de tests** | Comme votre travail ne doit pas impacter la vitesse de développement, vous devez choisir judicieusement la meilleure technique (simple, la plus rapide, la plus juste) pour vérifier les exigences de sécurité. Les projets [OWASP Security Knowledge Framework][4] et [OWASP Application Security Verification Standard][5] peuvent constituer d'excellentes sources d'exigences de sécurité fonctionnelles et non-fonctionnelles. Il existe également d'autres ressources et contenus de qualité tels les [projets][6] et [outils][7] proposés par la [communauté DevSecOps][8]. |
- Parmi les autres sources remarquent figurent les [projets][6] et [outils][7] proposés par la [communauté DevSecOps][8]. |
 | **Obtention de couverture et précision** | Vous êtes le lien entre les développeurs (Dev) et les équipes opérationnelles (Ops). Pour réaliser la couverture, vous devez vous concentrer non seulement sur la fonctionnalité, mais aussi sur l'orchestration. Travaillez en étroite relation à la fois avec les équipes de développement et des opérations (infra) dès le début pour pouvoir optimiser votre temps et vos efforts. Vous devez viser un état où la sécurité essentielle est vérifiée continuellement. |
 | **Communication claire des résultats** | Apportez de la valeur avec pas ou peu de friction. Alertez promptement sur vos découvertes, en utilisant les moyens et outils mis en oeuvres par vos équipes (pas dans des fichiers PDF). Joignez-vous à l'équipe de développement pour résoudre ces problèmes. Profitez de l'occasion pour les instruire, en décrivant clairement la vulnérabilité et la manière dont elle peut être exploitée, avec un scénario d'attaque pour la rendre réelle. |