diff --git a/2025/docs/fr/0x00_2025-Introduction.md b/2025/docs/fr/0x00_2025-Introduction.md index d614a1dbb..6e4e01778 100644 --- a/2025/docs/fr/0x00_2025-Introduction.md +++ b/2025/docs/fr/0x00_2025-Introduction.md @@ -1,87 +1,81 @@ -![OWASP Logo](../assets/TOP_10_logo_Final_Logo_Colour.png) +![Logo OWASP](../assets/TOP_10_logo_Final_Logo_Colour.png) -# Les dix risques les plus critiques pour la sécurité des applications Web +# Les dix risques les plus critiques pour la sécurité des applications web # Introduction -Bienvenue pour cette 8ème édition du Top 10 de l'OWASP ! +Bienvenue dans la 8e édition du Top 10 de l'OWASP ! -Un grand merci à tous ceux qui ont contribué à cette enquête en fournissant des données et des points de vue. Sans vous, ce volet n'aurait pas pu voir le jour. **MERCI !** +Un immense merci à toutes les personnes qui ont partagé leurs données et leurs points de vue dans le cadre de cette enquête. Sans vous, cette édition n'aurait pas été possible. **MERCI !** -## Présentation du Top 10 OWASP : 2025 +## Présentation du Top 10 de l'OWASP : 2025 * [A01:2025 - Contrôles d'accès défaillants](A01_2025-Broken_Access_Control.md) * [A02:2025 - Mauvaise configuration de sécurité](A02_2025-Security_Misconfiguration.md) -* [A03:2025 - Défaillances de la nomenclature logicielle](A03_2025-Software_Supply_Chain_Failures.md) +* [A03:2025 - Défaillances de la chaîne d'approvisionnement logicielle](A03_2025-Software_Supply_Chain_Failures.md) * [A04:2025 - Défaillances cryptographiques](A04_2025-Cryptographic_Failures.md) * [A05:2025 - Injection](A05_2025-Injection.md) * [A06:2025 - Conception non sécurisée](A06_2025-Insecure_Design.md) * [A07:2025 - Défaillances de l'authentification](A07_2025-Authentication_Failures.md) -* [A08:2025 - Manque d'intégrité des données ou du logiciel](A08_2025-Software_or_Data_Integrity_Failures.md) -* [A09:2025 - Carence des systèmes de contrôle et d'alerte](A09_2025-Security_Logging_and_Alerting_Failures.md) -* [A10:2025 - Mauvaise gestion des exceptions](A10_2025-Mishandling_of_Exceptional_Conditions.md) - +* [A08:2025 - Défaillances d'intégrité du logiciel ou des données](A08_2025-Software_or_Data_Integrity_Failures.md) +* [A09:2025 - Défaillances de la journalisation et des alertes de sécurité](A09_2025-Security_Logging_and_Alerting_Failures.md) +* [A10:2025 - Mauvaise gestion des conditions exceptionnelles](A10_2025-Mishandling_of_Exceptional_Conditions.md) ## Ce qui a changé dans le Top 10 en 2025 -Il y a deux nouvelles catégories et une consolidation dans le Top 10 pour 2025. Nous nous sommes efforcés de rester, autant que possible, concentrés sur les causes racines plutôt que sur les symptômes. Compte tenu de la complexité du génie logiciel et de la sécurité logicielle, il est pratiquement impossible de créer dix catégories sans un certain degré de chevauchement. - -![Mapping](../assets/2025-mappings.png) - -* **[A01:2025 - Broken Access Control](A01_2025-Broken_Access_Control.md)** maintains its position at #1 as the most serious application security risk; the contributed data indicates that on average, 3.73% of applications tested had one or more of the 40 Common Weakness Enumerations (CWEs) in this category. As indicated by the dashed line in the above figure, Server-Side Request Forgery (SSRF) has been rolled into this category. -* **[A02:2025 - Security Misconfiguration](A02_2025-Security_Misconfiguration.md)** moved up from #5 in 2021 to #2 in 2025. Misconfigurations are more prevalent in the data for this cycle. 3.00% of the applications tested had one or more of the 16 CWEs in this category. This is not surprising, as software engineering is continuing to increase the amount of an application’s behavior that is based on configurations. -* **[A03:2025 - Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md)** is an expansion of [A06:2021-Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) to include a broader scope of compromises occurring within or across the entire ecosystem of software dependencies, build systems, and distribution infrastructure. This category was overwhelmingly voted a top concern in the community survey. This category has 5 CWEs and a limited presence in the collected data, but we believe this is due to challenges in testing and hope that testing catches up in this area. This category has the fewest occurrences in the data, but also the highest average exploit and impact scores from CVEs. -* **[A04:2025 - Cryptographic Failures](A04_2025-Cryptographic_Failures.md)** falls two spots from #2 to #4 in the ranking. The contributed data indicates that, on average, 3.80% of applications have one or more of the 32 CWEs in this category. This category often leads to sensitive data exposure or system compromise. -* **[A05:2025 - Injection](A05_2025-Injection.md)** falls two spots from #3 to #5 in the ranking, maintaining its position relative to Cryptographic Failures and Insecure Design. Injection is one of the most tested categories, with the greatest number of CVEs associated with the 38 CWEs in this category. Injection includes a range of issues from Cross-site Scripting (high frequency/low impact) to SQL Injection (low frequency/high impact) vulnerabilities. -* **[A06:2025 - Insecure Design](A06_2025-Insecure_Design.md)** slides two spots from #4 to #6 in the ranking as Security Misconfiguration and Software Supply Chain Failures leapfrog it. This category was introduced in 2021, and we have seen noticeable improvements in the industry related to threat modeling and a greater emphasis on secure design. -* **[A07:2025 - Authentication Failures](A07_2025-Authentication_Failures.md)** maintains its position at #7 with a slight name change (prevously it was “[Identification and Authentication Failures](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)") to more accurately reflect the 36 CWEs in this category. This category remains important, but the increased use of standardized frameworks for authentication appears to be having beneficial effects on the occurrences of authentication failures. -* **[A08:2025 - Software or Data Integrity Failures](A08_2025-Software_or_Data_Integrity_Failures.md)** continues at #8 in the list. This category is focused on the failure to maintain trust boundaries and verify the integrity of software, code, and data artifacts at a lower level than Software Supply Chain Failures. -* **[A09:2025 - Security Logging & Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md)** retains its position at #9. This category has a slight name change (previously [Security Logging and Monitoring Failures](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/)”) to emphasize the importance of the alerting functionality needed to induce appropriate action on relevant logging events. Great logging with no alerting is of minimal value in identifying security incidents. This category will always be underrepresented in the data, and was again voted into a position in the list from the community survey participants. -* **[A10:2025 - Mishandling of Exceptional Conditions](A10_2025-Mishandling_of_Exceptional_Conditions.md)** is a new category for 2025. This category contains 24 CWEs focusing on improper error handling, logical errors, failing open, and other related scenarios stemming from abnormal conditions that systems may encounter. - - -## Methodology - -This installment of the Top Ten remains data-informed, but not blindly data-driven. We ranked 12 categories based on the data contributed, and allowed two to be promoted or highlighted by responses from the community survey. We do this for a fundamental reason: examining the contributed data is essentially looking into the past. Application Security researchers dedicate time to identifying new vulnerabilities and developing new testing methods. It takes weeks to years to integrate these tests into tools and processes. By the time we can reliably test a weakness at scale, years may have passed. There are also important risks that we may never be able to reliably test and be present in the data. To balance that view, we use a community survey to ask application security and development practitioners on the front lines what they see as essential risks that may be underrepresented in the testing data. +Le Top 10 2025 comporte deux nouvelles catégories et une consolidation. Nous nous sommes efforcés de rester autant que possible centrés sur les causes racines plutôt que sur les symptômes. Compte tenu de la complexité du génie logiciel et de la sécurité logicielle, il est pratiquement impossible de créer dix catégories sans un certain degré de chevauchement. +![Mise en correspondance](../assets/2025-mappings.png) -## How the categories are structured +* **[A01:2025 - Contrôles d'accès défaillants](A01_2025-Broken_Access_Control.md)** conserve sa première place en tant que risque de sécurité des applications le plus grave ; selon les données communiquées, au moins une des 40 CWE de cette catégorie était présente dans 3,73 % des applications testées en moyenne. Comme l'indique la ligne en pointillés de la figure ci-dessus, la falsification de requête côté serveur (SSRF) a été intégrée à cette catégorie. +* **[A02:2025 - Mauvaise configuration de sécurité](A02_2025-Security_Misconfiguration.md)** passe de la 5e place en 2021 à la 2e place en 2025. Les mauvaises configurations sont plus fréquentes dans les données de cette édition. 3,00 % des applications testées présentaient au moins une des 16 CWE de cette catégorie. Ce n'est pas surprenant, car le génie logiciel continue d'accroître la part du comportement d'une application fondée sur des configurations. +* **[A03:2025 - Défaillances de la chaîne d'approvisionnement logicielle](A03_2025-Software_Supply_Chain_Failures.md)** élargit [A06:2021 - Composants vulnérables et obsolètes](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) afin de couvrir un périmètre plus large de compromissions au sein de l'écosystème complet des dépendances logicielles, des systèmes de compilation et de l'infrastructure de distribution, ou entre ces éléments. Cette catégorie a été très largement désignée comme une préoccupation majeure par l'enquête communautaire. Elle comporte 5 CWE et est peu présente dans les données collectées, mais nous pensons que cela s'explique par les difficultés de test et espérons que les tests progresseront dans ce domaine. Elle présente le moins d'occurrences dans les données, mais aussi les scores moyens d'exploitabilité et d'impact issus des CVE les plus élevés. +* **[A04:2025 - Défaillances cryptographiques](A04_2025-Cryptographic_Failures.md)** recule de deux places, de la 2e à la 4e place. Les données communiquées indiquent que 3,80 % des applications présentent en moyenne au moins une des 32 CWE de cette catégorie. Cette catégorie entraîne souvent l'exposition de données sensibles ou la compromission du système. +* **[A05:2025 - Injection](A05_2025-Injection.md)** recule de deux places, de la 3e à la 5e place, tout en conservant sa position relative aux défaillances cryptographiques et à la conception non sécurisée. L'injection est l'une des catégories les plus testées et comporte le plus grand nombre de CVE associés à ses 38 CWE. Elle couvre un éventail de problèmes allant des scripts intersites (fréquence élevée et impact faible) aux vulnérabilités d'injection SQL (fréquence faible et impact élevé). +* **[A06:2025 - Conception non sécurisée](A06_2025-Insecure_Design.md)** recule de deux places, de la 4e à la 6e place, tandis que la mauvaise configuration de sécurité et les défaillances de la chaîne d'approvisionnement logicielle la dépassent. Cette catégorie a été introduite en 2021 et nous avons constaté des améliorations notables du secteur dans le domaine de la modélisation des menaces, ainsi qu'un intérêt accru pour la conception sécurisée. +* **[A07:2025 - Défaillances de l'authentification](A07_2025-Authentication_Failures.md)** conserve sa 7e place avec un léger changement de nom (il s'agissait auparavant de « [Défaillances de l'identification et de l'authentification](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/) ») afin de mieux refléter les 36 CWE de cette catégorie. Cette catégorie reste importante, mais l'utilisation accrue de frameworks standardisés pour l'authentification semble avoir un effet bénéfique sur le nombre de défaillances d'authentification. +* **[A08:2025 - Défaillances d'intégrité du logiciel ou des données](A08_2025-Software_or_Data_Integrity_Failures.md)** reste à la 8e place. Cette catégorie porte sur l'incapacité à maintenir les frontières de confiance et à vérifier l'intégrité des logiciels, du code et des artefacts de données, à un niveau plus bas que celui des défaillances de la chaîne d'approvisionnement logicielle. +* **[A09:2025 - Défaillances de la journalisation et des alertes de sécurité](A09_2025-Security_Logging_and_Alerting_Failures.md)** reste à la 9e place. Cette catégorie change légèrement de nom (il s'agissait auparavant de [Défaillances de la journalisation et de la surveillance de sécurité](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/)) pour mettre l'accent sur l'importance de la fonction d'alerte nécessaire au déclenchement d'une action appropriée sur les événements de journalisation pertinents. Une journalisation parfaite sans alertes a une valeur minimale pour identifier les incidents de sécurité. Cette catégorie sera toujours sous-représentée dans les données et a de nouveau été élue par les participants à l'enquête communautaire pour figurer dans la liste. +* **[A10:2025 - Mauvaise gestion des conditions exceptionnelles](A10_2025-Mishandling_of_Exceptional_Conditions.md)** est une nouvelle catégorie pour 2025. Elle contient 24 CWE et porte sur la gestion incorrecte des erreurs, les erreurs logiques, les échecs par ouverture et d'autres situations liées aux conditions anormales que les systèmes peuvent rencontrer. -A few categories have changed from the previous installment of the OWASP Top Ten. Here is a high-level summary of the category changes. +## Méthodologie -In this iteration, we asked for data, with no restriction on CWEs like we did for the 2021 edition. We asked for the number of applications tested for a given year (starting in 2021), and the number of applications with at least one instance of a CWE found in testing. This format allows us to track how prevalent each CWE is within the population of applications. We ignore frequency for our purposes; while it may be necessary for other situations, it only hides the actual prevalence in the application population. Whether an application has four instances of a CWE or 4,000 instances is not part of the calculation for the Top Ten. Especially as manual testers tend to only list a vulnerability once no matter how many times it is repeated in an application, while automated testing frameworks list every instance of a vulnerability as unique. We went from approximately 30 CWEs in 2017, to almost 400 CWEs in 2021, to 589 CWEs in this edition to analyze in the dataset. We plan to do additional data analysis as a supplement in the future. This significant increase in the number of CWEs necessitates changes to how the categories are structured. +Cette édition du Top 10 reste fondée sur les données, sans être guidée aveuglément par celles-ci. Nous avons classé 12 catégories à partir des données communiquées et autorisé la promotion ou la mise en avant de deux catégories à partir des réponses de l'enquête communautaire. Nous le faisons pour une raison fondamentale : l'examen des données communiquées revient essentiellement à regarder le passé. Les chercheurs en sécurité des applications consacrent du temps à identifier de nouvelles vulnérabilités et à élaborer de nouvelles méthodes de test. L'intégration de ces tests dans les outils et les processus prend des semaines, voire des années. Lorsque nous pouvons tester une faiblesse de manière fiable à grande échelle, plusieurs années peuvent s'être écoulées. Il existe également des risques importants que nous ne pourrons peut-être jamais tester de manière fiable et qui ne seront donc pas présents dans les données. Pour équilibrer cette vision, nous utilisons une enquête communautaire afin de demander aux professionnels de la sécurité et du développement des applications qui sont en première ligne quels risques essentiels pourraient être sous-représentés dans les données de test. -We spent several months grouping and categorizing CWEs and could have continued for additional months. We had to stop at some point. There are both root cause and symptom types of CWEs, where root cause types are like "Cryptographic Failure" and "Misconfiguration" contrasted to symptom types like "Sensitive Data Exposure" and "Denial of Service." We decided to focus on the root cause whenever possible as it's more logical for providing identification and remediation guidance. Focusing on the root cause over the symptom isn't a new concept; the Top Ten has been a mix of symptom and root cause. CWEs are also a mix of symptom and root cause; we are simply being more deliberate about calling it out. There is an average of 25 CWEs per category in this installment, with the lower bounds at 5 CWEs for A03:2025-Software Supply Chain Failures and A09:2025 Security Logging and Alerting Failures to 40 CWEs in A01:2025-Broken Access Control. We made the decision to cap the number of CWEs in a category to 40. This updated category structure offers additional training benefits as companies can focus on CWEs that make sense for a language/framework. +## Structure des catégories -We have been asked why not shift to a list of 10 CWEs as a Top 10, similar to the MITRE Top 25 Most Dangerous Software Weaknesses. There are two primary reasons why we use multiple CWEs in categories. First, not all CWEs exist in all programming languages or frameworks. This causes issues for tooling and training/awareness programs as part of the Top Ten may not be applicable. The second reason is that there are multiple CWEs for common vulnerabilities. For example, there are multiple CWEs for general Injection, Command Injection, Cross-site Scripting, Hardcoded Passwords, Lack of Validation, Buffer Overflows, Cleartext Storage of Sensitive Information, and many others. Depending on the organization or tester, different CWEs might be used. By using a category with multiple CWEs we can help raise the baseline and awareness of the different types of weaknesses that may occur under a common category name. In this edition of the Top Ten 2025, there are 248 CWEs within the 10 categories. There are a total of 968 CWEs in the [downloadable dictionary from MITRE](https://cwe.mitre.org) at the time of this release. +Quelques catégories ont changé depuis l'édition précédente du Top 10 de l'OWASP. Voici une synthèse générale de ces changements. +Pour cette édition, nous avons demandé des données sans imposer de restriction sur les CWE, contrairement à l'édition 2021. Nous avons demandé le nombre d'applications testées pour une année donnée (à partir de 2021) et le nombre d'applications présentant au moins une occurrence d'une CWE trouvée lors des tests. Ce format nous permet de suivre la prévalence de chaque CWE dans la population d'applications. Nous ignorons la fréquence pour nos besoins : bien qu'elle puisse être nécessaire dans d'autres situations, elle ne fait que masquer la prévalence réelle dans la population d'applications. Qu'une application présente quatre occurrences d'une CWE ou 4 000 ne fait pas partie du calcul du Top 10. Les testeurs manuels ont notamment tendance à ne répertorier une vulnérabilité qu'une seule fois, quel que soit le nombre de ses répétitions dans une application, tandis que les frameworks de test automatisés répertorient chaque occurrence comme unique. Nous sommes passés d'environ 30 CWE en 2017 à près de 400 en 2021, puis à 589 CWE à analyser dans le jeu de données de cette édition. Nous prévoyons de réaliser ultérieurement des analyses de données supplémentaires en complément. Cette augmentation importante du nombre de CWE impose de modifier la structure des catégories. -## How the data is used for selecting categories +Nous avons consacré plusieurs mois au regroupement et à la catégorisation des CWE et aurions pu continuer pendant plusieurs mois encore. Il a bien fallu nous arrêter. Il existe des CWE correspondant à des causes racines et d'autres correspondant à des symptômes : les premières comprennent par exemple « défaillance cryptographique » et « mauvaise configuration », tandis que les secondes comprennent « exposition de données sensibles » et « déni de service ». Nous avons décidé de nous concentrer autant que possible sur les causes racines, car cela est plus logique pour fournir des recommandations d'identification et de remédiation. Se concentrer sur la cause racine plutôt que sur le symptôme n'est pas un concept nouveau : le Top 10 mélange depuis toujours symptômes et causes racines. Les CWE mélangent également symptômes et causes racines ; nous sommes simplement plus explicites sur ce point. Cette édition compte en moyenne 25 CWE par catégorie, avec un minimum de 5 CWE pour A03:2025 - Défaillances de la chaîne d'approvisionnement logicielle et A09:2025 - Défaillances de la journalisation et des alertes de sécurité, et un maximum de 40 CWE pour A01:2025 - Contrôles d'accès défaillants. Nous avons décidé de plafonner à 40 le nombre de CWE par catégorie. Cette structure actualisée offre des avantages supplémentaires pour la formation, car les entreprises peuvent se concentrer sur les CWE pertinentes pour un langage ou un framework. -Similar to what we did for the 2021 edition, we leveraged CVE data for *Exploitability *and *(Technical) Impact*. We downloaded OWASP Dependency Check and extracted the CVSS Exploit and Impact scores, grouping them by relevant CWEs listed with the CVEs. It took a fair bit of research and effort, as all the CVEs have CVSSv2 scores, but there are flaws in CVSSv2 that CVSSv3 should address. After a certain point in time, all CVEs are assigned a CVSSv3 score as well. Additionally, the scoring ranges and formulas were updated between CVSSv2 and CVSSv3. +On nous a demandé pourquoi ne pas passer à une liste de 10 CWE comme Top 10, à l'image du Top 25 des faiblesses logicielles les plus dangereuses de MITRE. Deux raisons principales expliquent pourquoi nous utilisons plusieurs CWE dans les catégories. Premièrement, toutes les CWE n'existent pas dans tous les langages de programmation ou frameworks. Cela crée des problèmes pour les outils et les programmes de formation et de sensibilisation, car une partie du Top 10 peut ne pas être applicable. Deuxièmement, plusieurs CWE peuvent correspondre à une même vulnérabilité courante. Il existe par exemple plusieurs CWE pour l'injection générale, l'injection de commandes, les scripts intersites, les mots de passe codés en dur, l'absence de validation, les dépassements de tampon, le stockage en clair d'informations sensibles et bien d'autres. Selon l'organisation ou le testeur, des CWE différentes peuvent être utilisées. En utilisant une catégorie regroupant plusieurs CWE, nous pouvons élever le niveau de référence et sensibiliser aux différents types de faiblesses susceptibles de relever d'un même nom de catégorie. Dans cette édition du Top 10 2025, les 10 catégories regroupent 248 CWE. Le dictionnaire [téléchargeable auprès de MITRE](https://cwe.mitre.org) contient au total 968 CWE à la date de cette publication. -In CVSSv2, both Exploit and (Technical) Impact could be up to 10.0, but the formula would knock them down to 60% for Exploit and 40% for Impact. In CVSSv3, the theoretical max was limited to 6.0 for Exploit and 4.0 for Impact. With the weighting considered, the Impact scoring shifted higher, almost a point and a half on average in CVSSv3, and exploitability moved nearly half a point lower on average. +## Utilisation des données pour sélectionner les catégories -There are approximately 175k records (up from 125k in 2021) of CVEs mapped to CWEs in the National Vulnerability Database (NVD), extracted from OWASP Dependency Check. Additionally, there are 643 unique CWEs mapped to CVEs (up from 241 in 2021). Within the nearly 220k CVEs that were extracted, 160k had CVSS v2 scores, 156k had CVSS v3 scores, and 6k had CVSS v4 scores. Many CVEs have multiple scores, which is why they total more than 220k. +Comme pour l'édition 2021, nous avons utilisé les données CVE pour l'*exploitabilité* et l'*impact technique*. Nous avons téléchargé OWASP Dependency-Check et extrait les scores CVSS d'exploitabilité et d'impact, en les regroupant par CWE pertinentes répertoriées dans les CVE. Cela a nécessité beaucoup de recherches et d'efforts : tous les CVE disposent de scores CVSSv2, mais cette version comporte des défauts que CVSSv3 est censée corriger. Après une certaine date, tous les CVE se voient également attribuer un score CVSSv3. En outre, les plages de scores et les formules ont été mises à jour entre CVSSv2 et CVSSv3. -For the Top Ten 2025, we calculated average exploit and impact scores in the following manner. We grouped all the CVEs with CVSS scores by CWE and weighted both exploit and impact scores by the percentage of the population that had CVSSv3, as well as the remaining population with CVSSv2 scores, to get an overall average. We mapped these averages to the CWEs in the dataset to use as Exploit and (Technical) Impact scoring for the other half of the risk equation. +Dans CVSSv2, l'exploitabilité et l'impact (technique) pouvaient tous deux atteindre 10,0, mais la formule les ramenait à 60 % pour l'exploitabilité et à 40 % pour l'impact. Dans CVSSv3, le maximum théorique était limité à 6,0 pour l'exploitabilité et à 4,0 pour l'impact. Une fois la pondération prise en compte, le score d'impact a augmenté en moyenne de près d'un point et demi dans CVSSv3, tandis que l'exploitabilité a diminué en moyenne de près d'un demi-point. -Why not use CVSS v4.0, you may ask? That’s because the scoring algorithm was fundamentally changed, and it no longer easily provides the *Exploit* or *Impact* scores as CVSS v2 and CVSSv3 do. We will attempt to figure out a way to use CVSS v4.0 scoring for future versions of the Top Ten, but we were unable to determine a timely way to do so for the 2025 edition. +Il existe environ 175 000 enregistrements de CVE associés à des CWE dans la National Vulnerability Database (NVD), extraits d'OWASP Dependency-Check, contre 125 000 en 2021. De plus, 643 CWE uniques sont associées à des CVE, contre 241 en 2021. Parmi les quelque 220 000 CVE extraits, 160 000 possédaient des scores CVSS v2, 156 000 des scores CVSS v3 et 6 000 des scores CVSS v4. De nombreux CVE possèdent plusieurs scores, ce qui explique que leur total dépasse 220 000. +Pour le Top 10 2025, nous avons calculé les scores moyens d'exploitabilité et d'impact de la manière suivante. Nous avons regroupé par CWE tous les CVE disposant de scores CVSS et pondéré les scores d'exploitabilité et d'impact selon le pourcentage de la population disposant de CVSSv3, ainsi que selon la population restante disposant de scores CVSSv2, afin d'obtenir une moyenne globale. Nous avons associé ces moyennes aux CWE du jeu de données pour les utiliser comme scores d'exploitabilité et d'impact (technique) dans l'autre moitié de l'équation du risque. -## Why we use a community survey +Pourquoi ne pas utiliser CVSS v4.0, pourriez-vous demander ? Parce que l'algorithme de notation a été fondamentalement modifié et ne fournit plus aussi facilement les scores d'*exploitabilité* ou d'*impact* que CVSSv2 et CVSSv3. Nous tenterons de trouver un moyen d'utiliser la notation CVSS v4.0 dans les prochaines versions du Top 10, mais nous n'avons pas pu déterminer une méthode à temps pour l'édition 2025. -The results in the data are largely limited to what the industry can test for in an automated fashion. Talk to a seasoned AppSec professional, and they will tell you about stuff they find and trends they see that aren't yet in the data. It takes time for people to develop testing methodologies for certain vulnerability types and then more time for those tests to be automated and run against a large population of applications. Everything we find is looking back in the past and might be missing trends from the last year, which are not present in the data. +## Pourquoi utiliser une enquête communautaire -Therefore, we only pick eight of the ten categories from the data because it's incomplete. The other two categories are from the Top 10 community survey. It allows the practitioners on the front lines to vote for what they see as the highest risks that might not be in the data (and may never be expressed in data). +Les résultats des données sont largement limités à ce que le secteur peut tester automatiquement. Parlez à un professionnel expérimenté de l'AppSec : il vous parlera des éléments qu'il découvre et des tendances qu'il observe, mais qui ne figurent pas encore dans les données. Il faut du temps pour élaborer des méthodes de test pour certains types de vulnérabilités, puis encore du temps pour automatiser ces tests et les exécuter sur une grande population d'applications. Tout ce que nous découvrons regarde le passé et peut manquer les tendances de la dernière année, qui ne sont pas présentes dans les données. +Nous ne retenons donc dans les données que huit des dix catégories, car celles-ci sont incomplètes. Les deux autres catégories proviennent de l'enquête communautaire du Top 10. Celle-ci permet aux professionnels en première ligne de voter pour les risques qu'ils considèrent comme les plus élevés et qui pourraient ne pas apparaître dans les données (et ne jamais y être exprimés). -## Thank you to our data contributors +## Remerciements à nos contributeurs de données -The following organizations (along with several anonymous donors) kindly donated data for over 2.8 millions applications to make this the largest and most comprehensive application security data set. Without you, this would not be possible. +Les organisations suivantes (ainsi que plusieurs donateurs anonymes) ont généreusement fourni des données portant sur plus de 2,8 millions d'applications, permettant de constituer le jeu de données de sécurité des applications le plus vaste et le plus complet à ce jour. Sans vous, cela n'aurait pas été possible. * Accenture (Prague) -* Anonymous (multiple) +* Anonymous (plusieurs) * Bugcrowd * Contrast Security * CryptoNet Labs @@ -94,19 +88,19 @@ The following organizations (along with several anonymous donors) kindly donated * Veracode * Wallarm -## Lead Authors -* Andrew van der Stock - X: [@vanderaj](https://x.com/vanderaj) -* Brian Glas - X: [@infosecdad](https://x.com/infosecdad) -* Neil Smithline - X: [@appsecneil](https://x.com/appsecneil) -* Tanya Janca - X: [@shehackspurple](https://x.com/shehackspurple) -* Torsten Gigler - Mastodon: [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) +## Auteurs principaux -## Log issues and pull requests +* Andrew van der Stock - X : [@vanderaj](https://x.com/vanderaj) +* Brian Glas - X : [@infosecdad](https://x.com/infosecdad) +* Neil Smithline - X : [@appsecneil](https://x.com/appsecneil) +* Tanya Janca - X : [@shehackspurple](https://x.com/shehackspurple) +* Torsten Gigler - Mastodon : [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) -Please log any corrections or issues: +## Signaler des problèmes et des pull requests -### Project links: -* [Homepage](https://owasp.org/www-project-top-ten/) -* [GitHub repository](https://github.com/OWASP/Top10) +Veuillez signaler toute correction ou tout problème : +### Liens du projet +* [Page d'accueil](https://owasp.org/www-project-top-ten/) +* [Dépôt GitHub](https://github.com/OWASP/Top10) diff --git a/2025/docs/fr/0x01_2025-About_OWASP.md b/2025/docs/fr/0x01_2025-About_OWASP.md index a4103e922..c480b1b5b 100644 --- a/2025/docs/fr/0x01_2025-About_OWASP.md +++ b/2025/docs/fr/0x01_2025-About_OWASP.md @@ -1,35 +1,35 @@ -# About OWASP +# À propos de l'OWASP -The Open Worldwide Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted. +L'Open Worldwide Application Security Project (OWASP) est une communauté ouverte qui aide les organisations à développer, acheter et maintenir des applications et des API fiables. -At OWASP, you'll find free and open: +À l'OWASP, vous trouverez gratuitement et librement accessibles : -- Application security tools and standards -- Cutting edge research -- Standard security controls and libraries -- Complete books on application security testing, secure code development, and secure code review -- Presentations and [videos](https://www.youtube.com/user/OWASPGLOBAL) -- [Cheat sheets](https://cheatsheetseries.owasp.org/) on many common topics -- [Chapters meetings](https://owasp.org/chapters/) held worldwide and online -- [Events, training, and conferences](https://owasp.org/events/). -- [Google Groups](https://groups.google.com/g/owasp) +- des outils et des normes pour la sécurité des applications ; +- des travaux de recherche de pointe ; +- des contrôles et des bibliothèques de sécurité standard ; +- des ouvrages complets sur les tests de sécurité des applications, le développement de code sécurisé et sa revue ; +- des présentations et des [vidéos](https://www.youtube.com/user/OWASPGLOBAL) ; +- des [aide-mémoire](https://cheatsheetseries.owasp.org/) sur de nombreux sujets courants ; +- des [réunions organisées par les chapitres locaux de l'OWASP](https://owasp.org/chapters/), partout dans le monde et en ligne ; +- des [événements, formations et conférences](https://owasp.org/events/) ; +- des [groupes Google](https://groups.google.com/g/owasp). -Learn more at: [https://owasp.org](https://owasp.org). +Pour en savoir plus : [https://owasp.org](https://owasp.org). -All OWASP tools, documents, videos, presentations, and chapters are free and open to anyone interested in improving application security. +Tous les outils, documents, vidéos, présentations et chapitres de l'OWASP sont gratuits et ouverts à toute personne intéressée par l'amélioration de la sécurité des applications. -We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in all these areas. +Nous préconisons d'aborder la sécurité des applications comme un problème lié aux personnes, aux processus et aux technologies, car les approches les plus efficaces nécessitent des améliorations dans chacun de ces domaines. -OWASP is a different kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, and cost-effective information about application security. +L'OWASP est une organisation d'un type particulier. Notre indépendance vis-à-vis des pressions commerciales nous permet de fournir des informations impartiales, pratiques et économiques sur la sécurité des applications. -OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. OWASP produces many types of materials in a collaborative, transparent, and open way. +L'OWASP n'est affilié à aucune entreprise technologique, même si nous soutenons un usage éclairé des technologies de sécurité commerciales. L'OWASP produit de nombreux types de contenus de manière collaborative, transparente et ouverte. -The OWASP Foundation is the non-profit entity that ensures the project's long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP board, chapter leaders, project leaders, and project members. We support innovative security research with grants and infrastructure. +La Fondation OWASP est l'entité à but non lucratif qui garantit la pérennité du projet. Presque toutes les personnes associées à l'OWASP sont bénévoles, notamment les membres du conseil d'administration, les responsables des chapitres locaux, les responsables de projets et les membres des projets. Nous soutenons la recherche innovante en sécurité par des subventions et des infrastructures. -Join us! +Rejoignez-nous ! -## Copyright and License +## Copyright et licence -![License](../assets/license.png) +![Licence](../assets/license.png) -Copyright © 2003-2025 The OWASP® Foundation, Inc. This document is released under the Creative Commons Attribution Share-Alike 4.0 license. For any reuse or distribution, you must make it clear to others the license terms of this work. +Copyright © 2003-2025 The OWASP® Foundation, Inc. Ce document est publié sous licence Creative Commons Attribution - Partage dans les mêmes conditions 4.0. Toute réutilisation ou distribution doit clairement indiquer les conditions de licence applicables à cette œuvre. diff --git a/2025/docs/fr/0x02_2025-What_are_Application_Security_Risks.md b/2025/docs/fr/0x02_2025-What_are_Application_Security_Risks.md index df1e9d066..04ff9b925 100644 --- a/2025/docs/fr/0x02_2025-What_are_Application_Security_Risks.md +++ b/2025/docs/fr/0x02_2025-What_are_Application_Security_Risks.md @@ -1,113 +1,100 @@ -# What are Application Security Risks? -Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these ways poses a potential risk that needs to be investigated. +# Quels sont les risques liés à la sécurité des applications ? -![Calculation diagram](../assets/2025-algorithm-diagram.png) +Les attaquants peuvent emprunter de nombreux chemins différents dans votre application pour nuire à votre activité ou à votre organisation. Chacun de ces chemins constitue un risque potentiel qui doit être étudié. + +![Schéma du calcul](../assets/2025-algorithm-diagram.png)
- Threat Agents + Acteurs de la menace - Attack \ -Vectors + Vecteurs
d'attaque 		- Exploitability + Exploitabilité - Likelihood of Missing Security -

- - Controls + Probabilité d'absence de
contrôles de sécurité

- Technical -

- - Impacts + Impacts
techniques

- Business -

- - Impacts + Impacts
métier

- By environment, \ -dynamic by situation picture + Selon l'environnement,
dynamique selon la situation 		- By Application exposure (by environment + Selon l'exposition de
l'application (par environnement) 		- Avg Weighted Exploit + Exploitabilité moyenne
pondérée 		- Missing Controls \ -by average Incidence rate \ -Weighed by coverage + Contrôles manquants
selon le taux d'incidence moyen,
pondéré par la couverture 		- Avg Weighted Impact + Impact moyen pondéré - By Business + Selon le métier
+Dans notre évaluation du risque, nous avons pris en compte les paramètres universels que sont l'exploitabilité, la probabilité moyenne d'absence de contrôles de sécurité pour une faiblesse et ses impacts techniques. -In our Risk Rating we have taken into account the universal parameters of exploitability, average likelihood of missing security controls for a weakness and its technical impacts. - -Each organization is unique, and so are the threat actors for that organization, their goals, and the impact of any breach. If a public interest organization uses a content management system (CMS) for public information and a health system uses that same exact CMS for sensitive health records, the threat actors and business impacts can be very different for the same software. It is critical to understand the risk to your organization based on the exposure of the application, the applicable threat agents by situation picture (for targeted and undirected attacks by business and location) and the individual business impacts. +Chaque organisation est unique, tout comme les acteurs de la menace qui la ciblent, leurs objectifs et l'impact d'une compromission. Si une organisation d'intérêt public utilise un système de gestion de contenu (CMS) pour diffuser des informations publiques, tandis qu'un système de santé utilise exactement le même CMS pour des dossiers médicaux sensibles, les acteurs de la menace et les impacts métier peuvent être très différents pour un même logiciel. Il est essentiel de comprendre le risque pour votre organisation en fonction de l'exposition de l'application, des acteurs de la menace pertinents selon la situation (attaques ciblées ou non ciblées, activité et localisation) et des impacts métier propres à l'organisation. +## Utilisation des données pour sélectionner et classer les catégories -## How the data is used for selecting categories and ranking them +En 2017, nous avons sélectionné les catégories selon le taux d'incidence pour déterminer la probabilité, puis nous les avons classées à la suite de discussions de l'équipe fondées sur plusieurs décennies d'expérience en matière d'exploitabilité, de détectabilité (également une probabilité) et d'impact technique. En 2021, nous avons utilisé les données d'exploitabilité et d'impact (technique) issues des scores CVSSv2 et CVSSv3 de la National Vulnerability Database (NVD). Pour 2025, nous avons poursuivi la même méthodologie que celle créée en 2021. -In 2017, we selected categories by incidence rate to determine likelihood, then ranked them by team discussion based on decades of experience for Exploitability, Detectability (also likelihood), and Technical Impact. For 2021, we used data for Exploitability and (Technical) Impact from the CVSSv2 and CVSSv3 scores in the National Vulnerability Database (NVD). For 2025, we continued the same methodology that we created in 2021. +Nous avons téléchargé OWASP Dependency-Check et extrait les scores CVSS d'exploitabilité et d'impact, regroupés par CWE correspondante. Cela a nécessité beaucoup de recherches et d'efforts : tous les CVE disposent de scores CVSSv2, mais cette version comporte des défauts que CVSSv3 est censée corriger. Après une certaine date, tous les CVE se voient également attribuer un score CVSSv3. En outre, les plages de scores et les formules ont été mises à jour entre CVSSv2 et CVSSv3. -We downloaded OWASP Dependency Check and extracted the CVSS Exploit, and Impact scores grouped by related CWEs. It took a fair bit of research and effort as all the CVEs have CVSSv2 scores, but there are flaws in CVSSv2 that CVSSv3 should address. After a certain point in time, all CVEs are assigned a CVSSv3 score as well. Additionally, the scoring ranges and formulas were updated between CVSSv2 and CVSSv3. +Dans CVSSv2, l'exploitabilité et l'impact (technique) pouvaient tous deux atteindre 10,0, mais la formule les ramenait à 60 % pour l'exploitabilité et à 40 % pour l'impact. Dans CVSSv3, le maximum théorique était limité à 6,0 pour l'exploitabilité et à 4,0 pour l'impact. Une fois la pondération prise en compte, le score d'impact a augmenté en moyenne de près d'un point et demi dans CVSSv3, tandis que l'exploitabilité a diminué en moyenne de près d'un demi-point lors de notre analyse du Top 10 2021. -In CVSSv2, both Exploit and (Technical) Impact could be up to 10.0, but the formula would knock them down to 60% for Exploit and 40% for Impact. In CVSSv3, the theoretical max was limited to 6.0 for Exploit and 4.0 for Impact. With the weighting considered, the Impact scoring shifted higher, almost a point and a half on average in CVSSv3, and exploitability moved nearly half a point lower on average when we conducted analysis for the 2021 Top Ten. +Il existe environ 175 000 enregistrements de CVE associés à des CWE dans la National Vulnerability Database (NVD), extraits d'OWASP Dependency-Check, contre 125 000 en 2021. De plus, 643 CWE uniques sont associées à des CVE, contre 241 en 2021. Parmi les quelque 220 000 CVE extraits, 160 000 possédaient des scores CVSS v2, 156 000 des scores CVSS v3 et 6 000 des scores CVSS v4. De nombreux CVE possèdent plusieurs scores, ce qui explique que leur total dépasse 220 000. -There are approximately 175k records (up from 125k in 2021) of CVEs mapped to CWEs in the National Vulnerability Database (NVD), extracted from OWASP Dependency Check. Additionally, there are 643 unique CWEs mapped to CVEs (up from 241 in 2021). Within the nearly 220k CVEs that were extracted, 160k had CVSS v2 scores, 156k had CVSS v3 scores, and 6k had CVSS v4 scores. Many CVEs have multiple scores, which is why they total more than 220k. +Pour le Top 10 2025, nous avons calculé les scores moyens d'exploitabilité et d'impact de la manière suivante. Nous avons regroupé par CWE tous les CVE disposant de scores CVSS et pondéré les scores d'exploitabilité et d'impact selon le pourcentage de la population disposant de CVSSv3, ainsi que selon la population restante disposant de scores CVSSv2, afin d'obtenir une moyenne globale. Nous avons associé ces moyennes aux CWE du jeu de données pour les utiliser comme scores d'exploitabilité et d'impact (technique) dans l'autre moitié de l'équation du risque. -For the Top Ten 2025, we calculated average exploit and impact scores in the following manner. We grouped all the CVEs with CVSS scores by CWE and weighted both exploit and impact scores by the percentage of the population that had CVSSv3, as well as the remaining population with CVSSv2 scores, to get an overall average. We mapped these averages to the CWEs in the dataset to use as Exploit and (Technical) Impact scoring for the other half of the risk equation. +Pourquoi ne pas utiliser CVSS v4.0, pourriez-vous demander ? Parce que l'algorithme de notation a été fondamentalement modifié et ne fournit plus aussi facilement les scores d'*exploitabilité* ou d'*impact* que CVSSv2 et CVSSv3. Nous tenterons de trouver un moyen d'utiliser la notation CVSS v4.0 dans les prochaines versions du Top 10, mais nous n'avons pas pu déterminer une méthode à temps pour l'édition 2025. -Why not use CVSS v4.0, you may ask? That’s because the scoring algorithm was fundamentally changed, and it no longer easily provides the *Exploit* or *Impact* scores as CVSSv2 and CVSSv3 do. We will attempt to figure out a way to use CVSS v4.0 scoring for future versions of the Top Ten, but we were unable to determine a timely way to do so for the 2025 edition. +Pour le taux d'incidence, nous avons calculé le pourcentage d'applications vulnérables à chaque CWE parmi la population testée par une organisation pendant une période donnée. Rappelons que nous n'utilisons pas la fréquence (c'est-à-dire le nombre de fois où un problème apparaît dans une application) : nous nous intéressons au pourcentage d'applications de la population dans lesquelles chaque CWE a été détectée. -For the incidence rate, we calculated the percentage of applications vulnerable to each CWE from the population tested by an org for a period of time. As a reminder, we are not using frequency (or how many times an issue appears in an application), we are interested in what percentage of the population of applications were found to have each CWE. +Pour la couverture, nous considérons le pourcentage d'applications testées par l'ensemble des organisations pour une CWE donnée. Plus la couverture calculée est élevée, plus il est probable que le taux d'incidence soit exact, puisque la taille de l'échantillon est plus représentative de la population. -For coverage we look at the percentage of applications tested by all organizations for a given CWE. The higher the calculated coverage, the stronger the assurance that the incidence rate is accurate as the sample size is more representative of the population. +La formule utilisée pour cette édition est similaire à celle de 2021, avec quelques changements de pondération : -The formula that we used for this iteration is similar to 2021, with some weighting changes: -(Max Incidence Rate % * 1000) + (Max Coverage % * 100) + (Avg Exploit * 10) + (Avg Impact * 20) + (Sum Occurrences / 10000) = Risk Score +`(Taux d'incidence maximal % * 1000) + (Couverture maximale % * 100) + (Exploitabilité moyenne * 10) + (Impact moyen * 20) + (Total des occurrences / 10000) = Score de risque` -The calculated scores ranged from 621.60 for the category of Broken Access Control to 271.08 for Memory Management Errors. +Les scores calculés allaient de 621,60 pour la catégorie Contrôles d'accès défaillants à 271,08 pour Erreurs de gestion de la mémoire. -This is not a perfect system, but it is valuable for ranking risk categories. +Ce système n'est pas parfait, mais il est utile pour classer les catégories de risques. -One additional challenge that is growing is the definition of an "application". As the industry shifts to different architectures that consist of micro-services and other implementations that are smaller than a traditional application, calculations are more difficult. For instance, if an organization is testing code repositories, what does it consider an application? Similar to the growth of CVSSv4, the next edition of the Top Ten may need to adjust the analysis and scoring to account for a constantly changing industry. +Un autre défi croissant tient à la définition d'une « application ». À mesure que le secteur adopte des architectures différentes, composées de microservices et d'autres implémentations plus petites qu'une application traditionnelle, les calculs deviennent plus difficiles. Par exemple, si une organisation teste des dépôts de code, qu'entend-elle par application ? Comme avec l'évolution de CVSSv4, la prochaine édition du Top 10 devra peut-être ajuster l'analyse et la notation pour tenir compte d'un secteur en constante évolution. -## Data Factors +## Facteurs liés aux données -There are data factors that are listed for each of the Top Ten Categories, here is what they mean: +Des facteurs liés aux données sont indiqués pour chacune des catégories du Top 10. Voici leur signification : -**CWEs Mapped:** The number of CWEs mapped to a category by the Top Ten team. +**CWE associées :** nombre de CWE associées à une catégorie par l'équipe du Top 10. -**Incidence Rate:** Incidence rate is the percentage of applications vulnerable to that CWE from the population tested by that org for that year. +**Taux d'incidence :** pourcentage d'applications vulnérables à cette CWE parmi la population testée par l'organisation pour l'année concernée. -**Weighted Exploit:** The Exploit sub-score from CVSSv2 and CVSSv3 scores assigned to CVEs mapped to CWEs, normalized, and placed on a 10pt scale. +**Exploitabilité pondérée :** sous-score d'exploitabilité des scores CVSSv2 et CVSSv3 attribués aux CVE associés à des CWE, normalisé et ramené à une échelle de 10 points. -**Weighted Impact:** The Impact sub-score from CVSSv2 and CVSSv3 scores assigned to CVEs mapped to CWEs, normalized, and placed on a 10pt scale. +**Impact pondéré :** sous-score d'impact des scores CVSSv2 et CVSSv3 attribués aux CVE associés à des CWE, normalisé et ramené à une échelle de 10 points. -**(Testing) Coverage:** The percentage of applications tested by all organizations for a given CWE. +**Couverture (des tests) :** pourcentage d'applications testées par toutes les organisations pour une CWE donnée. -**Total Occurrences:** Total number of applications found to have the CWEs mapped to a category. +**Total des occurrences :** nombre total d'applications dans lesquelles les CWE associées à une catégorie ont été trouvées. -**Total CVEs:** Total number of CVEs in the NVD DB that were mapped to the CWEs mapped to a category. +**Total des CVE :** nombre total de CVE dans la base NVD qui ont été associés aux CWE elles-mêmes associées à une catégorie. -**Formula:** (Max Incidence Rate % * 1000) + (Max Coverage % * 100) + (Avg Exploit * 10) + (Avg Impact * 20) + (Sum Occurrences / 10000) = Risk Score +**Formule :** `(Taux d'incidence maximal % * 1000) + (Couverture maximale % * 100) + (Exploitabilité moyenne * 10) + (Impact moyen * 20) + (Total des occurrences / 10000) = Score de risque` diff --git a/2025/docs/fr/0x03_2025-Establishing_a_Modern_Application_Security_Program.md b/2025/docs/fr/0x03_2025-Establishing_a_Modern_Application_Security_Program.md index 7ae94c703..4ab7dafbd 100644 --- a/2025/docs/fr/0x03_2025-Establishing_a_Modern_Application_Security_Program.md +++ b/2025/docs/fr/0x03_2025-Establishing_a_Modern_Application_Security_Program.md @@ -1,307 +1,284 @@ -# Establishing a Modern Application Security Program +# Mettre en place un programme moderne de sécurité des applications -The OWASP Top Ten lists are awareness documents, meant to bring awareness to the most critical risks of whichever topic they cover. They are not meant to be a complete list, only a starting place. In previous versions of this list we have prescribed starting an application security program as the best way to avoid these risks, and more. In this section we will cover how to start and build a modern application security program. +Les éditions du Top 10 de l'OWASP sont des documents de sensibilisation destinés à attirer l'attention sur les risques les plus critiques du sujet traité. Elles ne constituent pas une liste exhaustive, mais seulement un point de départ. Dans les éditions précédentes, nous avons recommandé de commencer par mettre en place un programme de sécurité des applications afin d'éviter ces risques et bien d'autres. Cette section explique comment démarrer et construire un programme moderne de sécurité des applications. - +Si vous disposez déjà d'un programme de sécurité des applications, envisagez d'en évaluer la maturité à l'aide de [l'OWASP SAMM (Software Assurance Maturity Model)](https://owasp.org/www-project-samm/) ou du DSOMM (DevSecOps Maturity Model). Ces modèles de maturité sont complets et détaillés ; ils peuvent vous aider à déterminer où concentrer vos efforts pour développer et faire mûrir votre programme. Notez qu'il n'est pas nécessaire de tout mettre en œuvre dans OWASP SAMM ou DSOMM pour faire du bon travail : ces modèles sont destinés à vous guider et à vous proposer de nombreuses options. Ils ne fixent pas des standards inatteignables et ne décrivent pas des programmes hors de portée financière. Leur ampleur vise à vous fournir de nombreuses idées et possibilités. -If you already have an application security program, consider performing a maturity assessment on it using [OWASP SAMM (Software Assurance Maturity Model)](https://owasp.org/www-project-samm/) or DSOMM (DevSecOps Maturity Model) . These maturity models are comprehensive and exhaustive and can be used to help you figure out where you should best focus your efforts for expanding and maturing your program. Please note: you do not need to do everything in OWASP SAMM or DSOMM to be doing a good job, they are meant to guide you and offer many options. They are not meant to offer unattainable standards or describe unaffordable programs. They are expansive in order to offer you many ideas and options. +Si vous démarrez un programme de zéro, ou si OWASP SAMM ou DSOMM vous semblent actuellement « trop ambitieux » pour votre équipe, consultez les recommandations suivantes. - +### 1. Mettre en place une approche de portefeuille fondée sur le risque -If you are starting a program from scratch, or you find OWASP SAMM or DSOMM ‘too much’ for your team right now, please review the following advice. +* Identifiez les besoins de protection de votre portefeuille d'applications du point de vue métier. Cette démarche doit notamment tenir compte des lois sur la protection de la vie privée et des autres réglementations applicables à l'actif de données à protéger. +* Établissez un [modèle commun d'évaluation du risque](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) comportant un ensemble cohérent de facteurs de probabilité et d'impact reflétant la tolérance au risque de votre organisation. -### 1. Establish a Risk Based Portfolio Approach: +* Mesurez et hiérarchisez en conséquence toutes vos applications et vos API. Ajoutez les résultats à votre [base de données de gestion de configuration (CMDB)](https://de.wikipedia.org/wiki/Configuration_Management_Database). -* Identify the protection needs of your application portfolio from a business perspective. This should be driven in part by privacy laws and other regulations relevant to the data asset being protected. +* Définissez des lignes directrices d'assurance afin de déterminer correctement la couverture et le niveau de rigueur requis. -* Establish a [common risk rating model](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) with a consistent set of likelihood and impact factors reflective of your organization’s tolerance for risk. +### 2. S'appuyer sur un socle solide +* Définissez un ensemble ciblé de politiques et de normes qui fournit une base de sécurité des applications à respecter par toutes les équipes de développement. -* Accordingly measure and prioritize all your applications and APIs. Add the results to your [Configuration Management Database (CMDB)](https://de.wikipedia.org/wiki/Configuration_Management_Database). +* Définissez un ensemble commun de contrôles de sécurité réutilisables qui complètent ces politiques et normes et fournissent des recommandations de conception et de développement sur leur utilisation. -* Establish assurance guidelines to properly define coverage and level of rigor required. +* Établissez un programme de formation à la sécurité des applications, obligatoire et adapté aux différents rôles et sujets liés au développement. +### 3. Intégrer la sécurité aux processus existants -### 2. Enable with a Strong Foundation: +* Définissez et intégrez les activités de mise en œuvre et de vérification sécurisées aux processus existants de développement et d'exploitation. -* Establish a set of focused policies and standards that provide an application security baseline for all development teams to adhere to. +* Ces activités comprennent la modélisation des menaces, la conception sécurisée et sa revue, le codage sécurisé et la revue de code, les tests d'intrusion et la remédiation. -* Define a common set of reusable security controls that complement these policies and standards and provide design and development guidance on their use. +* Mettez à disposition des experts et des services d'accompagnement afin d'aider les équipes de développement et de projet à réussir. -* Establish an application security training curriculum that is required and targeted to different development roles and topics. +* Examinez votre cycle de vie actuel du développement des systèmes ainsi que toutes les activités, tous les outils, toutes les politiques et tous les processus de sécurité logicielle, puis documentez-les. +* Pour tout nouveau logiciel, ajoutez une ou plusieurs activités de sécurité à chaque phase du cycle de vie du développement des systèmes (SDLC). Nous proposons ci-dessous de nombreuses suggestions. Assurez-vous de réaliser ces nouvelles activités pour chaque nouveau projet ou initiative logicielle : vous saurez ainsi que chaque nouveau logiciel sera livré avec un niveau de sécurité acceptable pour votre organisation. -### 3. Integrate Security into Existing Processes: +* Sélectionnez vos activités de manière à ce que le produit final respecte un niveau de risque acceptable pour votre organisation. -* Define and integrate secure implementation and verification activities into existing development and operational processes. +* Pour les logiciels existants, parfois appelés logiciels hérités, prévoyez un plan de maintenance formel. Consultez ci-dessous la section « Exploitation et gestion des changements » pour trouver des idées permettant de maintenir la sécurité des applications. -* Activities include threat modeling, secure design and design review, secure coding and code review, penetration testing, and remediation. +### 4. Former à la sécurité des applications -* Provide subject matter experts and support services for development and project teams to be successful. +* Envisagez de lancer un programme de référents sécurité, ou un programme général de formation à la sécurité pour vos développeurs (parfois appelé programme de promotion ou de sensibilisation à la sécurité), afin de leur enseigner tout ce que vous souhaiteriez qu'ils sachent. Cela les tiendra à jour, les aidera à travailler de manière sécurisée et rendra la culture de la sécurité plus positive sur leur lieu de travail. Cela améliore souvent aussi la confiance entre les équipes et favorise de meilleures relations de travail. L'OWASP vous accompagne avec le [Guide OWASP des référents sécurité](https://securitychampions.owasp.org/), qui est enrichi progressivement. -* Review your current system development life cycle and all software security activities, tooling, policies, and processes, then document them. +* Le projet OWASP Education fournit des supports de formation pour aider à former les développeurs à la sécurité des applications web. Pour apprendre concrètement à propos des vulnérabilités, essayez le [projet OWASP Juice Shop](https://owasp.org/www-project-juice-shop/) ou [OWASP WebGoat](https://owasp.org/www-project-webgoat/). Pour rester à jour, participez à une [conférence OWASP AppSec](https://owasp.org/events/), à une [formation lors d'une conférence OWASP](https://owasp.org/events/) ou aux réunions d'un [chapitre OWASP](https://owasp.org/chapters/) local. -* For new software, add one or more security activities to each phase of the system development life cycle (SDLC). Below we offer many suggestions of what you can do below. Ensure you perform these new activities on every new project or software initiative, this way you will know each new piece of software will be delivered at an acceptable security posture for your organizations. +### 5. Donner de la visibilité à la direction -* Select your activities to ensure your final product meets an acceptable level of risk for your organization. +* Pilotez avec des indicateurs. Orientez les décisions d'amélioration et de financement à partir des indicateurs et des données d'analyse recueillis. Les indicateurs comprennent notamment le respect des pratiques et activités de sécurité, les vulnérabilités introduites, les vulnérabilités corrigées, la couverture de l'application et la densité des défauts par type et par nombre d'occurrences. -* For existing software (sometimes called legacy) you will want to have a formal maintenance plan, please look below for ideas of how to maintain secure applications in the section called 'Operations and Change Management'. +* Analysez les données issues des activités de mise en œuvre et de vérification afin de rechercher les causes racines et les modèles de vulnérabilités, et de conduire des améliorations stratégiques et systémiques dans toute l'entreprise. Tirez les leçons des erreurs et proposez des incitations positives pour encourager les améliorations. +## Établir et utiliser des processus de sécurité reproductibles et des contrôles de sécurité standard -### 4. Application Security Education: +### Phase des exigences et de la gestion des ressources -* Consider starting a security champion program, or general security education program for your developers (sometimes called an advocacy or security awareness program), to teach them everything you wish they would know. This will keep them up to date, help them know how to do their work securely, and make the security culture where you work more positive. It often also improves trust between the teams and makes for a happier working relationship. OWASP supports you in this with the [OWASP Security Champions Guide](https://securitychampions.owasp.org/), which is being expanded step by step. +* Recueillez et négociez avec le métier les exigences métier d'une application, notamment les exigences de protection relatives à la confidentialité, à l'authenticité, à l'intégrité et à la disponibilité de tous les actifs de données, ainsi que la logique métier attendue. -* The OWASP Education Project provides training materials to help educate developers on web application security. For hands-on learning about vulnerabilities, try the [OWASP Juice Shop Project](https://owasp.org/www-project-juice-shop/), or [OWASP WebGoat](https://owasp.org/www-project-webgoat/). To stay current, come to an [OWASP AppSec Conference](https://owasp.org/events/), [OWASP Conference Training](https://owasp.org/events/), or local [OWASP Chapter](https://owasp.org/chapters/) meetings. +* Rassemblez les exigences techniques, y compris les exigences de sécurité fonctionnelles et non fonctionnelles. L'OWASP recommande d'utiliser [l'OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) comme guide pour définir les exigences de sécurité de vos applications. +* Planifiez et négociez le budget couvrant tous les aspects de la conception, de la construction, des tests et de l'exploitation, y compris les activités de sécurité. -### 5. Provide Management Visibility: +* Ajoutez les activités de sécurité au calendrier du projet. -* Manage with metrics. Drive improvement and funding decisions based on the metrics and analysis data captured. Metrics include adherence to security practices and activities, vulnerabilities introduced, vulnerabilities mitigated, application coverage, defect density by type and instance counts, etc. +* Présentez-vous comme le représentant de la sécurité lors du lancement du projet afin que chacun sache à qui s'adresser. -* Analyze data from the implementation and verification activities to look for root cause and vulnerability patterns to drive strategic and systemic improvements across the enterprise. Learn from mistakes and offer positive incentives to promote improvements. +### Appel d'offres (RFP) et contractualisation +* Négociez les exigences avec les développeurs internes ou externes, notamment les recommandations et exigences de sécurité relatives à votre programme de sécurité, par exemple le SDLC et les bonnes pratiques. +* Évaluez le respect de toutes les exigences techniques, y compris celles de la phase de planification et de conception. -## Establish & Use Repeatable Security Processes and Standard Security Controls +* Négociez toutes les exigences techniques, notamment la conception, la sécurité et les accords de niveau de service (SLA). -### Requirements and Resource Management Phase: +* Adoptez des modèles et des listes de contrôle, tels que [l'annexe OWASP sur les contrats de logiciels sécurisés](https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex).
**Remarque :** *Cette annexe est prévue pour le droit des contrats américain ; consultez un professionnel du droit qualifié avant d'utiliser le modèle d'annexe.* -* Collect and negotiate the business requirements for an application with the business, including the protection requirements with regard to confidentiality, authenticity, integrity and availability of all data assets, and the expected business logic. +### Phase de planification et de conception -* Compile the technical requirements including functional and nonfunctional security requirements. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)(https://owasp.org/www-project-application-security-verification-standard/) as a guide for setting the security requirements for your application(s). +* Négociez la planification et la conception avec les développeurs et les parties prenantes internes, par exemple les spécialistes de la sécurité. -* Plan and negotiate the budget that covers all aspects of design, build, testing and operation, including security activities. +* Définissez l'architecture de sécurité, les contrôles, les contre-mesures et les revues de conception adaptés aux besoins de protection et au niveau de menace attendu. Ces éléments doivent être accompagnés par des spécialistes de la sécurité. -* Add security activities to your project schedule. +* Plutôt que d'ajouter la sécurité après coup à vos applications et API, il est beaucoup plus économique de l'intégrer dès le départ. L'OWASP recommande les [aide-mémoire OWASP](https://cheatsheetseries.owasp.org/index.html) et les [contrôles proactifs OWASP](https://top10proactive.owasp.org/) comme points de départ pour concevoir une sécurité intégrée dès le début. -* Introduce yourself as the security representative at the project kick off, so they know who to talk to. +* Réalisez une modélisation des menaces ; consultez l'[aide-mémoire OWASP sur la modélisation des menaces](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). +* Enseignez aux architectes logiciels les concepts et modèles de conception sécurisés et demandez-leur de les intégrer à leurs conceptions lorsque cela est possible. -### Request for Proposals (RFP) and Contracting: +* Examinez les flux de données avec vos développeurs. -* Negotiate the requirements with internal or external developers, including guidelines and security requirements with respect to your security program, e.g. SDLC, best practices. +* Ajoutez des récits utilisateurs de sécurité à côté de tous vos autres récits utilisateurs. -* Rate the fulfillment of all technical requirements, including a planning and design phase. +### Cycle de vie du développement sécurisé -* Negotiate all technical requirements, including design, security, and service level agreements (SLA). +* Pour améliorer le processus suivi par votre organisation lors de la construction d'applications et d'API, l'OWASP recommande le [Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/). Ce modèle aide les organisations à élaborer et à mettre en œuvre une stratégie de sécurité logicielle adaptée aux risques particuliers auxquels elles sont confrontées. -* Adopt templates and checklists, such as [OWASP Secure Software Contract Annex](https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex).
**Note:** *The annex is for US contract law, so please consult qualified legal advice before using the sample annex.* +* Formez vos développeurs logiciels aux pratiques de développement sécurisé et à toute autre compétence qui peut les aider à créer des applications plus robustes et plus sécurisées. +* Effectuez des revues de code ; consultez l'[aide-mémoire OWASP sur la revue de code sécurisé](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). -### Planning and Design Phase: +* Fournissez à vos développeurs des outils de sécurité, puis apprenez-leur à les utiliser, notamment les outils d'analyse statique, d'analyse de composition logicielle, d'analyse des secrets et les scanners d'[Infrastructure as Code (IaC)](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html). -* Negotiate planning and design with the developers and internal shareholders, e.g. security specialists. +* Créez si possible des garde-fous pour vos développeurs (des protections techniques qui les orientent vers des choix plus sûrs). -* Define the security architecture, controls, countermeasures and design reviews appropriate to the protection needs and the expected threat level. This should be supported by security specialists. +* Construire des contrôles de sécurité solides et utilisables est difficile. Proposez autant que possible des valeurs sécurisées par défaut et créez des « chemins pavés » : la façon la plus simple de faire quelque chose doit aussi être la plus sûre et constituer naturellement la voie privilégiée. Les [aide-mémoire OWASP](https://cheatsheetseries.owasp.org/index.html) sont un bon point de départ pour les développeurs, et de nombreux frameworks modernes proposent désormais des contrôles de sécurité standard et efficaces pour l'autorisation, la validation, la prévention des CSRF, etc. -* Rather than retrofitting security into your applications and APIs, it is far more cost effective to design the security in from the start. OWASP recommends the [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) and the [OWASP Proactive Controls](https://top10proactive.owasp.org/) as a good starting point for guidance on how to design security included from the beginning. +* Fournissez à vos développeurs des extensions d'IDE liées à la sécurité et encouragez-les à les utiliser. -* Perform threat modelling, see [OWASP Cheat Sheet: Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). +* Fournissez-leur un outil de gestion des secrets, les licences nécessaires et la documentation expliquant comment l'utiliser. -* Teach your software architects secure design concepts and patterns and ask them to add them to their designs where possible. +* Fournissez-leur une IA privée, idéalement configurée avec un serveur RAG rempli de documentation de sécurité utile, des prompts rédigés par votre équipe pour obtenir de meilleurs résultats et un serveur MCP qui appelle les outils de sécurité choisis par votre organisation. Apprenez-leur à utiliser l'IA en toute sécurité : ils le feront que cela vous plaise ou non. -* Examine data flows with your developers. +### Mettre en place des tests continus de sécurité des applications -* Add security user stories alongside all of your other user stories. +* Testez les fonctions techniques et l'intégration à l'architecture informatique, et coordonnez les tests métier. +* Créez des cas de test « d'utilisation » et « d'abus » du point de vue technique et métier. -### Secure Development Lifecycle: +* Gérez les tests de sécurité selon les processus internes, les besoins de protection et le niveau de menace supposé de l'application. +* Fournissez des outils de test de sécurité (fuzzers, DAST, etc.), un environnement de test sûr et une formation à leur utilisation, OU réalisez les tests vous-même, OU engagez un testeur. -* To improve the process your organization follows when building applications and APIs, OWASP recommends the [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/). This model helps organizations formulate and implement a strategy for software security that is tailored to the specific risks facing their organization. +* Si vous avez besoin d'un niveau d'assurance élevé, envisagez un test d'intrusion formel ainsi que des tests de résistance et de performance. -* Provide secure coding training to your software developers, and any other training you think will help them create more robust and secure applications. +* Travaillez avec vos développeurs pour les aider à décider ce qu'ils doivent corriger dans les rapports de bugs et assurez-vous que leurs responsables leur accordent le temps nécessaire. -* Code review, see [OWASP Cheat Sheet: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). +### Déploiement -* Give your developers security tools, then teach them how to use them, especially static analysis, software composition analysis, secret, and [Infrastructure-as-Code (IaC)](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) scanners. +* Mettez l'application en production et migrez depuis les applications précédemment utilisées si nécessaire. -* Create guardrails for your developers, if possible (technical safeguards to steer them towards more secure choices). +* Finalisez toute la documentation, notamment la base de données de gestion des changements (CMDB) et l'architecture de sécurité. -* Building strong and usable security controls is difficult. Offer secure defaults whenever possible, and create ‘paved roads’ (making the easiest way also the most secure way to do something, the obvious preferred way) whenever possible. The [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) are a good starting point for developers, and many modern frameworks now come with standard and effective security controls for authorization, validation, CSRF prevention, etc. +### Exploitation et gestion des changements -* Give your developers security-related IDE plugins and encourage them to use them. +* L'exploitation doit inclure des recommandations pour la gestion de la sécurité de l'application, par exemple la gestion des correctifs. -* Provide them a secret management tool, licenses, and documentation on how to use it. +* Sensibilisez les utilisateurs à la sécurité et gérez les conflits entre utilisabilité et sécurité. -* Provide them a private AI to use, ideally set up with a RAG server full of useful security documentation, prompts your team has written for better outcomes, and an MCP server that calls the security tooling of choice for your org. Teach them how to use AI safely, because they are going to do it whether you like it or not. +* Planifiez et gérez les changements, par exemple la migration vers de nouvelles versions de l'application ou d'autres composants tels que le système d'exploitation, les intergiciels et les bibliothèques. +* Assurez-vous que toutes les applications figurent dans votre inventaire et que toutes les informations importantes sont documentées. Mettez à jour toute la documentation, notamment la CMDB, l'architecture de sécurité, les contrôles et les contre-mesures, ainsi que les procédures opérationnelles ou la documentation de projet. -### Establish Continuous Application Security Testing: +* Mettez en place la journalisation, la surveillance et les alertes pour toutes les applications. Ajoutez-les lorsqu'elles sont absentes. -* Test the technical functions and integration with the IT architecture and coordinate business tests. +* Créez des processus de mise à jour et d'application des correctifs efficaces. -* Create “use” and “abuse” test cases from technical and business perspectives. +* Créez des calendriers d'analyse réguliers (si possible analyse dynamique, statique, des secrets, de l'IaC et de la composition logicielle). -* Manage security tests according to internal processes, the protection needs, and the assumed threat level by the application. +* Définissez des SLA pour corriger les bugs de sécurité. -* Provide security testing tools (fuzzers, DAST, etc.), a safe place to test, and training on how to use them, OR do the testing for them OR hire a tester +* Fournissez un moyen aux employés (et idéalement aussi à vos clients) de signaler les bugs. -* If you require a high level of assurance, consider a formal penetration test, as well as stress testing and performance testing. +* Mettez en place une équipe de réponse aux incidents formée, qui comprend à quoi ressemblent les attaques logicielles et qui sait utiliser les outils d'observabilité. -* Work with your developers to help them decide what they need to fix from the bug reports, and ensure their managers give them time to do it. +* Exécutez des outils de blocage ou de protection pour arrêter les attaques automatisées. +* Renforcez les configurations une fois par an, ou plus souvent. -### Rollout: +* Effectuez au moins un test d'intrusion annuel, selon le niveau d'assurance requis pour votre application. -* Put the application in operation and migrate from previously used applications if needed. +* Mettez en place des processus et des outils pour renforcer et protéger votre chaîne d'approvisionnement logicielle. -* Finalize all documentation, including the change management database (CMDB) and security architecture. +* Établissez et mettez à jour un plan de continuité d'activité et de reprise après sinistre qui inclut vos applications les plus importantes et les outils utilisés pour les maintenir. +### Mise hors service des systèmes -### Operations and Change Management: +* Les données nécessaires doivent être archivées. Toutes les autres données doivent être effacées de manière sécurisée. -* Operations must include guidelines for the security management of the application (e.g. patch management). +* Mettez l'application hors service de manière sécurisée, notamment en supprimant les comptes, rôles et permissions inutilisés. -* Raise the security awareness of users and manage conflicts about usability vs. security. +* Indiquez l'état « retirée » de l'application dans la CMDB. -* Plan and manage changes, e.g. migrate to new versions of the application or other components like OS, middleware, and libraries. +## Utiliser le Top 10 de l'OWASP comme norme -* Ensure all apps are in your inventory, with all important details documented. Update all documentation, including in the CMDB and the security architecture, controls, and countermeasures, including any runbooks or project documentation. +Le Top 10 de l'OWASP est avant tout un document de sensibilisation. Cela n'a toutefois pas empêché les organisations de l'utiliser comme norme de fait de l'industrie AppSec depuis sa création en 2003. Si vous souhaitez utiliser le Top 10 de l'OWASP comme norme de codage ou de test, sachez qu'il s'agit du strict minimum et seulement d'un point de départ. -* Perform logging, monitoring, and alerting for all apps. Add it if it’s missing. - -* Create processes for effective and efficient updating and patching. - -* Create regular scanning schedules (hopefully dynamic, static, secrets, IaC, and software composition analysis). - -* SLAs for fixing security bugs. - -* Provide a way for employees (and ideally also your customers) to report bugs. - -* Establish a trained incident response team that understands what software attacks look like, observability tooling. - -* Run blocking or shielding tools to stop automated attacks. - -* Annual (or more often) hardening of configurations. - -* At least annual penetration testing (depending upon the level assurance required for your app). - -* Establish processes and tooling for hardening and protecting your software supply chain. - -* Establish and update business continuity and disaster recovery planning that includes your most important applications and the tools you use to maintain them. - - -### Retiring Systems: - -* Any required data should be archived. All other data should be securely wiped. - -* Securely retire the application, including deleting unused accounts and roles and permissions. - -* Set your application’s state to retired in the CMDB. - - -## Using the OWASP Top 10 as a standard - -The OWASP Top 10 is primarily an awareness document. However, this has not stopped organizations from using it as a de facto industry AppSec standard since its inception in 2003. If you want to use the OWASP Top 10 as a coding or testing standard, know that it is the bare minimum and just a starting point. - -One of the difficulties of using the OWASP Top 10 as a standard is that we document AppSec risks, and not necessarily easily testable issues. For example, [A06:2025-Insecure Design](A06_2025-Insecure_Design.md) is beyond the scope of most forms of testing. Another example is testing whether in-place, in-use, and effective logging and monitoring are implemented, which can only be done with interviews and requesting a sampling of effective incident responses. A static code analysis tool can look for the absence of logging, but it might be impossible to determine if business logic or access control is logging critical security breaches. Penetration testers may only be able to determine that they have invoked incident response in a test environment, which is rarely monitored in the same way as production. - -Here are our recommendations for when it is appropriate to use the OWASP Top 10: +L'une des difficultés liées à l'utilisation du Top 10 de l'OWASP comme norme est que nous documentons des risques AppSec et non nécessairement des problèmes faciles à tester. Par exemple, [A06:2025 - Conception non sécurisée](A06_2025-Insecure_Design.md) dépasse le périmètre de la plupart des formes de test. Un autre exemple est la vérification de la mise en place d'une journalisation et d'une surveillance présentes, utilisées et efficaces ; elle ne peut être réalisée qu'au moyen d'entretiens et de l'examen d'un échantillon de réponses efficaces aux incidents. Un outil d'analyse statique du code peut rechercher l'absence de journalisation, mais il peut être impossible de déterminer si la logique métier ou le contrôle d'accès journalise les violations de sécurité critiques. Les testeurs d'intrusion peuvent seulement constater qu'ils ont déclenché une réponse aux incidents dans un environnement de test, qui est rarement surveillé de la même manière que la production. +Voici nos recommandations sur les cas où il est approprié d'utiliser le Top 10 de l'OWASP : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use Case + Cas d'utilisation OWASP Top 10 2025 + Top 10 de l'OWASP 2025 OWASP Application Security Verification Standard
Awareness + Sensibilisation Yes + Oui
Training + Formation Entry level + Niveau débutant Comprehensive + Complète
Design and architecture + Conception et architecture Occasionally + Occasionnellement Yes + Oui
Coding standard + Norme de codage Bare minimum + Strict minimum Yes + Oui
Secure Code review + Revue de code sécurisé Bare minimum + Strict minimum Yes + Oui
Peer review checklist + Liste de contrôle de revue par les pairs Bare minimum + Strict minimum Yes + Oui
Unit testing + Tests unitaires Occasionally + Occasionnellement Yes + Oui
Integration testing + Tests d'intégration Occasionally + Occasionnellement Yes + Oui
Penetration testing + Tests d'intrusion Bare minimum + Strict minimum Yes + Oui
Tool support + Prise en charge par les outils Bare minimum + Strict minimum Yes + Oui
Secure Supply Chain + Chaîne d'approvisionnement sécurisée Occasionally + Occasionnellement Yes + Oui
+Nous encourageons toute personne souhaitant adopter une norme de sécurité des applications à utiliser [l'OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) (ASVS), qui est conçu pour être vérifiable et testable et peut être utilisé à toutes les étapes d'un cycle de développement sécurisé. -We would encourage anyone wanting to adopt an application security standard to use the [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) (ASVS), as it’s designed to be verifiable and tested, and can be used in all parts of a secure development lifecycle. - -The ASVS is the only acceptable choice for tool vendors. Tools cannot comprehensively detect, test, or protect against the OWASP Top 10 due to the nature of several of the OWASP Top 10 risks, with reference to [A06:2025-Insecure Design](A06_2025-Insecure_Design.md). OWASP discourages any claims of full coverage of the OWASP Top 10, because it’s simply untrue. +L'ASVS est le seul choix acceptable pour les éditeurs d'outils. En raison de la nature de plusieurs risques du Top 10 de l'OWASP, les outils ne peuvent pas détecter, tester ou protéger de manière exhaustive contre le Top 10, notamment [A06:2025 - Conception non sécurisée](A06_2025-Insecure_Design.md). L'OWASP déconseille toute affirmation de couverture complète du Top 10, car elle serait tout simplement fausse. diff --git a/2025/docs/fr/A01_2025-Broken_Access_Control.md b/2025/docs/fr/A01_2025-Broken_Access_Control.md index 575192150..54d532646 100644 --- a/2025/docs/fr/A01_2025-Broken_Access_Control.md +++ b/2025/docs/fr/A01_2025-Broken_Access_Control.md @@ -1,34 +1,30 @@ -# A01:2025 Broken Access Control ![icon](../assets/TOP_10_Icons_Final_Broken_Access_Control.png){: style="height:80px;width:80px" align="right"} +# A01:2025 Contrôles d'accès défaillants ![icône](../assets/TOP_10_Icons_Final_Broken_Access_Control.png){: style="height:80px;width:80px" align="right"} +## Contexte +Conservant sa première place dans le Top 10, 100 % des applications testées présentaient une forme quelconque de contrôle d'accès défaillant. Parmi les CWE notables figurent *CWE-200 : Exposition d'informations sensibles à un acteur non autorisé*, *CWE-201 : Exposition d'informations sensibles par les données envoyées*, *CWE-918 : Falsification de requête côté serveur (SSRF)* et *CWE-352 : Falsification de requête intersites (CSRF)*. Cette catégorie présente le plus grand nombre d'occurrences dans les données communiquées et le deuxième plus grand nombre de CVE associés. -## Background. - -Maintaining its position at #1 in the Top Ten, 100% of the applications tested were found to have some form of broken access control. Notable CWEs included are *CWE-200: Exposure of Sensitive Information to an Unauthorized Actor*, *CWE-201: Exposure of Sensitive Information Through Sent Data*, *CWE-918 Server-Side Request Forgery (SSRF)*, and *CWE-352: Cross-Site Request Forgery (CSRF)*. This category has the highest number of occurrences in the contributed data, and second highest number of related CVEs. - - -## Score table. - +## Tableau des scores - - - - - - - - - @@ -53,172 +49,115 @@ Maintaining its position at #1 in the Top Ten, 100% of the applications tested w
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+## Description +Le contrôle d'accès applique une politique empêchant les utilisateurs d'agir au-delà des permissions qui leur sont destinées. Les défaillances entraînent généralement la divulgation, la modification ou la destruction non autorisée de tout ou partie des données, ou l'exécution d'une fonction métier au-delà des limites de l'utilisateur. Les vulnérabilités courantes de contrôle d'accès comprennent notamment : -## Description. - -Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside the user's limits. Common access control vulnerabilities include: - - - -* Violation of the principle of least privilege, commonly known as deny by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone. -* Bypassing access control checks by modifying the URL (parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool that modifies API requests. -* Permitting viewing or editing someone else's account by providing its unique identifier (insecure direct object references) -* An accessible API with missing access controls for POST, PUT, and DELETE. -* Elevation of privilege. Acting as a user without being logged in or or gaining privileges beyond those expected of the logged in user (e.g. admin access). -* Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation. -* CORS misconfiguration allows API access from unauthorized or untrusted origins. -* Force browsing (guessing URLs) to authenticated pages as an unauthenticated user or to privileged pages as a standard user. - +* la violation du principe du moindre privilège, aussi appelée refus par défaut : l'accès devrait être accordé uniquement pour certaines fonctionnalités, certains rôles ou certains utilisateurs, mais il est disponible pour tout le monde ; +* le contournement des vérifications de contrôle d'accès par modification de l'URL (altération des paramètres ou navigation forcée), de l'état interne de l'application ou de la page HTML, ou par l'utilisation d'un outil d'attaque qui modifie les requêtes d'API ; +* la possibilité de consulter ou de modifier le compte d'une autre personne en fournissant son identifiant unique (références directes d'objets non sécurisées) ; +* une API accessible sans contrôles d'accès pour les méthodes POST, PUT et DELETE ; +* l'élévation de privilèges : agir en tant qu'utilisateur sans être connecté, ou obtenir des privilèges supérieurs à ceux attendus pour l'utilisateur connecté (par exemple un accès administrateur) ; +* la manipulation des métadonnées, par exemple la relecture ou l'altération d'un jeton de contrôle d'accès JSON Web Token (JWT), la modification d'un cookie ou d'un champ masqué pour élever les privilèges, ou l'exploitation de l'invalidation des JWT ; +* une mauvaise configuration de CORS autorisant l'accès à l'API depuis des origines non autorisées ou non fiables ; +* la navigation forcée (deviner des URL) vers des pages authentifiées en tant qu'utilisateur non authentifié, ou vers des pages privilégiées en tant qu'utilisateur standard. -## How to prevent. +## Comment s'en prémunir -Access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata. +Le contrôle d'accès n'est efficace que lorsqu'il est implémenté dans du code serveur de confiance ou dans des API serverless, où l'attaquant ne peut pas modifier la vérification du contrôle d'accès ni les métadonnées. +* À l'exception des ressources publiques, refuser l'accès par défaut. +* Implémenter les mécanismes de contrôle d'accès une seule fois et les réutiliser dans toute l'application, notamment en réduisant l'utilisation du partage de ressources entre origines (CORS). +* Les modèles de contrôle d'accès doivent imposer la propriété des enregistrements plutôt que permettre aux utilisateurs de créer, lire, modifier ou supprimer n'importe quel enregistrement. +* Les exigences propres aux limites métier de l'application doivent être imposées par les modèles du domaine. +* Désactiver l'énumération des répertoires du serveur web et vérifier que les métadonnées de fichiers (par exemple `.git`) et les fichiers de sauvegarde ne sont pas présents dans les racines web. +* Journaliser les échecs de contrôle d'accès et alerter les administrateurs lorsque cela est pertinent (par exemple en cas d'échecs répétés). +* Mettre en place une limitation du débit des accès aux API et aux contrôleurs afin de réduire les dommages causés par les outils d'attaque automatisés. +* Les identifiants de session avec état doivent être invalidés côté serveur après la déconnexion. Les jetons JWT sans état doivent avoir une durée de vie courte afin de réduire la fenêtre d'opportunité d'un attaquant. Pour les JWT de plus longue durée, envisager d'utiliser des jetons d'actualisation et de suivre les normes OAuth pour révoquer l'accès. +* Utiliser des boîtes à outils ou des modèles éprouvés qui fournissent des contrôles d'accès simples et déclaratifs. +Les développeurs et le personnel chargé de l'assurance qualité doivent inclure le contrôle d'accès fonctionnel dans leurs tests unitaires et d'intégration. -* Except for public resources, deny by default. -* Implement access control mechanisms once and reuse them throughout the application, including minimizing Cross-Origin Resource Sharing (CORS) usage. -* Model access controls should enforce record ownership rather than allowing users to create, read, update, or delete any record. -* Unique application business limit requirements should be enforced by domain models. -* Disable web server directory listing and ensure file metadata (e.g., .git) and backup files are not present within web roots. -* Log access control failures, alert admins when appropriate (e.g., repeated failures). -* Implement rate limits on API and controller access to minimize the harm from automated attack tooling. -* Stateful session identifiers should be invalidated on the server after logout. Stateless JWT tokens should be short-lived to minimize the window of opportunity for an attacker. For longer-lived JWTs, consider using refresh tokens and following OAuth standards to revoke access. -* Use well-established toolkits or patterns that provide simple, declarative access controls. - -Developers and QA staff should include functional access control in their unit and integration tests. - - -## Example attack scenarios. - -**Scenario #1:** The application uses unverified data in an SQL call that is accessing account information: +## Exemples de scénarios d'attaque +**Scénario n° 1 :** l'application utilise des données non vérifiées dans un appel SQL qui accède aux informations d'un compte : ``` pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); ``` - -An attacker can simply modify the browser's 'acct' parameter to send any desired account number. If not correctly verified, the attacker can access any user's account. - +Un attaquant peut simplement modifier le paramètre `acct` du navigateur pour envoyer le numéro de compte de son choix. S'il n'est pas correctement vérifié, l'attaquant peut accéder au compte de n'importe quel utilisateur. ``` https://example.com/app/accountInfo?acct=notmyacct ``` - -**Scenario #2:** An attacker simply forces browsers to target URLs. Admin rights are required for access to the admin page. - +**Scénario n° 2 :** un attaquant force simplement les navigateurs à cibler des URL. L'accès à la page d'administration nécessite des droits d'administrateur. ``` https://example.com/app/getappInfo https://example.com/app/admin_getappInfo ``` +Si un utilisateur non authentifié peut accéder à l'une ou l'autre de ces pages, il s'agit d'une faille. Si un utilisateur qui n'est pas administrateur peut accéder à la page d'administration, il s'agit également d'une faille. -If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the admin page, this is a flaw. - -**Scenario #3:** An application puts all of their access control in their front-end. While the attacker cannot get to `https://example.com/app/admin_getappInfo` due to JavaScript code running in the browser, they can simply execute: - +**Scénario n° 3 :** une application place tous ses contrôles d'accès dans son interface frontale. Même si l'attaquant ne peut pas accéder à `https://example.com/app/admin_getappInfo` en raison du code JavaScript exécuté dans le navigateur, il peut exécuter simplement : ``` $ curl https://example.com/app/admin_getappInfo ``` - -from the command line. - - -## References. - -* [OWASP Proactive Controls: C1: Implement Access Control](https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/) -* [OWASP Application Security Verification Standard: V8 Authorization](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) -* [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) -* [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) -* [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) -* [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) - - -## List of Mapped CWEs - -* [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) - -* [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) - -* [CWE-36 Absolute Path Traversal](https://cwe.mitre.org/data/definitions/36.html) - -* [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) - -* [CWE-61 UNIX Symbolic Link (Symlink) Following](https://cwe.mitre.org/data/definitions/61.html) - -* [CWE-65 Windows Hard Link](https://cwe.mitre.org/data/definitions/65.html) - -* [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) - -* [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) - -* [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) - -* [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) - -* [CWE-281 Improper Preservation of Permissions](https://cwe.mitre.org/data/definitions/281.html) - -* [CWE-282 Improper Ownership Management](https://cwe.mitre.org/data/definitions/282.html) - -* [CWE-283 Unverified Ownership](https://cwe.mitre.org/data/definitions/283.html) - -* [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) - -* [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) - -* [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) - -* [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) - -* [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) - -* [CWE-379 Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -* [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) - -* [CWE-424 Improper Protection of Alternate Path](https://cwe.mitre.org/data/definitions/424.html) - -* [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) - -* [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) - -* [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) - -* [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) - -* [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) - -* [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) - -* [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) - -* [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) - -* [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) - -* [CWE-615 Inclusion of Sensitive Information in Source Code Comments](https://cwe.mitre.org/data/definitions/615.html) - -* [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) - -* [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) - -* [CWE-732 Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html) - -* [CWE-749 Exposed Dangerous Method or Function](https://cwe.mitre.org/data/definitions/749.html) - -* [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) - -* [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) - -* [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) - -* [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) - -* [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) +depuis la ligne de commande. + +## Références + +* [Contrôles proactifs OWASP : C1 : implémenter le contrôle d'accès](https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/) +* [OWASP Application Security Verification Standard : V8 Autorisation](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) +* [Guide de test OWASP : tests d'autorisation](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) +* [Aide-mémoire OWASP : autorisation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) +* [PortSwigger : exploiter une mauvaise configuration de CORS](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) +* [OAuth : révoquer l'accès](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) + +## Liste des CWE associées + +* [CWE-22 Limitation incorrecte d'un nom de chemin vers un répertoire restreint (« traversée de chemin »)](https://cwe.mitre.org/data/definitions/22.html) +* [CWE-23 Traversée de chemin relative](https://cwe.mitre.org/data/definitions/23.html) +* [CWE-36 Traversée de chemin absolue](https://cwe.mitre.org/data/definitions/36.html) +* [CWE-59 Résolution incorrecte d'un lien avant l'accès au fichier (« suivi de lien »)](https://cwe.mitre.org/data/definitions/59.html) +* [CWE-61 Suivi d'un lien symbolique (symlink) UNIX](https://cwe.mitre.org/data/definitions/61.html) +* [CWE-65 Lien physique Windows](https://cwe.mitre.org/data/definitions/65.html) +* [CWE-200 Exposition d'informations sensibles à un acteur non autorisé](https://cwe.mitre.org/data/definitions/200.html) +* [CWE-201 Exposition d'informations sensibles par les données envoyées](https://cwe.mitre.org/data/definitions/201.html) +* [CWE-219 Stockage d'un fichier contenant des données sensibles sous la racine web](https://cwe.mitre.org/data/definitions/219.html) +* [CWE-276 Permissions par défaut incorrectes](https://cwe.mitre.org/data/definitions/276.html) +* [CWE-281 Conservation incorrecte des permissions](https://cwe.mitre.org/data/definitions/281.html) +* [CWE-282 Gestion incorrecte de la propriété](https://cwe.mitre.org/data/definitions/282.html) +* [CWE-283 Propriété non vérifiée](https://cwe.mitre.org/data/definitions/283.html) +* [CWE-284 Contrôle d'accès incorrect](https://cwe.mitre.org/data/definitions/284.html) +* [CWE-285 Autorisation incorrecte](https://cwe.mitre.org/data/definitions/285.html) +* [CWE-352 Falsification de requête intersites (CSRF)](https://cwe.mitre.org/data/definitions/352.html) +* [CWE-359 Exposition d'informations personnelles privées à un acteur non autorisé](https://cwe.mitre.org/data/definitions/359.html) +* [CWE-377 Fichier temporaire non sécurisé](https://cwe.mitre.org/data/definitions/377.html) +* [CWE-379 Création d'un fichier temporaire dans un répertoire aux permissions non sécurisées](https://cwe.mitre.org/data/definitions/379.html) +* [CWE-402 Transmission de ressources privées vers un nouvel espace (« fuite de ressource »)](https://cwe.mitre.org/data/definitions/402.html) +* [CWE-424 Protection incorrecte d'un chemin alternatif](https://cwe.mitre.org/data/definitions/424.html) +* [CWE-425 Requête directe (« navigation forcée »)](https://cwe.mitre.org/data/definitions/425.html) +* [CWE-441 Utilisation involontaire d'un proxy ou d'un intermédiaire (« adjoint confus »)](https://cwe.mitre.org/data/definitions/441.html) +* [CWE-497 Exposition d'informations sensibles sur le système à une sphère de contrôle non autorisée](https://cwe.mitre.org/data/definitions/497.html) +* [CWE-538 Insertion d'informations sensibles dans un fichier ou répertoire accessible de l'extérieur](https://cwe.mitre.org/data/definitions/538.html) +* [CWE-540 Inclusion d'informations sensibles dans le code source](https://cwe.mitre.org/data/definitions/540.html) +* [CWE-548 Exposition d'informations par l'énumération d'un répertoire](https://cwe.mitre.org/data/definitions/548.html) +* [CWE-552 Fichiers ou répertoires accessibles à des parties externes](https://cwe.mitre.org/data/definitions/552.html) +* [CWE-566 Contournement de l'autorisation par une clé primaire SQL contrôlée par l'utilisateur](https://cwe.mitre.org/data/definitions/566.html) +* [CWE-601 Redirection d'URL vers un site non fiable (« redirection ouverte »)](https://cwe.mitre.org/data/definitions/601.html) +* [CWE-615 Inclusion d'informations sensibles dans des commentaires du code source](https://cwe.mitre.org/data/definitions/615.html) +* [CWE-639 Contournement de l'autorisation par une clé contrôlée par l'utilisateur](https://cwe.mitre.org/data/definitions/639.html) +* [CWE-668 Exposition d'une ressource au mauvais espace](https://cwe.mitre.org/data/definitions/668.html) +* [CWE-732 Attribution incorrecte d'une permission à une ressource critique](https://cwe.mitre.org/data/definitions/732.html) +* [CWE-749 Méthode ou fonction dangereuse exposée](https://cwe.mitre.org/data/definitions/749.html) +* [CWE-862 Autorisation manquante](https://cwe.mitre.org/data/definitions/862.html) +* [CWE-863 Autorisation incorrecte](https://cwe.mitre.org/data/definitions/863.html) +* [CWE-918 Falsification de requête côté serveur (SSRF)](https://cwe.mitre.org/data/definitions/918.html) +* [CWE-922 Stockage non sécurisé d'informations sensibles](https://cwe.mitre.org/data/definitions/922.html) +* [CWE-1275 Cookie sensible avec attribut SameSite incorrect](https://cwe.mitre.org/data/definitions/1275.html) diff --git a/2025/docs/fr/A02_2025-Security_Misconfiguration.md b/2025/docs/fr/A02_2025-Security_Misconfiguration.md index 9dfcf4d17..0b4e8b511 100644 --- a/2025/docs/fr/A02_2025-Security_Misconfiguration.md +++ b/2025/docs/fr/A02_2025-Security_Misconfiguration.md @@ -1,33 +1,30 @@ -# A02:2025 Security Misconfiguration ![icon](../assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} +# A02:2025 Mauvaise configuration de sécurité ![icône](../assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} +## Contexte -## Background. - -Moving up from #5 in the previous edition, 100% of the applications tested were found to have some form of misconfiguration, with an average incidence rate of 3.00%, and over 719k occurrences of a Common Weakness Enumeration (CWE) in this risk category. With more shifts into highly configurable software, it's not surprising to see this category moving up. Notable CWEs included are *CWE-16 Configuration* and *CWE-611 Improper Restriction of XML External Entity Reference (XXE)*. - - -## Score table. +Passant de la 5e place dans l'édition précédente à la 2e place, 100 % des applications testées présentaient une forme quelconque de mauvaise configuration, avec un taux d'incidence moyen de 3,00 % et plus de 719 000 occurrences d'une CWE dans cette catégorie de risque. Alors que les logiciels deviennent de plus en plus configurables, il n'est pas surprenant de voir cette catégorie progresser. Parmi les CWE notables figurent *CWE-16 : Configuration* et *CWE-611 : Restriction incorrecte d'une référence à une entité externe XML (XXE)*. +## Tableau des scores - - - - - - - - - @@ -52,96 +49,72 @@ Moving up from #5 in the previous edition, 100% of the applications tested were
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+## Description +Une mauvaise configuration de sécurité signifie qu'un système, une application ou un service cloud est configuré incorrectement du point de vue de la sécurité, ce qui crée des vulnérabilités. -## Description. - -Security misconfiguration is when a system, application, or cloud service is set up incorrectly from a security perspective, creating vulnerabilities. - -The application might be vulnerable if: - - - -* It is missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services. -* Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, testing frameworks, or privileges). -* Default accounts and their passwords are still enabled and unchanged. -* A lack of central configuration for intercepting excessive error messages. Error handling reveals stack traces or other overly informative error messages to users. -* For upgraded systems, the latest security features are disabled or not configured securely. -* Excessive prioritization of backward compatibility leading to insecure configuration. -* The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values. -* The server does not send security headers or directives, or they are not set to secure values. - -Without a concerted, repeatable application security configuration hardening process, systems are at a higher risk. - - -## How to prevent. - -Secure installation processes should be implemented, including: - - +L'application peut être vulnérable si : -* A repeatable hardening process enabling the fast and easy deployment of another environment that is appropriately locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to set up a new secure environment. -* A minimal platform without any unnecessary features, components, documentation, or samples. Remove or do not install unused features and frameworks. -* A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process (see [A03 Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md)). Review cloud storage permissions (e.g., S3 bucket permissions). -* A segmented application architecture provides effective and secure separation between components or tenants, with segmentation, containerization, or cloud security groups (ACLs). -* Sending security directives to clients, e.g., Security Headers. -* An automated process to verify the effectiveness of the configurations and settings in all environments. -* Proactively add a central configuration to intercept excessive error messages as a backup. -* If these verifications are not automated, they should be manually verified annually at a minimum. -* Use identity federation, short-lived credentials, or role-based access mechanisms provided by the underlying platform instead of embedding static keys or secrets in code, configuration files, or pipelines. +* le renforcement de sécurité approprié fait défaut sur une partie quelconque de la pile applicative, ou si les permissions des services cloud sont mal configurées ; +* des fonctionnalités inutiles sont activées ou installées (par exemple des ports, services, pages, comptes, frameworks de test ou privilèges inutiles) ; +* les comptes par défaut et leurs mots de passe sont toujours activés et inchangés ; +* il n'existe pas de configuration centralisée pour intercepter les messages d'erreur excessifs. La gestion des erreurs révèle alors des traces de pile ou des messages trop informatifs aux utilisateurs ; +* pour les systèmes mis à niveau, les dernières fonctionnalités de sécurité sont désactivées ou ne sont pas configurées de manière sécurisée ; +* la compatibilité ascendante est privilégiée à l'excès, ce qui conduit à une configuration non sécurisée ; +* les paramètres de sécurité des serveurs d'applications, frameworks applicatifs (par exemple Struts, Spring, ASP.NET), bibliothèques, bases de données, etc. ne sont pas définis sur des valeurs sécurisées ; +* le serveur n'envoie pas d'en-têtes ou de directives de sécurité, ou ceux-ci ne sont pas définis sur des valeurs sécurisées. +Sans processus concerté et reproductible de renforcement de la configuration de sécurité des applications, les systèmes sont davantage exposés aux risques. -## Example attack scenarios. +## Comment s'en prémunir -**Scenario #1:** The application server comes with sample applications not removed from the production server. These sample applications have known security flaws that attackers use to compromise the server. Suppose one of these applications is the admin console, and default accounts weren't changed. In that case, the attacker logs in with the default password and takes over. +Des processus d'installation sécurisés doivent être mis en place, notamment : -**Scenario #2:** Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a severe access control flaw in the application. +* un processus de renforcement reproductible permettant de déployer rapidement et facilement un autre environnement correctement verrouillé. Les environnements de développement, d'assurance qualité et de production doivent tous être configurés de manière identique, avec des identifiants différents dans chaque environnement. Ce processus doit être automatisé afin de réduire l'effort nécessaire à la mise en place d'un nouvel environnement sécurisé ; +* une plateforme minimale sans fonctionnalité, composant, documentation ou exemple inutile. Supprimer ou ne pas installer les fonctionnalités et frameworks inutilisés ; +* une tâche de revue et de mise à jour des configurations liées à toutes les notes, mises à jour et correctifs de sécurité dans le cadre du processus de gestion des correctifs (voir [A03 :2025 - Défaillances de la chaîne d'approvisionnement logicielle](A03_2025-Software_Supply_Chain_Failures.md)). Vérifier les permissions du stockage cloud (par exemple celles d'un compartiment S3) ; +* une architecture applicative segmentée assurant une séparation efficace et sécurisée entre les composants ou les locataires, au moyen de la segmentation, de la conteneurisation ou de groupes de sécurité cloud (ACL) ; +* l'envoi de directives de sécurité aux clients, par exemple des en-têtes de sécurité ; +* un processus automatisé permettant de vérifier l'efficacité des configurations et des paramètres dans tous les environnements ; +* l'ajout proactif d'une configuration centralisée pour intercepter les messages d'erreur excessifs en secours ; +* si ces vérifications ne sont pas automatisées, une vérification manuelle au moins annuelle ; +* l'utilisation de la fédération d'identité, d'identifiants à courte durée de vie ou de mécanismes d'accès fondés sur les rôles fournis par la plateforme sous-jacente, plutôt que l'intégration de clés statiques ou de secrets dans le code, les fichiers de configuration ou les pipelines. -**Scenario #3:** The application server's configuration allows detailed error messages, such as stack traces to be returned to users. This potentially exposes sensitive information or underlying flaws, such as component versions that are known to be vulnerable. +## Exemples de scénarios d'attaque -**Scenario #4:** A cloud service provider (CSP) defaults to having sharing permissions open to the Internet. This allows sensitive data stored within cloud storage to be accessed. +**Scénario n° 1 :** le serveur d'application contient des applications d'exemple qui n'ont pas été supprimées du serveur de production. Ces applications d'exemple présentent des failles de sécurité connues que les attaquants utilisent pour compromettre le serveur. Supposons que l'une de ces applications soit la console d'administration et que les comptes par défaut n'aient pas été modifiés. L'attaquant se connecte alors avec le mot de passe par défaut et prend le contrôle du serveur. +**Scénario n° 2 :** l'énumération des répertoires n'est pas désactivée sur le serveur. Un attaquant découvre qu'il peut simplement lister les répertoires. Il trouve et télécharge les classes Java compilées, les décompile et en fait la rétro-ingénierie afin d'en examiner le code. Il découvre ensuite une grave faille de contrôle d'accès dans l'application. -## References. +**Scénario n° 3 :** la configuration du serveur d'application autorise le renvoi aux utilisateurs de messages d'erreur détaillés, tels que des traces de pile. Cela peut exposer des informations sensibles ou des faiblesses sous-jacentes, par exemple des versions de composants connues pour être vulnérables. -* [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) -* [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) -* [Application Security Verification Standard V13 Configuration](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V13-Configuration.md) -* [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) -* [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) -* [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) -* ScienceDirect: Security Misconfiguration +**Scénario n° 4 :** un fournisseur de services cloud (CSP) définit par défaut des permissions de partage ouvertes à Internet. Les données sensibles stockées dans le cloud peuvent ainsi être consultées. -## List of Mapped CWEs +## Références -* [CWE-5 J2EE Misconfiguration: Data Transmission Without Encryption](https://cwe.mitre.org/data/definitions/5.html) +* [Guide de test OWASP : gestion de la configuration](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) +* [Guide de test OWASP : tests des codes d'erreur](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) +* [Application Security Verification Standard V13 : configuration](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V13-Configuration.md) +* [Guide NIST sur le renforcement général des serveurs](https://csrc.nist.gov/publications/detail/sp/800-123/final) +* [Guides et référentiels de configuration de sécurité CIS](https://www.cisecurity.org/cis-benchmarks/) +* [Découverte et énumération des compartiments Amazon S3](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) +* ScienceDirect : mauvaise configuration de sécurité -* [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) - -* [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) - -* [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) +## Liste des CWE associées +* [CWE-5 Mauvaise configuration J2EE : transmission de données sans chiffrement](https://cwe.mitre.org/data/definitions/5.html) +* [CWE-11 Mauvaise configuration ASP.NET : création d'un binaire de débogage](https://cwe.mitre.org/data/definitions/11.html) +* [CWE-13 Mauvaise configuration ASP.NET : mot de passe dans un fichier de configuration](https://cwe.mitre.org/data/definitions/13.html) +* [CWE-15 Contrôle externe d'un paramètre système ou de configuration](https://cwe.mitre.org/data/definitions/15.html) * [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) - -* [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) - -* [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) - -* [CWE-489 Active Debug Code](https://cwe.mitre.org/data/definitions/489.html) - -* [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) - -* [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) - -* [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) - -* [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) - -* [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) - -* [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) - -* [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) - -* [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) +* [CWE-260 Mot de passe dans un fichier de configuration](https://cwe.mitre.org/data/definitions/260.html) +* [CWE-315 Stockage en clair d'informations sensibles dans un cookie](https://cwe.mitre.org/data/definitions/315.html) +* [CWE-489 Code actif de débogage](https://cwe.mitre.org/data/definitions/489.html) +* [CWE-526 Exposition d'informations sensibles par des variables d'environnement](https://cwe.mitre.org/data/definitions/526.html) +* [CWE-547 Utilisation de constantes codées en dur et pertinentes pour la sécurité](https://cwe.mitre.org/data/definitions/547.html) +* [CWE-611 Restriction incorrecte d'une référence à une entité externe XML](https://cwe.mitre.org/data/definitions/611.html) +* [CWE-614 Cookie sensible dans une session HTTPS sans attribut « Secure »](https://cwe.mitre.org/data/definitions/614.html) +* [CWE-776 Restriction incorrecte des références récursives d'entités dans les DTD (« expansion d'entité XML »)](https://cwe.mitre.org/data/definitions/776.html) +* [CWE-942 Politique inter-domaines permissive avec des domaines non fiables](https://cwe.mitre.org/data/definitions/942.html) +* [CWE-1004 Cookie sensible sans indicateur « HttpOnly »](https://cwe.mitre.org/data/definitions/1004.html) +* [CWE-1174 Mauvaise configuration ASP.NET : validation incorrecte du modèle](https://cwe.mitre.org/data/definitions/1174.html) diff --git a/2025/docs/fr/A03_2025-Software_Supply_Chain_Failures.md b/2025/docs/fr/A03_2025-Software_Supply_Chain_Failures.md index 25e70baac..761ae0bb4 100644 --- a/2025/docs/fr/A03_2025-Software_Supply_Chain_Failures.md +++ b/2025/docs/fr/A03_2025-Software_Supply_Chain_Failures.md @@ -1,33 +1,30 @@ -# A03:2025 Software Supply Chain Failures ![icon](../assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} +# A03:2025 Défaillances de la chaîne d'approvisionnement logicielle ![icône](../assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} +## Contexte -## Background. - -This was top-ranked in the Top 10 community survey with exactly 50% respondents ranking it #1. Since initially appearing in the 2013 Top 10 as "A9 – Using Components with Known Vulnerabilities", the risk has grown in scope to include all supply chain failures, not just ones involving known vulnerabilities. Despite this increased scope, supply chain failures continue to be a challenge to identify with only 11 Common Vulnerability and Exposures (CVEs) having the related CWEs. However, when tested and reported in the contributed data, this category has the highest average incidence rate at 5.19%. The relevant CWEs are *CWE-477: Use of Obsolete Function, CWE-1104: Use of Unmaintained Third Party Components*, CWE-1329: *Reliance on Component That is Not Updateable*, and *CWE-1395: Dependency on Vulnerable Third-Party Component*. - - -## Score table. +Cette catégorie est arrivée en tête de l'enquête communautaire du Top 10 : exactement 50 % des répondants l'ont classée en première position. Depuis son apparition initiale dans le Top 10 2013 sous le nom « A9 – Utilisation de composants présentant des vulnérabilités connues », le risque s'est élargi pour inclure toutes les défaillances de la chaîne d'approvisionnement, et pas seulement celles liées à des vulnérabilités connues. Malgré ce périmètre élargi, les défaillances de la chaîne d'approvisionnement restent difficiles à identifier : seuls 11 identifiants d'expositions et de vulnérabilités communes (CVE) sont associés aux CWE correspondantes. En revanche, lorsqu'elle est testée et déclarée dans les données communiquées, cette catégorie présente le taux d'incidence moyen le plus élevé, avec 5,19 %. Les CWE pertinentes sont *CWE-477 : Utilisation d'une fonction obsolète*, *CWE-1104 : Utilisation de composants tiers non maintenus*, *CWE-1329 : Dépendance à un composant qui ne peut pas être mis à jour* et *CWE-1395 : Dépendance à un composant tiers vulnérable*. +## Tableau des scores - - - - - - - - - @@ -52,123 +49,104 @@ This was top-ranked in the Top 10 community survey with exactly 50% respondents
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+## Description +Les défaillances de la chaîne d'approvisionnement logicielle sont des ruptures ou d'autres compromissions du processus de construction, de distribution ou de mise à jour des logiciels. Elles sont souvent causées par des vulnérabilités ou des modifications malveillantes du code, des outils ou d'autres dépendances tierces dont le système dépend. -## Description. - -Software supply chain failures are breakdowns or other compromises in the process of building, distributing, or updating software. They are often caused by vulnerabilities or malicious changes in third-party code, tools, or other dependencies that the system relies on. - -You are likely vulnerable if: - -* you do not carefully track the versions of all components that you use (both client-side and server-side). This includes components you directly use as well as nested (transitive) dependencies. -* the software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries. -* you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use. -* you do not have a change management process or tracking of changes within your supply chain, including tracking IDEs, IDE extensions and updates, changes to your organization's code repository, sandboxes, image and library repositories, the way artifacts are created and stored, etc. Every part of your supply chain should be documented, especially changes. -* you have not hardened every part of your supply chain, with a special focus on access control and the application of least privilege. -* your supply chain systems do not have any separation of duty. No single person should be able to write code and promote it all the way to production without oversight from another human being. -* components from untrusted sources, across any part of the tech stack, are used in or can impact on production environments. -* you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, leaving organizations open to days or months of unnecessary exposure before fixing vulnerabilities. -* software developers do not test the compatibility of updated, upgraded, or patched libraries. -* you do not secure the configurations of every part of your system (see [A02:2025-Security Misconfiguration](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/)). -* your CI/CD pipeline has weaker security than the systems it builds and deploys, especially if it is complex. - - -## How to prevent. - -There should be a patch management process in place to: - - - -* Centrally generate and manage the Software Bill of Materials (SBOM) of your entire software. -* Track not just your direct dependencies, but their (transitive) dependencies, and so on. -* Reduce attack surface by removing unused dependencies, unnecessary features, components, files, and documentation. -* Continuously inventory the versions of both client-side and server-side components (e.g., frameworks, libraries) and their dependencies using tools like OWASP Dependency Track, OWASP Dependency Check, retire.js, etc. -* Continuously monitor sources like Common Vulnerability and Exposures (CVE), National Vulnerability Database (NVD), and [Open Source Vulnerabilities (OSV)](https://osv.dev/) for vulnerabilities in the components you use. Use software composition analysis, software supply chain, or security-focused SBOM tools to automate the process. Subscribe to alerts for security vulnerabilities related to components you use. -* Only obtain components from official (trusted) sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component (see [A08:2025-Software and Data Integrity Failures](https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/)). -* Deliberately choose which version of a dependency you use and upgrade only when there is need. -* Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider migrating to an alternative. If that is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue. -* Update your CI/CD, IDE, and any other developer tooling regularly -* Avoid deploying updates to all systems simultaneously. Use staged rollouts or canary deployments to limit exposure in case a trusted vendor is compromised. +Vous êtes probablement vulnérable si : +* vous ne suivez pas attentivement les versions de tous les composants que vous utilisez, côté client comme côté serveur. Cela inclut les composants que vous utilisez directement ainsi que les dépendances imbriquées (transitives) ; +* le logiciel est vulnérable, n'est plus pris en charge ou n'est pas à jour. Cela concerne le système d'exploitation, le serveur web ou d'application, le système de gestion de base de données (SGBD), les applications, les API et tous les composants, environnements d'exécution et bibliothèques ; +* vous n'effectuez pas régulièrement d'analyse des vulnérabilités et ne vous abonnez pas aux bulletins de sécurité relatifs aux composants utilisés ; +* vous ne disposez pas d'un processus de gestion des changements ou d'un suivi des changements dans votre chaîne d'approvisionnement, notamment le suivi des IDE, de leurs extensions et de leurs mises à jour, des changements dans le dépôt de code de votre organisation, des environnements isolés, des dépôts d'images et de bibliothèques, de la manière dont les artefacts sont créés et stockés, etc. Chaque partie de votre chaîne d'approvisionnement doit être documentée, en particulier les changements ; +* vous n'avez pas renforcé chaque partie de votre chaîne d'approvisionnement, en accordant une attention particulière au contrôle d'accès et à l'application du principe du moindre privilège ; +* les systèmes de votre chaîne d'approvisionnement ne séparent pas les responsabilités. Une seule personne ne devrait pas pouvoir écrire du code et le promouvoir jusqu'en production sans supervision d'une autre personne ; +* des composants provenant de sources non fiables, quelle que soit la partie de la pile technologique concernée, sont utilisés dans les environnements de production ou peuvent les affecter ; +* vous ne corrigez pas ou ne mettez pas à niveau la plateforme sous-jacente, les frameworks et les dépendances de manière opportune et fondée sur le risque. Cela se produit souvent dans les environnements où l'application des correctifs est une tâche mensuelle ou trimestrielle soumise au contrôle des changements, laissant les organisations exposées inutilement pendant plusieurs jours ou plusieurs mois avant la correction des vulnérabilités ; +* les développeurs logiciels ne testent pas la compatibilité des bibliothèques mises à jour, mises à niveau ou corrigées ; +* vous ne sécurisez pas les configurations de chaque partie de votre système (voir [A02:2025 - Mauvaise configuration de sécurité](A02_2025-Security_Misconfiguration.md)) ; +* votre pipeline CI/CD est moins sécurisé que les systèmes qu'il construit et déploie, en particulier s'il est complexe. -There should be a change management process or tracking system in place to track changes to: +## Comment s'en prémunir -* CI/CD settings (all build tools and pipelines) -* Code repositories -* Sandbox areas -* Developer IDEs -* SBOM tooling, and created artifacts -* Logging systems and logs -* Third party integrations, such as SaaS -* Artifact repositories -* Container registries +Un processus de gestion des correctifs doit être en place afin de : +* générer et gérer de manière centralisée le Software Bill of Materials (SBOM) de l'ensemble de vos logiciels ; +* suivre non seulement vos dépendances directes, mais aussi leurs dépendances (transitives), et ainsi de suite ; +* réduire la surface d'attaque en supprimant les dépendances, fonctionnalités, composants, fichiers et documentations inutilisés ou superflus ; +* inventorier en continu les versions des composants côté client et côté serveur (par exemple frameworks et bibliothèques), ainsi que leurs dépendances, à l'aide d'outils tels qu'OWASP Dependency-Track, OWASP Dependency-Check, retire.js, etc. ; +* surveiller en continu des sources telles que les expositions et vulnérabilités communes (CVE), la National Vulnerability Database (NVD) et les [Open Source Vulnerabilities (OSV)](https://osv.dev/) pour détecter les vulnérabilités des composants utilisés. Utiliser l'analyse de composition logicielle, des outils de chaîne d'approvisionnement logicielle ou des outils SBOM dédiés à la sécurité pour automatiser le processus. S'abonner aux alertes relatives aux vulnérabilités des composants utilisés ; +* obtenir les composants uniquement auprès de sources officielles et fiables, via des liens sécurisés. Préférer les paquets signés afin de réduire le risque d'inclure un composant modifié et malveillant (voir [A08:2025 - Défaillances d'intégrité du logiciel ou des données](A08_2025-Software_or_Data_Integrity_Failures.md)) ; +* choisir délibérément la version utilisée d'une dépendance et ne la mettre à niveau que lorsque cela est nécessaire ; +* surveiller les bibliothèques et composants qui ne sont plus maintenus ou pour lesquels aucun correctif de sécurité n'est créé pour les anciennes versions. Si l'application de correctifs est impossible, envisager une migration vers une solution de remplacement. Si cela est impossible, envisager de déployer un correctif virtuel pour surveiller, détecter ou protéger contre le problème découvert ; +* mettre régulièrement à jour la CI/CD, les IDE et tous les autres outils destinés aux développeurs ; +* éviter de déployer les mises à jour sur tous les systèmes simultanément. Utiliser des déploiements progressifs ou canary afin de limiter l'exposition en cas de compromission d'un fournisseur de confiance. -Harden the following systems, which includes enabling MFA and locking down IAM: +Un processus de gestion des changements ou un système de suivi doit être en place pour suivre les changements apportés aux éléments suivants : -* Your code repository (which includes not checking in secrets, protecting branches, backups) -* Developer workstations (regular patching, MFA, monitoring, and more) -* Your build server & CI/CD (separation of duties, access control, signed builds, environment-scoped secrets, tamper-evident logs, more) -* Your artifacts (ensure integrity via provenance, signing, and time stamping, promote artifacts rather than rebuilding for each environment, ensure builds are immutable) -* Infrastructure as code (managed like all code, including use of PRs and version control) +* paramètres CI/CD (tous les outils de construction et pipelines) ; +* dépôts de code ; +* zones d'environnement isolé ; +* IDE des développeurs ; +* outils SBOM et artefacts créés ; +* systèmes de journalisation et journaux ; +* intégrations tierces, telles que les SaaS ; +* dépôts d'artefacts ; +* registres de conteneurs. -Every organization must ensure an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio. +Renforcez les systèmes suivants, notamment en activant l'authentification multifacteur et en verrouillant la gestion des identités et des accès (IAM) : +* votre dépôt de code (notamment en n'y enregistrant pas de secrets, en protégeant les branches et les sauvegardes) ; +* les postes de travail des développeurs (correctifs réguliers, MFA, surveillance, etc.) ; +* votre serveur de compilation et votre CI/CD (séparation des responsabilités, contrôle d'accès, compilations signées, secrets limités à l'environnement, journaux infalsifiables, etc.) ; +* vos artefacts (garantir leur intégrité par la provenance, la signature et l'horodatage, promouvoir les artefacts plutôt que les reconstruire pour chaque environnement, garantir l'immutabilité des compilations) ; +* l'infrastructure as code (gérée comme tout autre code, notamment au moyen de pull requests et du contrôle de version). -## Example attack scenarios. +Chaque organisation doit disposer d'un plan permanent de surveillance, de triage et d'application des mises à jour ou des changements de configuration pendant toute la durée de vie de l'application ou du portefeuille. -**Scenario #1:** A trusted vendor is compromised with malware, leading to your computer systems being compromised when you upgrade. The most famous example of this is probably: +## Exemples de scénarios d'attaque +**Scénario n° 1 :** un fournisseur de confiance est compromis par un logiciel malveillant, ce qui entraîne la compromission de vos systèmes informatiques lors de leur mise à niveau. L'exemple le plus célèbre est probablement : +* la compromission de SolarWinds en 2019, qui a entraîné la compromission d'environ 18 000 organisations. [https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) -* The 2019 SolarWinds compromise that led to ~18,000 organizations being compromised. [https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) +**Scénario n° 2 :** un fournisseur de confiance est compromis de manière à ne se comporter malicieusement que dans une condition particulière. -**Scenario #2:** A trusted vendor is compromised such that it behaves maliciously only under a specific condition. +* le vol de 1,5 milliard de dollars chez Bybit en 2025 a été causé par [une attaque de la chaîne d'approvisionnement du logiciel de portefeuille](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/) qui ne s'exécutait que lorsque le portefeuille cible était utilisé. +**Scénario n° 3 :** l'[attaque de la chaîne d'approvisionnement `Shai-Hulud`](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) en 2025 a été le premier ver npm auto-propagatif à réussir. Les attaques ont introduit des versions malveillantes de paquets populaires, qui utilisaient un script post-installation pour collecter et exfiltrer des données sensibles vers des dépôts GitHub publics. Le logiciel malveillant détectait également les jetons npm dans l'environnement de la victime et les utilisait automatiquement pour publier des versions malveillantes de tout paquet accessible. Le ver a atteint plus de 500 versions de paquets avant d'être neutralisé par npm. Cette attaque de la chaîne d'approvisionnement était avancée, se propageait rapidement et causait d'importants dommages ; en ciblant les machines des développeurs, elle a démontré que les développeurs eux-mêmes sont désormais des cibles privilégiées des attaques de la chaîne d'approvisionnement. +**Scénario n° 4 :** les composants s'exécutent généralement avec les mêmes privilèges que l'application elle-même ; les failles de n'importe quel composant peuvent donc avoir de graves conséquences. Ces failles peuvent être accidentelles (par exemple une erreur de programmation) ou intentionnelles (par exemple une porte dérobée dans un composant). Voici quelques exemples de vulnérabilités exploitables découvertes dans des composants : -* The 2025 Bybit theft of $1.5 billion was caused by [a supply chain attack in wallet software](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/) that only executed when the target wallet was being used. +* CVE-2017-5638, une vulnérabilité d'exécution de code à distance de Struts 2 permettant d'exécuter du code arbitraire sur le serveur, a été mise en cause dans d'importantes compromissions ; +* CVE-2021-44228 (« Log4Shell »), une vulnérabilité zero-day d'exécution de code à distance dans Apache Log4j, a été mise en cause dans des campagnes de rançongiciel, de cryptominage et d'autres attaques. -**Scenario #3:** The [`Shai-Hulud` supply chain attack](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) in 2025 was the first successful self-propagating npm worm. Attacks seeded malicious versions of popular packages, which used a post-install script to harvest and exfiltrate sensitive data to public GitHub repositories. The malware would also detect npm tokens in the victim environment, and automatically use them to push malicious versions of any accessible package. The worm reached over 500 package versions before being disrupted by npm. This supply chain attack was advanced, fast-spreading, and damaging, and by targeting developer machines it demonstrated developers themselves are now prime targets for supply chain attacks. +## Références -**Scenario #4:** Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g., coding error) or intentional (e.g., a backdoor in a component). Some example exploitable component vulnerabilities discovered are: - -* CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables the execution of arbitrary code on the server, has been blamed for significant breaches. -* CVE-2021-44228 ("Log4Shell"), an Apache Log4j remote code execution zero-day vulnerability, has been blamed for ransomware, cryptomining, and other attack campaigns. - - -## References - -* [OWASP Application Security Verification Standard: V15 Secure Coding and Architecture](https://owasp.org/www-project-application-security-verification-standard/) -* [OWASP Cheat Sheet Series: Dependency Graph SBOM](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) -* [OWASP Cheat Sheet Series: Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) +* [OWASP Application Security Verification Standard : V15 Codage et architecture sécurisés](https://owasp.org/www-project-application-security-verification-standard/) +* [Série d'aide-mémoire OWASP : graphe des dépendances et SBOM](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) +* [Série d'aide-mémoire OWASP : gestion des dépendances vulnérables](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) * [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) * [OWASP CycloneDX](https://owasp.org/www-project-cyclonedx/) -* [OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling](https://owasp-aasvs.readthedocs.io/en/latest/v1.html) -* [OWASP Dependency Check (for Java and .NET libraries)](https://owasp.org/www-project-dependency-check/) -* OWASP Testing Guide - Map Application Architecture (OTG-INFO-010) -* [OWASP Virtual Patching Best Practices](https://owasp.org/www-community/Virtual_Patching_Best_Practices) -* [The Unfortunate Reality of Insecure Libraries](https://www.scribd.com/document/105692739/JeffWilliamsPreso-Sm) -* [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cve.org) +* [OWASP Application Security Verification Standard : V1 Architecture, conception et modélisation des menaces](https://owasp-aasvs.readthedocs.io/en/latest/v1.html) +* [OWASP Dependency-Check (pour les bibliothèques Java et .NET)](https://owasp.org/www-project-dependency-check/) +* Guide de test OWASP - cartographier l'architecture de l'application (OTG-INFO-010) +* [Bonnes pratiques OWASP pour les correctifs virtuels](https://owasp.org/www-community/Virtual_Patching_Best_Practices) +* [La réalité malheureuse des bibliothèques non sécurisées](https://www.scribd.com/document/105692739/JeffWilliamsPreso-Sm) +* [Recherche MITRE des expositions et vulnérabilités communes (CVE)](https://www.cve.org) * [National Vulnerability Database (NVD)](https://nvd.nist.gov) -* [Retire.js for detecting known vulnerable JavaScript libraries](https://retirejs.github.io/retire.js/) -* [GitHub Advisory Database](https://github.com/advisories) -* Ruby Libraries Security Advisory Database and Tools -* [SAFECode Software Integrity Controls (PDF)](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) -* [Glassworm supply chain attack](https://thehackernews.com/2025/10/self-spreading-glassworm-infects-vs.html) -* [PhantomRaven supply chain attack campaign](https://thehackernews.com/2025/10/phantomraven-malware-found-in-126-npm.html) - - -## List of Mapped CWEs - -* [CWE-447 Use of Obsolete Function](https://cwe.mitre.org/data/definitions/447.html) - -* [CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities](https://cwe.mitre.org/data/definitions/1035.html) - -* [CWE-1104 Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html) - -* [CWE-1329 Reliance on Component That is Not Updateable](https://cwe.mitre.org/data/definitions/1329.html) - -* [CWE-1357 Reliance on Insufficiently Trustworthy Component](https://cwe.mitre.org/data/definitions/1357.html) - -* [CWE-1395 Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html) +* [Retire.js pour détecter les bibliothèques JavaScript vulnérables connues](https://retirejs.github.io/retire.js/) +* [Base de données des avis de sécurité GitHub](https://github.com/advisories) +* Base de données et outils d'avis de sécurité des bibliothèques Ruby +* [Contrôles d'intégrité logicielle SAFECode (PDF)](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [Attaque de la chaîne d'approvisionnement Glassworm](https://thehackernews.com/2025/10/self-spreading-glassworm-infects-vs.html) +* [Campagne d'attaque de la chaîne d'approvisionnement PhantomRaven](https://thehackernews.com/2025/10/phantomraven-malware-found-in-126-npm.html) + +## Liste des CWE associées + +* [CWE-447 Utilisation d'une fonction obsolète](https://cwe.mitre.org/data/definitions/447.html) +* [CWE-1035 A9 du Top 10 2017 : utilisation de composants présentant des vulnérabilités connues](https://cwe.mitre.org/data/definitions/1035.html) +* [CWE-1104 Utilisation de composants tiers non maintenus](https://cwe.mitre.org/data/definitions/1104.html) +* [CWE-1329 Dépendance à un composant qui ne peut pas être mis à jour](https://cwe.mitre.org/data/definitions/1329.html) +* [CWE-1357 Dépendance à un composant dont la fiabilité est insuffisante](https://cwe.mitre.org/data/definitions/1357.html) +* [CWE-1395 Dépendance à un composant tiers vulnérable](https://cwe.mitre.org/data/definitions/1395.html) diff --git a/2025/docs/fr/A04_2025-Cryptographic_Failures.md b/2025/docs/fr/A04_2025-Cryptographic_Failures.md index d81a20b8f..66cfd4a50 100644 --- a/2025/docs/fr/A04_2025-Cryptographic_Failures.md +++ b/2025/docs/fr/A04_2025-Cryptographic_Failures.md @@ -1,35 +1,30 @@ -# A04:2025 Cryptographic Failures ![icon](../assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} +# A04:2025 Défaillances cryptographiques ![icône](../assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} +## Contexte +Cette faiblesse recule de deux places, de la 2e à la 4e place. Elle porte sur les défaillances liées à l'absence de cryptographie, à une cryptographie insuffisamment robuste, à la fuite de clés cryptographiques et aux erreurs connexes. Trois des CWE les plus fréquentes de ce risque concernent l'utilisation d'un générateur pseudo-aléatoire faible : *CWE-327 : Utilisation d'un algorithme cryptographique compromis ou risqué*, *CWE-331 : Entropie insuffisante*, *CWE-1241 : Utilisation d'un algorithme prévisible dans un générateur de nombres aléatoires* et *CWE-338 : Utilisation d'un générateur pseudo-aléatoire cryptographiquement faible (PRNG)*. -## Background. - -Moving down two positions to #4, this weakness focuses on failures related to the lack of cryptography, insufficiently strong cryptography, leaking of cryptographic keys, and related errors. Three of the most common Common Weakness Enumerations (CWEs) in this risk involved the use of a weak pseudo-random number generator: *CWE-327 Use of a Broken or Risky Cryptographic Algorithm, CWE-331: Insufficient Entropy*, *CWE-1241: Use of Predictable Algorithm in Random Number Generator*, and *CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)*. - - - -## Score table. - +## Tableau des scores - - - - - - - - - @@ -54,142 +49,99 @@ Moving down two positions to #4, this weakness focuses on failures related to th
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
- - -## Description. - -Generally speaking, all data in transit should be encrypted at the [transport layer](https://en.wikipedia.org/wiki/Transport_layer) ([OSI layer](https://en.wikipedia.org/wiki/OSI_model) 4). Previous hurdles such as CPU performance and private key/certificate management are now handled by CPUs having instructions designed to accelerate encryption (eg: [AES support](https://en.wikipedia.org/wiki/AES_instruction_set)) and private key and certificate management being simplified by services like [LetsEncrypt.org](https://LetsEncrypt.org) with major cloud vendors providing even more tightly integrated certificate management services for their specific platforms. - -Beyond securing the transport layer, it is important to determine what data needs encryption at rest as well as what data needs extra encryption in transit (at the [application layer](https://en.wikipedia.org/wiki/Application_layer), OSI layer 7). For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, especially if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations such as PCI Data Security Standard (PCI DSS). For all such data: - - - -* Are any old or weak cryptographic algorithms or protocols used either by default or in older code? -* Are default crypto keys in use, are weak crypto keys generated, are keys re-used, or is proper key management and rotation missing? -* Are crypto keys checked into source code repositories? -* Is encryption not enforced, e.g., are any HTTP headers (browser) security directives or headers missing? -* Is the received server certificate and the trust chain properly validated? -* Are initialization vectors ignored, reused, or not generated sufficiently secure for the cryptographic mode of operation? Is an insecure mode of operation such as ECB in use? Is encryption used when authenticated encryption is more appropriate? -* Are passwords being used as cryptographic keys in the absence of a password based key derivation function? -* Is randomness used that was not designed to meet cryptographic requirements? Even if the correct function is chosen, does it need to be seeded by the developer, and if not, has the developer over-written the strong seeding functionality built into it with a seed that lacks sufficient entropy/unpredictability? -* Are deprecated hash functions such as MD5 or SHA1 in use, or are non-cryptographic hash functions used when cryptographic hash functions are needed? -* Are cryptographic error messages or side channel information exploitable, for example in the form of padding oracle attacks? -* Can the cryptographic algorithm be downgraded or bypassed? - -See references ASVS: Cryptography (V11), Secure Communication (V12) and Data Protection (V14). - - -## How to prevent. - -Do the following, at a minimum, and consult the references: - - - -* Classify and label data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs. -* Store your most sensitive keys in a hardware or cloud-based HSM. -* Use well-trusted implementations of cryptographic algorithms whenever possible. -* Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen. -* Make sure to encrypt all sensitive data at rest. -* Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management. -* Encrypt all data in transit with protocols >= TLS 1.2 only, with forward secrecy (FS) ciphers, drop support for cipher block chaining (CBC) ciphers, support quantum key change algorithms. For HTTPS enforce encryption using HTTP Strict Transport Security (HSTS). Check everything with a tool. -* Disable caching for responses that contain sensitive data. This includes caching in your CDN, web server, and any application caching (eg: Redis). -* Apply required security controls as per the data classification. -* Do not use unencrypted protocols such as FTP, and STARTTLS. Avoid using SMTP for transmitting confidential data. -* Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, yescrypt, scrypt or PBKDF2-HMAC-SHA-512. For legacy systems using bcrypt, get more advice at [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) -* Initialization vectors must be chosen appropriate for the mode of operation. This could mean using a CSPRNG (cryptographically secure pseudo random number generator). For modes that require a nonce, the initialization vector (IV) does not need a CSPRNG. In all cases, the IV should never be used twice for a fixed key. -* Always use authenticated encryption instead of just encryption. -* Keys should be generated cryptographically randomly and stored in memory as byte arrays. If a password is used, then it must be converted to a key via an appropriate password base key derivation function. -* Ensure that cryptographic randomness is used where appropriate and that it has not been seeded in a predictable way or with low entropy. Most modern APIs do not require the developer to seed the CSPRNG to be secure. -* Avoid deprecated cryptographic functions, block building methods and padding schemes, such as MD5, SHA1, Cipher Block Chaining Mode (CBC), PKCS number 1 v1.5. -* Ensure settings and configurations meet security requirements by having them reviewed by security specialists, tools designed for this purpose, or both. -* You need to prepare now for post quantum cryptography (PQC), see reference (ENISA) so that high risk systems are safe no later than the end of 2030. - - -## Example attack scenarios. - -**Scenario #1**: A site doesn't use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g., at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could alter all transported data, e.g., the recipient of a money transfer. - -**Scenario #2**: The password database uses unsalted or simple hashes to store everyone's passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted. - - -## References. - - - -* [OWASP Proactive Controls: C2: Use Cryptography to Protect Data ](https://top10proactive.owasp.org/archive/2024/the-top-10/c2-crypto/) -* [OWASP Application Security Verification Standard (ASVS): ](https://owasp.org/www-project-application-security-verification-standard) [V11,](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x20-V11-Cryptography.md) [12, ](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x21-V12-Secure-Communication.md) [14](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x23-V14-Data-Protection.md) -* [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) -* [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) -* [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) -* [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) -* [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) -* [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) -* [ENISA: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) -* [NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) - - -## List of Mapped CWEs - -* [CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) - -* [CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) - -* [CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) - -* [CWE-320 Key Management Errors (Prohibited)](https://cwe.mitre.org/data/definitions/320.html) - -* [CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) - -* [CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) - -* [CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) - -* [CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) - -* [CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) - -* [CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) - -* [CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) - -* [CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) - -* [CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) - -* [CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) - -* [CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) - -* [CWE-332 Insufficient Entropy in PRNG](https://cwe.mitre.org/data/definitions/332.html) - -* [CWE-334 Small Space of Random Values](https://cwe.mitre.org/data/definitions/334.html) - -* [CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) - -* [CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) - -* [CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) - -* [CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) - -* [CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) - -* [CWE-342 Predictable Exact Value from Previous Values](https://cwe.mitre.org/data/definitions/342.html) - -* [CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) - -* [CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) - -* [CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) - -* [CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) - -* [CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) - -* [CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) - -* [CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) - -* [CWE-1240 Use of a Cryptographic Primitive with a Risky Implementation](https://cwe.mitre.org/data/definitions/1240.html) - -* [CWE-1241 Use of Predictable Algorithm in Random Number Generator](https://cwe.mitre.org/data/definitions/1241.html) +## Description + +De manière générale, toutes les données en transit doivent être chiffrées au [niveau transport](https://en.wikipedia.org/wiki/Transport_layer) ( [couche OSI](https://en.wikipedia.org/wiki/OSI_model) 4). Les obstacles qui existaient auparavant, comme les performances des processeurs et la gestion des clés privées et des certificats, sont désormais pris en charge par des processeurs dotés d'instructions destinées à accélérer le chiffrement (par exemple la [prise en charge d'AES](https://en.wikipedia.org/wiki/AES_instruction_set)). La gestion des clés privées et des certificats a également été simplifiée par des services comme [LetsEncrypt.org](https://LetsEncrypt.org), les grands fournisseurs cloud proposant des services de gestion des certificats encore plus étroitement intégrés à leurs plateformes. + +Au-delà de la sécurisation de la couche transport, il est important de déterminer quelles données doivent être chiffrées au repos et quelles données nécessitent un chiffrement supplémentaire en transit (au [niveau applicatif](https://en.wikipedia.org/wiki/Application_layer), couche OSI 7). Par exemple, les mots de passe, numéros de carte bancaire, dossiers médicaux, informations personnelles et secrets métier nécessitent une protection supplémentaire, en particulier lorsque ces données relèvent de lois sur la protection de la vie privée, comme le Règlement général sur la protection des données de l'Union européenne (RGPD), ou de réglementations telles que la norme PCI Data Security Standard (PCI DSS). Pour toutes ces données, vérifiez les points suivants : + +* d'anciens algorithmes ou protocoles cryptographiques faibles sont-ils utilisés par défaut ou dans du code ancien ? +* des clés cryptographiques par défaut sont-elles utilisées, des clés faibles sont-elles générées, les clés sont-elles réutilisées ou la gestion et la rotation appropriées des clés font-elles défaut ? +* des clés cryptographiques sont-elles enregistrées dans les dépôts de code source ? +* le chiffrement n'est-il pas imposé, par exemple parce que des directives ou en-têtes de sécurité HTTP (navigateur) sont absents ? +* le certificat serveur reçu et la chaîne de confiance sont-ils correctement validés ? +* les vecteurs d'initialisation sont-ils ignorés, réutilisés ou générés avec une sécurité insuffisante pour le mode de fonctionnement cryptographique ? Un mode de fonctionnement non sécurisé comme ECB est-il utilisé ? Le chiffrement est-il utilisé alors qu'un chiffrement authentifié serait plus approprié ? +* des mots de passe sont-ils utilisés comme clés cryptographiques en l'absence d'une fonction de dérivation de clé fondée sur un mot de passe ? +* une source d'aléa qui n'a pas été conçue pour répondre aux exigences cryptographiques est-elle utilisée ? Même si la bonne fonction est choisie, doit-elle être initialisée par le développeur et, dans ce cas, celui-ci a-t-il remplacé la fonction d'initialisation robuste intégrée par une graine dépourvue d'entropie ou de prévisibilité suffisante ? +* des fonctions de hachage obsolètes comme MD5 ou SHA1 sont-elles utilisées, ou des fonctions de hachage non cryptographiques sont-elles employées alors que des fonctions de hachage cryptographiques sont nécessaires ? +* des messages d'erreur cryptographiques ou des informations de canal auxiliaire peuvent-ils être exploités, par exemple sous la forme d'attaques par oracle de bourrage ? +* l'algorithme cryptographique peut-il être rétrogradé ou contourné ? + +Voir les références ASVS : Cryptographie (V11), Communications sécurisées (V12) et Protection des données (V14). + +## Comment s'en prémunir + +Effectuez au minimum les opérations suivantes et consultez les références : + +* classer et étiqueter les données traitées, stockées ou transmises par une application. Identifier les données sensibles selon les lois sur la protection de la vie privée, les exigences réglementaires ou les besoins métier ; +* stocker les clés les plus sensibles dans un HSM matériel ou cloud ; +* utiliser autant que possible des implémentations d'algorithmes cryptographiques reconnues et fiables ; +* ne pas stocker inutilement les données sensibles. Les supprimer dès que possible ou utiliser une tokenisation conforme à PCI DSS, voire une troncature. Les données qui ne sont pas conservées ne peuvent pas être volées ; +* s'assurer que toutes les données sensibles au repos sont chiffrées ; +* s'assurer que des algorithmes, protocoles et clés standard robustes et à jour sont en place, et utiliser une gestion appropriée des clés ; +* chiffrer toutes les données en transit avec des protocoles version 1.2 ou ultérieure de TLS uniquement, avec des chiffrements assurant la confidentialité persistante (FS), abandonner les chiffrements à chaînage de blocs (CBC) et prendre en charge les algorithmes d'échange de clés post-quantiques. Pour HTTPS, imposer le chiffrement à l'aide de HTTP Strict Transport Security (HSTS). Vérifier l'ensemble avec un outil ; +* désactiver la mise en cache des réponses contenant des données sensibles. Cela inclut la mise en cache dans votre CDN, votre serveur web et tout cache applicatif (par exemple Redis) ; +* appliquer les contrôles de sécurité requis selon la classification des données ; +* ne pas utiliser de protocoles non chiffrés tels que FTP et STARTTLS. Éviter d'utiliser SMTP pour transmettre des données confidentielles ; +* stocker les mots de passe à l'aide de fonctions de hachage adaptatives et salées, robustes, avec un facteur de coût (facteur de délai), telles qu'Argon2, yescrypt, scrypt ou PBKDF2-HMAC-SHA-512. Pour les systèmes anciens utilisant bcrypt, consulter l'[aide-mémoire OWASP sur le stockage des mots de passe](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) ; +* choisir les vecteurs d'initialisation en fonction du mode de fonctionnement. Cela peut nécessiter un CSPRNG (générateur pseudo-aléatoire cryptographiquement sûr). Pour les modes qui nécessitent un nonce, le vecteur d'initialisation (IV) n'a pas besoin d'un CSPRNG. Dans tous les cas, l'IV ne doit jamais être utilisé deux fois pour une même clé ; +* toujours utiliser un chiffrement authentifié plutôt qu'un simple chiffrement ; +* générer les clés de manière cryptographiquement aléatoire et les stocker en mémoire sous forme de tableaux d'octets. Si un mot de passe est utilisé, il doit être converti en clé au moyen d'une fonction appropriée de dérivation de clé à partir d'un mot de passe ; +* s'assurer qu'une source d'aléa cryptographique est utilisée lorsque cela est approprié et qu'elle n'a pas été initialisée de manière prévisible ou avec une faible entropie. La plupart des API modernes n'exigent pas que le développeur initialise le CSPRNG pour qu'il soit sûr ; +* éviter les fonctions cryptographiques, méthodes de construction de blocs et schémas de bourrage obsolètes, tels que MD5, SHA1, le mode de chaînage de blocs (CBC) et PKCS n° 1 v1.5 ; +* s'assurer que les paramètres et configurations respectent les exigences de sécurité en les faisant examiner par des spécialistes de la sécurité, par des outils conçus à cet effet, ou par les deux ; +* se préparer dès maintenant à la cryptographie post-quantique (PQC) ; consulter la référence de l'ENISA afin que les systèmes à haut risque soient sûrs au plus tard à la fin de 2030. + +## Exemples de scénarios d'attaque + +**Scénario n° 1 :** un site n'utilise pas TLS pour toutes ses pages, ne l'impose pas ou prend en charge un chiffrement faible. Un attaquant surveille le trafic réseau (par exemple sur un réseau sans fil non sécurisé), rétrograde les connexions de HTTPS vers HTTP, intercepte les requêtes et vole le cookie de session de l'utilisateur. Il rejoue ensuite ce cookie et détourne la session (authentifiée) de l'utilisateur, ce qui lui permet d'accéder à ses données privées ou de les modifier. Au lieu de cela, il pourrait modifier toutes les données transportées, par exemple le destinataire d'un virement. + +**Scénario n° 2 :** la base de données des mots de passe utilise des hachages non salés ou simples pour stocker les mots de passe de tout le monde. Une faille de téléversement de fichier permet à un attaquant de récupérer la base de données des mots de passe. Tous les hachages non salés peuvent être retrouvés à l'aide d'une table arc-en-ciel de hachages précalculés. Les hachages produits par des fonctions simples ou rapides peuvent être cassés par des GPU, même lorsqu'ils sont salés. + +## Références + +* [Contrôles proactifs OWASP : C2 : utiliser la cryptographie pour protéger les données](https://top10proactive.owasp.org/archive/2024/the-top-10/c2-crypto/) +* [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard) : [V11](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x20-V11-Cryptography.md), [V12](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x21-V12-Secure-Communication.md), [V14](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x23-V14-Data-Protection.md) +* [Aide-mémoire OWASP : protection de la couche transport](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) +* [Aide-mémoire OWASP : protection de la vie privée des utilisateurs](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +* [Aide-mémoire OWASP : stockage des mots de passe](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [Aide-mémoire OWASP : stockage cryptographique](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [Aide-mémoire OWASP : HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) +* [Guide de test OWASP : tests de la cryptographie faible](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) +* [ENISA : feuille de route de mise en œuvre coordonnée pour la transition vers la cryptographie post-quantique](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) +* [La NIST publie les trois premières normes de chiffrement post-quantique finalisées](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) + +## Liste des CWE associées + +* [CWE-261 Encodage faible d'un mot de passe](https://cwe.mitre.org/data/definitions/261.html) +* [CWE-296 Suivi incorrect de la chaîne de confiance d'un certificat](https://cwe.mitre.org/data/definitions/296.html) +* [CWE-319 Transmission en clair d'informations sensibles](https://cwe.mitre.org/data/definitions/319.html) +* [CWE-320 Erreurs de gestion des clés (interdit)](https://cwe.mitre.org/data/definitions/320.html) +* [CWE-321 Utilisation d'une clé cryptographique codée en dur](https://cwe.mitre.org/data/definitions/321.html) +* [CWE-322 Échange de clés sans authentification de l'entité](https://cwe.mitre.org/data/definitions/322.html) +* [CWE-323 Réutilisation d'un nonce ou d'une paire de clés dans un chiffrement](https://cwe.mitre.org/data/definitions/323.html) +* [CWE-324 Utilisation d'une clé après sa date d'expiration](https://cwe.mitre.org/data/definitions/324.html) +* [CWE-325 Étape cryptographique requise manquante](https://cwe.mitre.org/data/definitions/325.html) +* [CWE-326 Robustesse de chiffrement insuffisante](https://cwe.mitre.org/data/definitions/326.html) +* [CWE-327 Utilisation d'un algorithme cryptographique compromis ou risqué](https://cwe.mitre.org/data/definitions/327.html) +* [CWE-328 Hachage à sens unique réversible](https://cwe.mitre.org/data/definitions/328.html) +* [CWE-329 Absence d'IV aléatoire avec le mode CBC](https://cwe.mitre.org/data/definitions/329.html) +* [CWE-330 Utilisation de valeurs insuffisamment aléatoires](https://cwe.mitre.org/data/definitions/330.html) +* [CWE-331 Entropie insuffisante](https://cwe.mitre.org/data/definitions/331.html) +* [CWE-332 Entropie insuffisante dans un PRNG](https://cwe.mitre.org/data/definitions/332.html) +* [CWE-334 Espace réduit de valeurs aléatoires](https://cwe.mitre.org/data/definitions/334.html) +* [CWE-335 Utilisation incorrecte des graines dans un générateur pseudo-aléatoire (PRNG)](https://cwe.mitre.org/data/definitions/335.html) +* [CWE-336 Même graine dans un générateur pseudo-aléatoire (PRNG)](https://cwe.mitre.org/data/definitions/336.html) +* [CWE-337 Graine prévisible dans un générateur pseudo-aléatoire (PRNG)](https://cwe.mitre.org/data/definitions/337.html) +* [CWE-338 Utilisation d'un générateur pseudo-aléatoire cryptographiquement faible (PRNG)](https://cwe.mitre.org/data/definitions/338.html) +* [CWE-340 Génération de nombres ou d'identifiants prévisibles](https://cwe.mitre.org/data/definitions/340.html) +* [CWE-342 Valeur exacte prévisible à partir de valeurs précédentes](https://cwe.mitre.org/data/definitions/342.html) +* [CWE-347 Vérification incorrecte d'une signature cryptographique](https://cwe.mitre.org/data/definitions/347.html) +* [CWE-523 Transport non protégé des identifiants](https://cwe.mitre.org/data/definitions/523.html) +* [CWE-757 Sélection d'un algorithme moins sécurisé lors de la négociation (« rétrogradation d'algorithme »)](https://cwe.mitre.org/data/definitions/757.html) +* [CWE-759 Utilisation d'un hachage à sens unique sans sel](https://cwe.mitre.org/data/definitions/759.html) +* [CWE-760 Utilisation d'un hachage à sens unique avec un sel prévisible](https://cwe.mitre.org/data/definitions/760.html) +* [CWE-780 Utilisation de l'algorithme RSA sans OAEP](https://cwe.mitre.org/data/definitions/780.html) +* [CWE-916 Utilisation d'un hachage de mot de passe avec un effort de calcul insuffisant](https://cwe.mitre.org/data/definitions/916.html) +* [CWE-1240 Utilisation d'une primitive cryptographique avec une implémentation risquée](https://cwe.mitre.org/data/definitions/1240.html) +* [CWE-1241 Utilisation d'un algorithme prévisible dans un générateur de nombres aléatoires](https://cwe.mitre.org/data/definitions/1241.html) diff --git a/2025/docs/fr/A05_2025-Injection.md b/2025/docs/fr/A05_2025-Injection.md index d72e4a3b4..bbf5116f2 100644 --- a/2025/docs/fr/A05_2025-Injection.md +++ b/2025/docs/fr/A05_2025-Injection.md @@ -1,32 +1,30 @@ -# A05:2025 Injection ![icon](../assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} +# A05:2025 Injection ![icône](../assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} -## Background. +## Contexte -Injection falls two spots from #3 to #5 in the ranking, maintaining its position relative to A04:2025-Cryptographic Failures and A06:2025-Insecure Design. Injection is one of the most tested categories with 100% of applications tested for some form of injection. It had the greatest number of CVEs for any category, with 37 CWEs in this category. Injection includes Cross-site Scripting (high frequency/low impact) with more than 30k CVEs and SQL Injection (low frequency/high impact) with more than 14k CVEs. The massive number of reported CVEs for CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') brings down the average weighted impact of this category. - - -## Score table. +L'injection recule de deux places, de la 3e à la 5e place, tout en conservant sa position relative à A04:2025 - Défaillances cryptographiques et A06:2025 - Conception non sécurisée. L'injection est l'une des catégories les plus testées : 100 % des applications testées l'ont été pour une forme quelconque d'injection. Elle possède le plus grand nombre de CVE de toutes les catégories, avec 37 CWE dans cette catégorie. L'injection comprend les scripts intersites (fréquence élevée et impact faible), avec plus de 30 000 CVE, et les injections SQL (fréquence faible et impact élevé), avec plus de 14 000 CVE. Le nombre très important de CVE signalés pour la CWE-79, Neutralisation incorrecte des entrées lors de la génération d'une page web (« scripts intersites »), fait baisser l'impact moyen pondéré de cette catégorie. +## Tableau des scores - - - - - - - - - @@ -51,159 +49,118 @@ Injection falls two spots from #3 to #5 in the ranking, maintaining its position
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+## Description +Une vulnérabilité d'injection est une faille applicative qui permet d'envoyer une entrée utilisateur non fiable à un interpréteur (par exemple un navigateur, une base de données ou la ligne de commande) et de faire exécuter par cet interpréteur une partie de cette entrée en tant que commandes. -## Description. - -An injection vulnerability is an application flaw that allows untrusted user input to be sent to an interpreter (e.g. a browser, database, the command line) and causes the interpreter to execute parts of that input as commands. +Une application est vulnérable aux attaques lorsque : -An application is vulnerable to attack when: +* les données fournies par l'utilisateur ne sont pas validées, filtrées ou nettoyées par l'application ; +* des requêtes dynamiques ou des appels non paramétrés, sans échappement adapté au contexte, sont utilisés directement dans l'interpréteur ; +* des données non nettoyées sont utilisées dans des paramètres de recherche d'un mapping objet-relationnel (ORM) pour extraire d'autres enregistrements sensibles ; +* des données potentiellement hostiles sont utilisées ou concaténées directement. La requête SQL ou la commande contient alors à la fois la structure et les données malveillantes dans des requêtes, commandes ou procédures stockées dynamiques. -* User-supplied data is not validated, filtered, or sanitized by the application. -* Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter. -* Unsanitized data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records. -* Potentially hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures. +Parmi les injections les plus courantes figurent les injections SQL, NoSQL, de commandes système, de mapping objet-relationnel (ORM), LDAP et de langage d'expression (EL) ou de bibliothèque de navigation dans les graphes d'objets (OGNL). Le concept est identique pour tous les interpréteurs. La détection est optimale lorsqu'elle combine la revue du code source et les tests automatisés (y compris le fuzzing) de tous les paramètres, en-têtes, URL, cookies et entrées de données JSON, SOAP et XML. L'ajout d'outils de test de sécurité des applications statiques (SAST), dynamiques (DAST) et interactifs (IAST) au pipeline CI/CD peut également aider à identifier les failles d'injection avant le déploiement en production. -Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Detection is best achieved by a combination of source code review along with automated testing (including fuzzing) of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs. The addition of static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline can also be helpful to identify injection flaws before production deployment. +Une catégorie apparentée de vulnérabilités d'injection est devenue courante dans les LLM. Elle est traitée séparément dans l'[OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/), plus précisément dans [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). -A related class of injection vulnerabilities has become common in LLMs. These are discussed separately in the [OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/), specifically [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). +## Comment s'en prémunir +Le meilleur moyen de prévenir les injections consiste à séparer les données des commandes et des requêtes : -## How to prevent. +* l'option privilégiée consiste à utiliser une API sûre qui évite entièrement l'interpréteur, fournit une interface paramétrée ou permet de migrer vers des outils de mapping objet-relationnel (ORM) ; +**Remarque :** même paramétrées, les procédures stockées peuvent toujours introduire une injection SQL si PL/SQL ou T-SQL concatène les requêtes et les données, ou exécute des données hostiles avec `EXECUTE IMMEDIATE` ou `exec()`. -The best means to prevent injection requires keeping data separate from commands and queries: +Lorsque la séparation des données et des commandes est impossible, vous pouvez réduire les risques avec les techniques suivantes : -* The preferred option is to use a safe API, which avoids using the interpreter entirely, provides a parameterized interface, or migrates to Object Relational Mapping Tools (ORMs). -**Note:** Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data or executes hostile data with EXECUTE IMMEDIATE or exec(). +* utiliser une validation positive des entrées côté serveur. Il ne s'agit pas d'une défense complète, car de nombreuses applications nécessitent des caractères spéciaux, notamment dans les zones de texte ou les API d'applications mobiles ; +* pour les requêtes dynamiques restantes, échapper les caractères spéciaux à l'aide de la syntaxe d'échappement propre à l'interpréteur concerné ; +**Remarque :** les structures SQL telles que les noms de tables, les noms de colonnes, etc. ne peuvent pas être échappées ; les noms de structures fournis par l'utilisateur sont donc dangereux. Il s'agit d'un problème fréquent dans les logiciels de génération de rapports. -When it is not possible to separate the data from commands, you can reduce threats using the following techniques. +**Avertissement :** ces techniques nécessitent d'analyser et d'échapper des chaînes complexes, ce qui les rend sujettes aux erreurs et peu robustes face aux changements mineurs du système sous-jacent. -* Use positive server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications. -* For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. -**Note:** SQL structures such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software. +## Exemples de scénarios d'attaque -**Warning** these techniques involve parsing and escaping complex strings, making them error-prone and not robust in the face of minor changes to the underlying system. - -## Example attack scenarios. - -**Scenario #1:** An application uses untrusted data in the construction of the following vulnerable SQL call: +**Scénario n° 1 :** une application utilise des données non fiables pour construire l'appel SQL vulnérable suivant : ``` String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; ``` -An attacker modifies the 'id' parameter value in their browser to send: `' OR '1'='1`. For example: +Un attaquant modifie dans son navigateur la valeur du paramètre `id` afin d'envoyer : `' OR '1'='1`. Par exemple : ``` http://example.com/app/accountView?id=' OR '1'='1 ``` -This changes the meaning of the query to return all records from the accounts table. More dangerous attacks could modify or delete data or even invoke stored procedures. +Cela modifie le sens de la requête, qui renvoie tous les enregistrements de la table des comptes. Des attaques plus dangereuses pourraient modifier ou supprimer des données, voire invoquer des procédures stockées. -**Scenario #2:** An application's blind trust in frameworks may result in queries that are still vulnerable. For example, Hibernate Query Language (HQL): +**Scénario n° 2 :** la confiance aveugle d'une application dans les frameworks peut entraîner des requêtes qui restent vulnérables. Par exemple, le langage de requête Hibernate (HQL) : ``` Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); ``` -An attacker supplies: `' OR custID IS NOT NULL OR custID='`. This bypasses the filter and returns all accounts. While HQL has fewer dangerous functions than raw SQL, it still allows unauthorized data access when user input is concatenated into queries. +Un attaquant fournit : `' OR custID IS NOT NULL OR custID='`. Il contourne ainsi le filtre et récupère tous les comptes. Même si HQL possède moins de fonctions dangereuses que le SQL brut, il permet toujours un accès non autorisé aux données lorsque l'entrée utilisateur est concaténée aux requêtes. -**Scenario #3:** An application passes user input directly to an OS command: +**Scénario n° 3 :** une application transmet directement une entrée utilisateur à une commande du système d'exploitation : ``` String cmd = "nslookup " + request.getParameter("domain"); Runtime.getRuntime().exec(cmd); ``` -An attacker supplies `example.com; cat /etc/passwd` to execute arbitrary commands on the server. - -## References. - -* [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) -* [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) -* [OWASP Testing Guide: SQL Injection,](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Command Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection), and [ORM Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) -* [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) -* [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) -* [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) -* [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) -* [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) -* [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) -* [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) - - - -## List of Mapped CWEs - -* [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) - -* [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) - -* [CWE-76 Improper Neutralization of Equivalent Special Elements](https://cwe.mitre.org/data/definitions/76.html) - -* [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) - -* [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) - -* [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) - -* [CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)](https://cwe.mitre.org/data/definitions/80.html) - -* [CWE-83 Improper Neutralization of Script in Attributes in a Web Page](https://cwe.mitre.org/data/definitions/83.html) - -* [CWE-86 Improper Neutralization of Invalid Characters in Identifiers in Web Pages](https://cwe.mitre.org/data/definitions/86.html) - -* [CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')](https://cwe.mitre.org/data/definitions/88.html) - -* [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) - -* [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) - -* [CWE-91 XML Injection (aka Blind XPath Injection)](https://cwe.mitre.org/data/definitions/91.html) - -* [CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) - -* [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) - -* [CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95.html) - -* [CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')](https://cwe.mitre.org/data/definitions/96.html) - -* [CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page](https://cwe.mitre.org/data/definitions/97.html) - -* [CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')](https://cwe.mitre.org/data/definitions/98.html) - -* [CWE-99 Improper Control of Resource Identifiers ('Resource Injection')](https://cwe.mitre.org/data/definitions/99.html) - -* [CWE-103 Struts: Incomplete validate() Method Definition](https://cwe.mitre.org/data/definitions/103.html) - -* [CWE-104 Struts: Form Bean Does Not Extend Validation Class](https://cwe.mitre.org/data/definitions/104.html) - -* [CWE-112 Missing XML Validation](https://cwe.mitre.org/data/definitions/112.html) - -* [CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')](https://cwe.mitre.org/data/definitions/113.html) - -* [CWE-114 Process Control](https://cwe.mitre.org/data/definitions/114.html) - -* [CWE-115 Misinterpretation of Output](https://cwe.mitre.org/data/definitions/115.html) - -* [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) - -* [CWE-129 Improper Validation of Array Index](https://cwe.mitre.org/data/definitions/129.html) - -* [CWE-159 Improper Handling of Invalid Use of Special Elements](https://cwe.mitre.org/data/definitions/159.html) - -* [CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')](https://cwe.mitre.org/data/definitions/470.html) - -* [CWE-493 Critical Public Variable Without Final Modifier](https://cwe.mitre.org/data/definitions/493.html) - -* [CWE-500 Public Static Field Not Marked Final](https://cwe.mitre.org/data/definitions/500.html) - -* [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) - -* [CWE-610 Externally Controlled Reference to a Resource in Another Sphere](https://cwe.mitre.org/data/definitions/610.html) - -* [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) - -* [CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax](https://cwe.mitre.org/data/definitions/644.html) - -* [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) +Un attaquant fournit `example.com; cat /etc/passwd` afin d'exécuter des commandes arbitraires sur le serveur. + +## Références + +* [Contrôles proactifs OWASP : accès sécurisé aux bases de données](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) +* [OWASP ASVS : V5 Validation et encodage des entrées](https://owasp.org/www-project-application-security-verification-standard) +* [Guide de test OWASP : injection SQL](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection), [injection de commandes](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection) et [injection ORM](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) +* [Aide-mémoire OWASP : prévention des injections](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) +* [Aide-mémoire OWASP : prévention des injections SQL](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) +* [Aide-mémoire OWASP : prévention des injections en Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) +* [Aide-mémoire OWASP : paramétrage des requêtes](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) +* [Menaces automatisées contre les applications web OWASP – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) +* [PortSwigger : injection de modèles côté serveur](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) +* [Awesome Fuzzing : liste de ressources de fuzzing](https://github.com/secfigo/Awesome-Fuzzing) + +## Liste des CWE associées + +* [CWE-20 Validation incorrecte des entrées](https://cwe.mitre.org/data/definitions/20.html) +* [CWE-74 Neutralisation incorrecte d'éléments spéciaux dans une sortie utilisée par un composant en aval (« injection »)](https://cwe.mitre.org/data/definitions/74.html) +* [CWE-76 Neutralisation incorrecte d'éléments spéciaux équivalents](https://cwe.mitre.org/data/definitions/76.html) +* [CWE-77 Neutralisation incorrecte d'éléments spéciaux utilisés dans une commande (« injection de commandes »)](https://cwe.mitre.org/data/definitions/77.html) +* [CWE-78 Neutralisation incorrecte d'éléments spéciaux utilisés dans une commande système (« injection de commandes système »)](https://cwe.mitre.org/data/definitions/78.html) +* [CWE-79 Neutralisation incorrecte des entrées lors de la génération d'une page web (« scripts intersites »)](https://cwe.mitre.org/data/definitions/79.html) +* [CWE-80 Neutralisation incorrecte des balises HTML liées aux scripts dans une page web (XSS de base)](https://cwe.mitre.org/data/definitions/80.html) +* [CWE-83 Neutralisation incorrecte d'un script dans les attributs d'une page web](https://cwe.mitre.org/data/definitions/83.html) +* [CWE-86 Neutralisation incorrecte de caractères invalides dans les identifiants des pages web](https://cwe.mitre.org/data/definitions/86.html) +* [CWE-88 Neutralisation incorrecte des séparateurs d'arguments dans une commande (« injection d'arguments »)](https://cwe.mitre.org/data/definitions/88.html) +* [CWE-89 Neutralisation incorrecte d'éléments spéciaux utilisés dans une commande SQL (« injection SQL »)](https://cwe.mitre.org/data/definitions/89.html) +* [CWE-90 Neutralisation incorrecte d'éléments spéciaux utilisés dans une requête LDAP (« injection LDAP »)](https://cwe.mitre.org/data/definitions/90.html) +* [CWE-91 Injection XML (aussi appelée injection XPath aveugle)](https://cwe.mitre.org/data/definitions/91.html) +* [CWE-93 Neutralisation incorrecte de séquences CRLF (« injection CRLF »)](https://cwe.mitre.org/data/definitions/93.html) +* [CWE-94 Contrôle incorrect de la génération de code (« injection de code »)](https://cwe.mitre.org/data/definitions/94.html) +* [CWE-95 Neutralisation incorrecte de directives dans du code évalué dynamiquement (« injection eval »)](https://cwe.mitre.org/data/definitions/95.html) +* [CWE-96 Neutralisation incorrecte de directives dans du code enregistré statiquement (« injection de code statique »)](https://cwe.mitre.org/data/definitions/96.html) +* [CWE-97 Neutralisation incorrecte des inclusions côté serveur (SSI) dans une page web](https://cwe.mitre.org/data/definitions/97.html) +* [CWE-98 Contrôle incorrect du nom de fichier pour une instruction Include/Require dans un programme PHP (« inclusion de fichier distant PHP »)](https://cwe.mitre.org/data/definitions/98.html) +* [CWE-99 Contrôle incorrect des identifiants de ressources (« injection de ressource »)](https://cwe.mitre.org/data/definitions/99.html) +* [CWE-103 Struts : définition incomplète de la méthode validate()](https://cwe.mitre.org/data/definitions/103.html) +* [CWE-104 Struts : le bean de formulaire n'étend pas la classe de validation](https://cwe.mitre.org/data/definitions/104.html) +* [CWE-112 Validation XML manquante](https://cwe.mitre.org/data/definitions/112.html) +* [CWE-113 Neutralisation incorrecte des séquences CRLF dans les en-têtes HTTP (« division de réponse HTTP »)](https://cwe.mitre.org/data/definitions/113.html) +* [CWE-114 Contrôle des processus](https://cwe.mitre.org/data/definitions/114.html) +* [CWE-115 Mauvaise interprétation de la sortie](https://cwe.mitre.org/data/definitions/115.html) +* [CWE-116 Encodage ou échappement incorrect de la sortie](https://cwe.mitre.org/data/definitions/116.html) +* [CWE-129 Validation incorrecte de l'index d'un tableau](https://cwe.mitre.org/data/definitions/129.html) +* [CWE-159 Gestion incorrecte de l'utilisation invalide d'éléments spéciaux](https://cwe.mitre.org/data/definitions/159.html) +* [CWE-470 Utilisation d'une entrée contrôlée de l'extérieur pour sélectionner des classes ou du code (« réflexion non sécurisée »)](https://cwe.mitre.org/data/definitions/470.html) +* [CWE-493 Variable publique critique sans modificateur final](https://cwe.mitre.org/data/definitions/493.html) +* [CWE-500 Champ statique public non marqué final](https://cwe.mitre.org/data/definitions/500.html) +* [CWE-564 Injection SQL : Hibernate](https://cwe.mitre.org/data/definitions/564.html) +* [CWE-610 Référence contrôlée de l'extérieur vers une ressource d'un autre espace](https://cwe.mitre.org/data/definitions/610.html) +* [CWE-643 Neutralisation incorrecte de données dans des expressions XPath (« injection XPath »)](https://cwe.mitre.org/data/definitions/643.html) +* [CWE-644 Neutralisation incorrecte d'en-têtes HTTP pour la syntaxe des scripts](https://cwe.mitre.org/data/definitions/644.html) +* [CWE-917 Neutralisation incorrecte d'éléments spéciaux utilisés dans une instruction de langage d'expression (« injection de langage d'expression »)](https://cwe.mitre.org/data/definitions/917.html) diff --git a/2025/docs/fr/A06_2025-Insecure_Design.md b/2025/docs/fr/A06_2025-Insecure_Design.md index aaf212113..33661e9a7 100644 --- a/2025/docs/fr/A06_2025-Insecure_Design.md +++ b/2025/docs/fr/A06_2025-Insecure_Design.md @@ -1,33 +1,30 @@ -# A06:2025 Insecure Design ![icon](../assets/TOP_10_Icons_Final_Insecure_Design.png){: style="height:80px;width:80px" align="right"} +# A06:2025 Conception non sécurisée ![icône](../assets/TOP_10_Icons_Final_Insecure_Design.png){: style="height:80px;width:80px" align="right"} +## Contexte -## Background. - -Insecure Design slides two spots from #4 to #6 in the ranking as **[A02:2025-Security Misconfiguration](A02_2025-Security_Misconfiguration.md)** and **[A03:2025-Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md)** leapfrog it. This category was introduced in 2021, and we have seen noticeable improvements in the industry related to threat modeling and a greater emphasis on secure design. This category focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures. This includes flaws in the business logic of an application, e.g. the lack of defining unwanted or unexpected state changes inside an application. As a community, we need to move beyond "shift-left" in the coding space, to pre-code activities such as requirements writing and application design, that are critical for the principles of Secure by Design (e.g. see **[Establish a Modern AppSec Program: Planning and Design Phase](0x03_2025-Establishing_a_Modern_Application_Security_Program.md)**). Notable Common Weakness Enumerations (CWEs) include *CWE-256: Unprotected Storage of Credentials, CWE-269 Improper Privilege Management, CWE-434 Unrestricted Upload of File with Dangerous Type, CWE-501: Trust Boundary Violation, and CWE-522: Insufficiently Protected Credentials.* - - -## Score table. +La conception non sécurisée recule de deux places, de la 4e à la 6e place, tandis que **[A02:2025 - Mauvaise configuration de sécurité](A02_2025-Security_Misconfiguration.md)** et **[A03:2025 - Défaillances de la chaîne d'approvisionnement logicielle](A03_2025-Software_Supply_Chain_Failures.md)** la dépassent. Cette catégorie a été introduite en 2021 et nous avons constaté des améliorations notables du secteur dans le domaine de la modélisation des menaces, ainsi qu'un intérêt accru pour la conception sécurisée. Elle porte sur les risques liés aux défauts de conception et d'architecture, et encourage un recours accru à la modélisation des menaces, aux modèles de conception sécurisés et aux architectures de référence. Cela inclut les défauts de logique métier d'une application, par exemple l'absence de définition des changements d'état indésirables ou inattendus au sein d'une application. En tant que communauté, nous devons aller au-delà du « shift-left » dans le domaine du codage et nous intéresser aux activités antérieures au code, comme la rédaction des exigences et la conception des applications, qui sont essentielles aux principes de la sécurité par la conception (voir par exemple **[Mettre en place un programme moderne de sécurité des applications : phase de planification et de conception](0x03_2025-Establishing_a_Modern_Application_Security_Program.md)**). Parmi les CWE notables figurent *CWE-256 : stockage non protégé des identifiants*, *CWE-269 : gestion incorrecte des privilèges*, *CWE-434 : téléversement sans restriction de fichiers de type dangereux*, *CWE-501 : violation de frontière de confiance* et *CWE-522 : identifiants insuffisamment protégés*. +## Tableau des scores - - - - - - - - - @@ -52,148 +49,97 @@ Insecure Design slides two spots from #4 to #6 in the ranking as **[A02:2025-Sec
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+## Description +La conception non sécurisée est une catégorie générale qui représente différentes faiblesses, exprimées comme une « conception de contrôles absente ou inefficace ». La conception non sécurisée n'est pas à l'origine de toutes les autres catégories de risques du Top 10. Il faut noter la différence entre conception non sécurisée et implémentation non sécurisée. Nous distinguons les défauts de conception des défauts d'implémentation pour une bonne raison : ils ont des causes racines différentes, surviennent à des moments différents du processus de développement et appellent des remédiations différentes. Une conception sécurisée peut néanmoins comporter des défauts d'implémentation entraînant des vulnérabilités exploitables. Une conception non sécurisée ne peut pas être corrigée par une implémentation parfaite, car les contrôles de sécurité nécessaires n'ont jamais été créés pour se défendre contre des attaques spécifiques. L'absence de profilage des risques métier inhérents au logiciel ou au système développé est l'un des facteurs qui contribuent à une conception non sécurisée ; elle empêche de déterminer le niveau de sécurité requis pour la conception. -## Description. - -Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top Ten risk categories. Note that there is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes, take place at different times in the development process, and have different remediations. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks. One of the factors that contributes to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required. - -Three key parts of having a secure design are: - -* Gathering Requirements and Resource Management -* Creating a Secure Design -* Having a Secure Development Lifecycle - - -### Requirements and Resource Management - -Collect and negotiate the business requirements for an application with the business, including the protection requirements concerning confidentiality, integrity, availability, and authenticity of all data assets and the expected business logic. Take into account how exposed your application will be and if you need segregation of tenants (beyond those needed for access control). Compile the technical requirements, including functional and non-functional security requirements. Plan and negotiate the budget covering all design, build, testing, and operation, including security activities. - - -### Secure Design - -Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. Threat modeling should be integrated into refinement sessions (or similar activities); look for changes in data flows and access control or other security controls. In the user story development, determine the correct flow and failure states, ensure they are well understood and agreed upon by the responsible and impacted parties. Analyze assumptions and conditions for expected and failure flows to ensure they remain accurate and desirable. Determine how to validate the assumptions and enforce conditions needed for proper behaviors. Ensure the results are documented in the user story. Learn from mistakes and offer positive incentives to promote improvements. Secure design is neither an add-on nor a tool that you can add to software. - - -### Secure Development Lifecycle +Une conception sécurisée repose sur trois éléments essentiels : -Secure software requires a secure development lifecycle, a secure design pattern, a paved road methodology, a secure component library, appropriate tooling, threat modeling, and incident post-mortems that are used to improve the process. Reach out to your security specialists at the beginning of a software project, throughout the project, and for ongoing software maintenance. Consider leveraging the [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/) to help structure your secure software development efforts. +* la collecte des exigences et la gestion des ressources ; +* la création d'une conception sécurisée ; +* la mise en place d'un cycle de vie du développement sécurisé. -Often self-responsibility of developers is underappreciated. Foster a culture of awareness, responsibility and proactive risk mitigation. Regular exchanges about security (e.g. during threat modeling sessions) can generate a mindset for including security in all important design decisions. +### Exigences et gestion des ressources +Recueillez et négociez avec le métier les exigences métier d'une application, y compris les exigences de protection relatives à la confidentialité, à l'intégrité, à la disponibilité et à l'authenticité de tous les actifs de données, ainsi que la logique métier attendue. Tenez compte de l'exposition de votre application et de la nécessité éventuelle de séparer les locataires, au-delà des séparations nécessaires au contrôle d'accès. Rassemblez les exigences techniques, y compris les exigences de sécurité fonctionnelles et non fonctionnelles. Planifiez et négociez le budget couvrant la conception, la construction, les tests et l'exploitation, y compris les activités de sécurité. -## How to prevent. +### Conception sécurisée +La conception sécurisée est une culture et une méthodologie qui évaluent constamment les menaces et garantissent que le code est conçu et testé de manière robuste afin de prévenir les méthodes d'attaque connues. La modélisation des menaces doit être intégrée aux sessions d'affinage (ou activités équivalentes) ; recherchez les changements dans les flux de données, le contrôle d'accès et les autres contrôles de sécurité. Lors de la rédaction des récits utilisateurs, déterminez le flux correct et les états d'échec, et assurez-vous qu'ils sont bien compris et approuvés par les parties responsables et concernées. Analysez les hypothèses et les conditions des flux nominaux et des flux d'échec pour vérifier qu'elles restent exactes et souhaitables. Déterminez comment valider les hypothèses et imposer les conditions nécessaires à un comportement correct. Assurez-vous que les résultats sont documentés dans le récit utilisateur. Tirez les leçons des erreurs et proposez des incitations positives pour encourager les améliorations. La conception sécurisée n'est ni un ajout ni un outil que l'on peut greffer à un logiciel. +### Cycle de vie du développement sécurisé -* Establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls -* Establish and use a library of secure design patterns or paved-road components -* Use threat modeling for critical parts of the application such as authentication, access control, business logic, and key flows -* User threat modeling as an educational tool to generate a security mindset -* Integrate security language and controls into user stories -* Integrate plausibility checks at each tier of your application (from frontend to backend) -* Write unit and integration tests to validate that all critical flows are resistant to the threat model. Compile use-cases *and* misuse-cases for each tier of your application. -* Segregate tier layers on the system and network layers, depending on the exposure and protection needs -* Segregate tenants robustly by design throughout all tiers +Un logiciel sécurisé nécessite un cycle de vie du développement sécurisé, un modèle de conception sécurisé, une méthodologie de « chemin pavé », une bibliothèque de composants sécurisés, des outils appropriés, une modélisation des menaces et des analyses rétrospectives des incidents utilisées pour améliorer le processus. Sollicitez vos spécialistes de la sécurité au début d'un projet logiciel, pendant toute sa durée et pour la maintenance continue du logiciel. Envisagez d'utiliser le [Software Assurance Maturity Model (SAMM) de l'OWASP](https://owaspsamm.org/) pour structurer vos efforts de développement logiciel sécurisé. +La responsabilité individuelle des développeurs est souvent sous-estimée. Favorisez une culture de sensibilisation, de responsabilité et d'atténuation proactive des risques. Des échanges réguliers sur la sécurité (par exemple lors de sessions de modélisation des menaces) peuvent créer un état d'esprit qui intègre la sécurité à toutes les décisions importantes de conception. -## Example attack scenarios. +## Comment s'en prémunir -**Scenario #1:** A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity, as more than one person can know the answers. Such functionality should be removed and replaced with a more secure design. +* établir et utiliser un cycle de vie du développement sécurisé avec l'aide de professionnels de l'AppSec pour évaluer et concevoir les contrôles liés à la sécurité et à la confidentialité ; +* établir et utiliser une bibliothèque de modèles de conception sécurisés ou de composants de type « chemin pavé » ; +* utiliser la modélisation des menaces pour les parties critiques de l'application, notamment l'authentification, le contrôle d'accès, la logique métier et les flux clés ; +* utiliser la modélisation des menaces comme outil pédagogique pour développer une culture de la sécurité ; +* intégrer le vocabulaire et les contrôles de sécurité aux récits utilisateurs ; +* intégrer des contrôles de plausibilité à chaque niveau de l'application, du frontend au backend ; +* écrire des tests unitaires et d'intégration pour valider la résistance de tous les flux critiques au modèle de menace. Compiler des cas d'utilisation et des cas d'utilisation abusive pour chaque niveau de l'application ; +* séparer les couches aux niveaux système et réseau, selon l'exposition et les besoins de protection ; +* séparer solidement les locataires par conception à tous les niveaux. -**Scenario #2:** A cinema chain allows group booking discounts and has a maximum of fifteen attendees before requiring a deposit. Attackers could threat model this flow and test if they can find an attack vector in the business logic of the application, e.g. booking six hundred seats and all cinemas at once in a few requests, causing a massive loss of income. +## Exemples de scénarios d'attaque -**Scenario #3:** A retail chain’s e-commerce website does not have protection against bots run by scalpers buying high-end video cards to resell on auction websites. This creates terrible publicity for the video card makers and retail chain owners, and enduring bad blood with enthusiasts who cannot obtain these cards at any price. Careful anti-bot design and domain logic rules, such as purchases made within a few seconds of availability, might identify inauthentic purchases and reject such transactions. +**Scénario n° 1 :** un processus de récupération d'identifiants peut comporter des « questions et réponses », interdites par la norme NIST 800-63b, l'OWASP ASVS et le Top 10 de l'OWASP. Les questions et réponses ne peuvent pas constituer une preuve d'identité fiable, puisque plusieurs personnes peuvent connaître les réponses. Cette fonctionnalité devrait être supprimée et remplacée par une conception plus sûre. +**Scénario n° 2 :** une chaîne de cinémas autorise des réductions pour les réservations de groupe et fixe à quinze le nombre maximal de participants avant d'exiger un acompte. Les attaquants pourraient modéliser les menaces de ce flux et vérifier s'ils peuvent trouver un vecteur d'attaque dans la logique métier de l'application, par exemple réserver six cents places dans tous les cinémas à la fois en quelques requêtes, entraînant une perte de revenus considérable. -## References. +**Scénario n° 3 :** le site de commerce électronique d'une chaîne de magasins ne protège pas contre les bots utilisés par des revendeurs pour acheter des cartes graphiques haut de gamme et les revendre sur des sites d'enchères. Cela nuit fortement à la réputation des fabricants de cartes graphiques et des propriétaires de la chaîne de magasins, et crée un ressentiment durable chez les passionnés qui ne peuvent obtenir ces cartes à aucun prix. Une conception anti-bot attentive et des règles de logique métier, comme l'identification d'achats effectués quelques secondes après la mise en disponibilité, pourraient détecter les achats inauthentiques et rejeter ces transactions. +## Références - -* [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) -* [OWASP SAMM: Design | Secure Architecture](https://owaspsamm.org/model/design/secure-architecture/) -* [OWASP SAMM: Design | Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) -* [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) -* [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org/) +* [Aide-mémoire OWASP : principes de conception sécurisée](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) +* [OWASP SAMM : conception | architecture sécurisée](https://owaspsamm.org/model/design/secure-architecture/) +* [OWASP SAMM : conception | évaluation des menaces](https://owaspsamm.org/model/design/threat-assessment/) +* [NIST – recommandations sur les normes minimales de vérification des logiciels par les développeurs](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) +* [Manifeste de la modélisation des menaces](https://threatmodelingmanifesto.org/) * [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) - -## List of Mapped CWEs - -* [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) - -* [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) - -* [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) - -* [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) - -* [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) - -* [CWE-286 Incorrect User Management](https://cwe.mitre.org/data/definitions/286.html) - -* [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) - -* [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) - -* [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) - -* [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) - -* [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html) - -* [CWE-382 J2EE Bad Practices: Use of System.exit()](https://cwe.mitre.org/data/definitions/382.html) - -* [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) - -* [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) - -* [CWE-436 Interpretation Conflict](https://cwe.mitre.org/data/definitions/436.html) - -* [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) - -* [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) - -* [CWE-454 External Initialization of Trusted Variables or Data Stores](https://cwe.mitre.org/data/definitions/454.html) - -* [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) - -* [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) - -* [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) - -* [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) - -* [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) - -* [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) - -* [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) - -* [CWE-628 Function Call with Incorrectly Specified Arguments](https://cwe.mitre.org/data/definitions/628.html) - -* [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) - -* [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) - -* [CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) - -* [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) - -* [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) - -* [CWE-676 Use of Potentially Dangerous Function](https://cwe.mitre.org/data/definitions/676.html) - -* [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) - -* [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) - -* [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) - -* [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) - -* [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) - -* [CWE-1022 Use of Web Link to Untrusted Target with window.opener Access](https://cwe.mitre.org/data/definitions/1022.html) - -* [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) +## Liste des CWE associées + +* [CWE-73 Contrôle externe du nom ou du chemin d'un fichier](https://cwe.mitre.org/data/definitions/73.html) +* [CWE-183 Liste permissive des entrées autorisées](https://cwe.mitre.org/data/definitions/183.html) +* [CWE-256 Stockage non protégé des identifiants](https://cwe.mitre.org/data/definitions/256.html) +* [CWE-266 Attribution incorrecte de privilèges](https://cwe.mitre.org/data/definitions/266.html) +* [CWE-269 Gestion incorrecte des privilèges](https://cwe.mitre.org/data/definitions/269.html) +* [CWE-286 Gestion incorrecte des utilisateurs](https://cwe.mitre.org/data/definitions/286.html) +* [CWE-311 Chiffrement manquant de données sensibles](https://cwe.mitre.org/data/definitions/311.html) +* [CWE-312 Stockage en clair d'informations sensibles](https://cwe.mitre.org/data/definitions/312.html) +* [CWE-313 Stockage en clair dans un fichier ou sur un disque](https://cwe.mitre.org/data/definitions/313.html) +* [CWE-316 Stockage en clair d'informations sensibles en mémoire](https://cwe.mitre.org/data/definitions/316.html) +* [CWE-362 Exécution concurrente utilisant une ressource partagée avec une synchronisation incorrecte (« condition de course »)](https://cwe.mitre.org/data/definitions/362.html) +* [CWE-382 Mauvaises pratiques J2EE : utilisation de System.exit()](https://cwe.mitre.org/data/definitions/382.html) +* [CWE-419 Canal principal non protégé](https://cwe.mitre.org/data/definitions/419.html) +* [CWE-434 Téléversement sans restriction de fichiers de type dangereux](https://cwe.mitre.org/data/definitions/434.html) +* [CWE-436 Conflit d'interprétation](https://cwe.mitre.org/data/definitions/436.html) +* [CWE-444 Interprétation incohérente des requêtes HTTP (« désynchronisation des requêtes HTTP »)](https://cwe.mitre.org/data/definitions/444.html) +* [CWE-451 Présentation incorrecte d'informations critiques dans l'interface utilisateur (UI)](https://cwe.mitre.org/data/definitions/451.html) +* [CWE-454 Initialisation externe de variables ou de magasins de données de confiance](https://cwe.mitre.org/data/definitions/454.html) +* [CWE-472 Contrôle externe d'un paramètre web supposé immuable](https://cwe.mitre.org/data/definitions/472.html) +* [CWE-501 Violation de frontière de confiance](https://cwe.mitre.org/data/definitions/501.html) +* [CWE-522 Identifiants insuffisamment protégés](https://cwe.mitre.org/data/definitions/522.html) +* [CWE-525 Utilisation du cache d'un navigateur web contenant des informations sensibles](https://cwe.mitre.org/data/definitions/525.html) +* [CWE-539 Utilisation de cookies persistants contenant des informations sensibles](https://cwe.mitre.org/data/definitions/539.html) +* [CWE-598 Utilisation de la méthode GET avec des chaînes de requête sensibles](https://cwe.mitre.org/data/definitions/598.html) +* [CWE-602 Application côté client de la sécurité côté serveur](https://cwe.mitre.org/data/definitions/602.html) +* [CWE-628 Appel de fonction avec des arguments spécifiés incorrectement](https://cwe.mitre.org/data/definitions/628.html) +* [CWE-642 Contrôle externe de données d'état critiques](https://cwe.mitre.org/data/definitions/642.html) +* [CWE-646 Dépendance au nom ou à l'extension d'un fichier fourni de l'extérieur](https://cwe.mitre.org/data/definitions/646.html) +* [CWE-653 Compartimentage insuffisant](https://cwe.mitre.org/data/definitions/653.html) +* [CWE-656 Dépendance à la sécurité par l'obscurité](https://cwe.mitre.org/data/definitions/656.html) +* [CWE-657 Violation des principes de conception sécurisée](https://cwe.mitre.org/data/definitions/657.html) +* [CWE-676 Utilisation d'une fonction potentiellement dangereuse](https://cwe.mitre.org/data/definitions/676.html) +* [CWE-693 Défaillance d'un mécanisme de protection](https://cwe.mitre.org/data/definitions/693.html) +* [CWE-799 Contrôle incorrect de la fréquence des interactions](https://cwe.mitre.org/data/definitions/799.html) +* [CWE-807 Dépendance à des entrées non fiables dans une décision de sécurité](https://cwe.mitre.org/data/definitions/807.html) +* [CWE-841 Application incorrecte d'un flux comportemental](https://cwe.mitre.org/data/definitions/841.html) +* [CWE-1021 Restriction incorrecte des couches ou cadres d'interface utilisateur rendus](https://cwe.mitre.org/data/definitions/1021.html) +* [CWE-1022 Utilisation d'un lien web vers une cible non fiable avec accès à window.opener](https://cwe.mitre.org/data/definitions/1022.html) +* [CWE-1125 Surface d'attaque excessive](https://cwe.mitre.org/data/definitions/1125.html) diff --git a/2025/docs/fr/A07_2025-Authentication_Failures.md b/2025/docs/fr/A07_2025-Authentication_Failures.md index 2d3077107..fd498ef0b 100644 --- a/2025/docs/fr/A07_2025-Authentication_Failures.md +++ b/2025/docs/fr/A07_2025-Authentication_Failures.md @@ -1,33 +1,30 @@ -# A07:2025 Authentication Failures ![icon](../assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} +# A07:2025 Défaillances de l'authentification ![icône](../assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} +## Contexte -## Background. - -Authentication Failures maintains its position at #7 with a slight name change to more accurately reflect the 36 CWEs in this category. Despite benefits from standardized frameworks, this category has kept its #7 rank from 2021. Notable CWEs included are *CWE-259 Use of Hard-coded Password*, *CWE-297: Improper Validation of Certificate with Host Mismatch*, *CWE-287: Improper Authentication*, *CWE-384: Session Fixation*, and *CWE-798 Use of Hard-coded Credentials*. - - -## Score table. +Les défaillances de l'authentification conservent leur 7e place, avec un léger changement de nom destiné à mieux refléter les 36 CWE de cette catégorie. Malgré les bénéfices des frameworks standardisés, cette catégorie a conservé son rang de 2021. Parmi les CWE notables figurent *CWE-259 : Utilisation d'un mot de passe codé en dur*, *CWE-297 : Validation incorrecte d'un certificat avec discordance d'hôte*, *CWE-287 : Authentification incorrecte*, *CWE-384 : Fixation de session* et *CWE-798 : Utilisation d'identifiants codés en dur*. +## Tableau des scores - - - - - - - - - @@ -52,148 +49,86 @@ Authentication Failures maintains its position at #7 with a slight name change t
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
- - -## Description. - -When an attacker is able to trick a system into recognizing an invalid or incorrect user as legitimate, this vulnerability is present. There may be authentication weaknesses if the application: - -* Permits automated attacks such as credential stuffing, where the attacker has a breached list of valid usernames and passwords. More recently this type of attack has been expanded to include hybrid password attacks credential stuffing (also known as password spray attacks), where the attacker uses variations or increments of spilled credentials to gain access, for instance trying Password1!, Password2!, Password3! and so on. - -* Permits brute force or other automated, scripted attacks that are not quickly blocked. - -* Permits default, weak, or well-known passwords, such as "Password1" or "admin" username with an "admin" password. - -* Allows users to create new accounts with already known-breached credentials. - -* Allows use of weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers," which cannot be made safe. - -* Uses plain text, encrypted, or weakly hashed passwords data stores (see[ A04:2025-Cryptographic Failures](https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/)). - -* Has missing or ineffective multi-factor authentication. - -* Allows use of weak or ineffective fallbacks if multi-factor authentication is not available. - -* Exposes session identifier in the URL, a hidden field, or another insecure location that is accessible to the client. - -* Reuses the same session identifier after successful login. - -* Does not correctly invalidate user sessions or authentication tokens (mainly single sign-on (SSO) tokens) during logout or a period of inactivity. - -* Does not correctly assert the scope and intended audience of the provided credentials. - -## How to prevent. - -* Where possible, implement and enforce use of multi-factor authentication to prevent automated credential stuffing, brute force, and stolen credential reuse attacks. - -* Where possible, encourage and enable the use of password managers, to help users make better choices. - -* Do not ship or deploy with any default credentials, particularly for admin users. - -* Implement weak password checks, such as testing new or changed passwords against the top 10,000 worst passwords list. - -* During new account creation and password changes validate against lists of known breached credentials (eg: using [haveibeenpwned.com](https://haveibeenpwned.com)). - -* Align password length, complexity, and rotation policies with [National Institute of Standards and Technology (NIST) 800-63b's guidelines in section 5.1.1](https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=5.1.1%20Memorized%20Secrets) for Memorized Secrets or other modern, evidence-based password policies. - -* Do not force human beings to rotate passwords unless you suspect breach. If you suspect breach, force password resets immediately. - -* Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes (“Invalid username or password.”). - -* Limit or increasingly delay failed login attempts but be careful not to create a denial of service scenario. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected or suspected. - -* Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session identifiers should not be in the URL, be securely stored in a secure cookie, and invalidated after logout, idle, and absolute timeouts. - -* Ideally, use a premade, well-trusted system to handle authentication, identity, and session management. Transfer this risk whenever possible by buying and utilizing a hardened and well tested system. - -* Verify the intended use of provided credentials, e.g. for JWTs validate `aud`, `iss` claims and scopes - - -## Example attack scenarios. - -**Scenario #1:** Credential stuffing, the use of lists of known username and password combinations, is now a very common attack. More recently attackers have been found to ‘increment’ or otherwise adjust passwords, based on common human behavior. For instance, changing ‘Winter2025’ to ‘Winter2026’, or ‘ILoveMyDog6’ to ‘ILoveMyDog7’ or ‘ILoveMyDog5’. This adjusting of password attempts is called a hybrid credential stuffing attack or a password spray attack, and they can be even more effective than the traditional version. If an application does not implement defences against automated threats (brute force, scripts, or bots) or credential stuffing, the application can be used as a password oracle to determine if the credentials are valid and gain unauthorized access. - -**Scenario #2:** Most successful authentication attacks occur due to the continued use of passwords as the sole authentication factor. Once considered best practices, password rotation and complexity requirements encourage users to both reuse passwords and use weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and to enforce use of multi-factor authentication on all important systems. - -**Scenario #3:** Application session timeouts aren't implemented correctly. A user uses a public computer to access an application and instead of selecting "logout," the user simply closes the browser tab and walks away. Another Example for this is, if a Single Sign on (SSO) session can not be closed by a Single Logout (SLO). That is, a single login logs you into, for example, your mail reader, your document system, and your chat system. But logging out happens only to the current system. If an attacker uses the same browser after the victim thinks they have successfully logged out, but with the user still authenticated to some of the applications, then can access the victim's account. The same issue can happen in offices and enterprises when a sensitive application has not been properly exited and a colleague has (temporary) access to the unlocked computer. - -## References. - -* [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) - -* [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-introduction/05-introduction) - - -## List of Mapped CWEs - -* [CWE-258 Empty Password in Configuration File](https://cwe.mitre.org/data/definitions/258.html) - -* [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) - -* [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) - -* [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) - -* [CWE-289 Authentication Bypass by Alternate Name](https://cwe.mitre.org/data/definitions/289.html) - -* [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) - -* [CWE-291 Reliance on IP Address for Authentication](https://cwe.mitre.org/data/definitions/291.html) - -* [CWE-293 Using Referer Field for Authentication](https://cwe.mitre.org/data/definitions/293.html) - -* [CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) - -* [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) - -* [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) - -* [CWE-298 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/298.html) - -* [CWE-299 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/299.html) - -* [CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) - -* [CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) - -* [CWE-303 Incorrect Implementation of Authentication Algorithm](https://cwe.mitre.org/data/definitions/303.html) - -* [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) - -* [CWE-305 Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html) - -* [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) - -* [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) - -* [CWE-308 Use of Single-factor Authentication](https://cwe.mitre.org/data/definitions/308.html) - -* [CWE-309 Use of Password System for Primary Authentication](https://cwe.mitre.org/data/definitions/309.html) - -* [CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) - -* [CWE-350 Reliance on Reverse DNS Resolution for a Security-Critical Action](https://cwe.mitre.org/data/definitions/350.html) - -* [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) - -* [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) - -* [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) - -* [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) - -* [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) - -* [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) - -* [CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) - -* [CWE-941 Incorrectly Specified Destination in a Communication Channel](https://cwe.mitre.org/data/definitions/941.html) - -* [CWE-1390 Weak Authentication](https://cwe.mitre.org/data/definitions/1390.html) - -* [CWE-1391 Use of Weak Credentials](https://cwe.mitre.org/data/definitions/1391.html) - -* [CWE-1392 Use of Default Credentials](https://cwe.mitre.org/data/definitions/1392.html) - -* [CWE-1393 Use of Default Password](https://cwe.mitre.org/data/definitions/1393.html) +## Description + +Cette vulnérabilité est présente lorsqu'un attaquant parvient à tromper un système pour qu'il reconnaisse comme légitime un utilisateur invalide ou incorrect. Il peut exister des faiblesses d'authentification si l'application : + +* autorise les attaques automatisées telles que le credential stuffing, dans lesquelles l'attaquant dispose d'une liste de noms d'utilisateur et de mots de passe valides issus d'une compromission. Plus récemment, ce type d'attaque s'est étendu aux attaques par mot de passe hybride, ou password spraying, dans lesquelles l'attaquant utilise des variantes ou des incréments des identifiants divulgués pour obtenir un accès, par exemple en essayant `Password1!`, `Password2!`, `Password3!`, etc. ; +* autorise les attaques par force brute ou d'autres attaques automatisées et scriptées qui ne sont pas rapidement bloquées ; +* autorise des mots de passe par défaut, faibles ou connus, tels que « Password1 » ou le nom d'utilisateur « admin » associé au mot de passe « admin » ; +* permet aux utilisateurs de créer de nouveaux comptes avec des identifiants déjà connus comme compromis ; +* utilise des processus faibles ou inefficaces de récupération d'identifiants et de mots de passe oubliés, tels que des « réponses fondées sur des connaissances », qui ne peuvent pas être sécurisés ; +* utilise des magasins de données contenant des mots de passe en clair, chiffrés ou hachés faiblement (voir [A04:2025 - Défaillances cryptographiques](https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/)) ; +* ne dispose pas d'une authentification multifacteur, ou celle-ci est inefficace ; +* autorise l'utilisation de solutions de repli faibles ou inefficaces lorsque l'authentification multifacteur n'est pas disponible ; +* expose l'identifiant de session dans l'URL, un champ masqué ou un autre emplacement non sécurisé accessible au client ; +* réutilise le même identifiant de session après une connexion réussie ; +* n'invalide pas correctement les sessions utilisateur ou les jetons d'authentification (principalement les jetons d'authentification unique, ou SSO) lors de la déconnexion ou après une période d'inactivité ; +* ne vérifie pas correctement la portée et l'audience prévue des identifiants fournis. + +## Comment s'en prémunir + +* Lorsque cela est possible, implémenter et imposer l'utilisation de l'authentification multifacteur afin de prévenir le credential stuffing automatisé, les attaques par force brute et la réutilisation d'identifiants volés. +* Lorsque cela est possible, encourager et permettre l'utilisation de gestionnaires de mots de passe afin d'aider les utilisateurs à faire de meilleurs choix. +* Ne pas livrer ni déployer de solution avec des identifiants par défaut, en particulier pour les utilisateurs administrateurs. +* Implémenter des contrôles des mots de passe faibles, par exemple en comparant les mots de passe nouveaux ou modifiés à la liste des 10 000 pires mots de passe. +* Lors de la création d'un compte et de la modification d'un mot de passe, vérifier les listes d'identifiants connus comme compromis (par exemple avec [haveibeenpwned.com](https://haveibeenpwned.com)). +* Aligner les politiques de longueur, de complexité et de rotation des mots de passe sur les [recommandations du NIST 800-63b, section 5.1.1](https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=5.1.1%20Memorized%20Secrets) relatives aux secrets mémorisés, ou sur d'autres politiques modernes fondées sur des preuves. +* Ne pas imposer aux personnes de changer régulièrement leur mot de passe, sauf en cas de suspicion de compromission. En cas de suspicion de compromission, imposer immédiatement une réinitialisation des mots de passe. +* S'assurer que l'inscription, la récupération des identifiants et les chemins d'accès aux API sont protégés contre les attaques d'énumération de comptes en utilisant le même message pour tous les résultats (« Nom d'utilisateur ou mot de passe invalide. »). +* Limiter les tentatives de connexion échouées ou augmenter progressivement leur délai, en veillant à ne pas créer de scénario de déni de service. Journaliser tous les échecs et alerter les administrateurs lorsqu'une attaque par credential stuffing, par force brute ou une autre attaque est détectée ou soupçonnée. +* Utiliser un gestionnaire de sessions intégré, sécurisé et côté serveur, qui génère après la connexion un nouvel identifiant de session aléatoire à forte entropie. Les identifiants de session ne doivent pas figurer dans l'URL ; ils doivent être stockés de manière sécurisée dans un cookie sécurisé et invalidés après la déconnexion, l'expiration pour inactivité et l'expiration absolue. +* Dans l'idéal, utiliser un système préfabriqué et fiable pour gérer l'authentification, l'identité et les sessions. Transférer ce risque lorsque cela est possible en achetant et en utilisant un système renforcé et bien testé. +* Vérifier l'utilisation prévue des identifiants fournis ; par exemple, pour les JWT, valider les revendications `aud`, `iss` et les portées. + +## Exemples de scénarios d'attaque + +**Scénario n° 1 :** le credential stuffing, qui consiste à utiliser des listes de couples de noms d'utilisateur et de mots de passe connus, est désormais une attaque très courante. Plus récemment, on a constaté que les attaquants « incrémentaient » ou ajustaient autrement les mots de passe en fonction de comportements humains courants. Par exemple, ils transforment `Winter2025` en `Winter2026`, ou `ILoveMyDog6` en `ILoveMyDog7` ou `ILoveMyDog5`. Cet ajustement des tentatives de mot de passe est appelé attaque hybride par credential stuffing ou attaque par password spraying et peut être encore plus efficace que la version traditionnelle. Si une application n'implémente pas de défenses contre les menaces automatisées (force brute, scripts ou bots) ou contre le credential stuffing, elle peut servir d'oracle de mots de passe permettant de déterminer si les identifiants sont valides et d'obtenir un accès non autorisé. + +**Scénario n° 2 :** la plupart des attaques d'authentification réussies sont dues à l'utilisation persistante des mots de passe comme unique facteur d'authentification. Autrefois considérées comme de bonnes pratiques, la rotation des mots de passe et les exigences de complexité encouragent les utilisateurs à réutiliser leurs mots de passe et à en choisir de faibles. Il est recommandé aux organisations d'abandonner ces pratiques conformément au NIST 800-63 et d'imposer l'authentification multifacteur sur tous les systèmes importants. + +**Scénario n° 3 :** les délais d'expiration des sessions applicatives ne sont pas correctement implémentés. Un utilisateur accède à une application depuis un ordinateur public et, au lieu de sélectionner « se déconnecter », ferme simplement l'onglet du navigateur et s'en va. Autre exemple : une session SSO (Single Sign-On) ne peut pas être fermée par une déconnexion unique (SLO, Single Logout). Une seule connexion vous ouvre par exemple votre messagerie, votre système documentaire et votre outil de discussion, mais la déconnexion ne concerne que le système courant. Si un attaquant utilise le même navigateur après que la victime pense s'être correctement déconnectée, alors qu'elle reste authentifiée auprès de certaines applications, il peut accéder à son compte. Le même problème peut se produire dans les bureaux et les entreprises lorsqu'une application sensible n'a pas été correctement fermée et qu'un collègue dispose temporairement d'un accès à l'ordinateur déverrouillé. + +## Références + +* [Aide-mémoire OWASP sur l'authentification](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) +* [Pratiques de codage sécurisé OWASP](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable/en/01-introduction/05-introduction) + +## Liste des CWE associées + +* [CWE-258 Mot de passe vide dans un fichier de configuration](https://cwe.mitre.org/data/definitions/258.html) +* [CWE-259 Utilisation d'un mot de passe codé en dur](https://cwe.mitre.org/data/definitions/259.html) +* [CWE-287 Authentification incorrecte](https://cwe.mitre.org/data/definitions/287.html) +* [CWE-288 Contournement de l'authentification par un chemin ou canal alternatif](https://cwe.mitre.org/data/definitions/288.html) +* [CWE-289 Contournement de l'authentification par un autre nom](https://cwe.mitre.org/data/definitions/289.html) +* [CWE-290 Contournement de l'authentification par usurpation](https://cwe.mitre.org/data/definitions/290.html) +* [CWE-291 Dépendance à une adresse IP pour l'authentification](https://cwe.mitre.org/data/definitions/291.html) +* [CWE-293 Utilisation du champ Referer pour l'authentification](https://cwe.mitre.org/data/definitions/293.html) +* [CWE-294 Contournement de l'authentification par capture-rejeu](https://cwe.mitre.org/data/definitions/294.html) +* [CWE-295 Validation incorrecte d'un certificat](https://cwe.mitre.org/data/definitions/295.html) +* [CWE-297 Validation incorrecte d'un certificat avec discordance d'hôte](https://cwe.mitre.org/data/definitions/297.html) +* [CWE-298 Validation incorrecte d'un certificat avec discordance d'hôte](https://cwe.mitre.org/data/definitions/298.html) +* [CWE-299 Validation incorrecte d'un certificat avec discordance d'hôte](https://cwe.mitre.org/data/definitions/299.html) +* [CWE-300 Canal accessible par une entité qui n'est pas un point d'extrémité](https://cwe.mitre.org/data/definitions/300.html) +* [CWE-302 Contournement de l'authentification par des données supposées immuables](https://cwe.mitre.org/data/definitions/302.html) +* [CWE-303 Implémentation incorrecte d'un algorithme d'authentification](https://cwe.mitre.org/data/definitions/303.html) +* [CWE-304 Étape critique manquante dans l'authentification](https://cwe.mitre.org/data/definitions/304.html) +* [CWE-305 Contournement de l'authentification par une faiblesse primaire](https://cwe.mitre.org/data/definitions/305.html) +* [CWE-306 Authentification manquante pour une fonction critique](https://cwe.mitre.org/data/definitions/306.html) +* [CWE-307 Restriction incorrecte des tentatives d'authentification excessives](https://cwe.mitre.org/data/definitions/307.html) +* [CWE-308 Utilisation d'une authentification à facteur unique](https://cwe.mitre.org/data/definitions/308.html) +* [CWE-309 Utilisation d'un système de mots de passe pour l'authentification primaire](https://cwe.mitre.org/data/definitions/309.html) +* [CWE-346 Erreur de validation de l'origine](https://cwe.mitre.org/data/definitions/346.html) +* [CWE-350 Dépendance à la résolution DNS inverse pour une action critique pour la sécurité](https://cwe.mitre.org/data/definitions/350.html) +* [CWE-384 Fixation de session](https://cwe.mitre.org/data/definitions/384.html) +* [CWE-521 Exigences faibles pour les mots de passe](https://cwe.mitre.org/data/definitions/521.html) +* [CWE-613 Expiration insuffisante de session](https://cwe.mitre.org/data/definitions/613.html) +* [CWE-620 Changement de mot de passe non vérifié](https://cwe.mitre.org/data/definitions/620.html) +* [CWE-640 Mécanisme faible de récupération d'un mot de passe oublié](https://cwe.mitre.org/data/definitions/640.html) +* [CWE-798 Utilisation d'identifiants codés en dur](https://cwe.mitre.org/data/definitions/798.html) +* [CWE-940 Vérification incorrecte de la source d'un canal de communication](https://cwe.mitre.org/data/definitions/940.html) +* [CWE-941 Destination incorrectement spécifiée dans un canal de communication](https://cwe.mitre.org/data/definitions/941.html) +* [CWE-1390 Authentification faible](https://cwe.mitre.org/data/definitions/1390.html) +* [CWE-1391 Utilisation d'identifiants faibles](https://cwe.mitre.org/data/definitions/1391.html) +* [CWE-1392 Utilisation d'identifiants par défaut](https://cwe.mitre.org/data/definitions/1392.html) +* [CWE-1393 Utilisation d'un mot de passe par défaut](https://cwe.mitre.org/data/definitions/1393.html) diff --git a/2025/docs/fr/A08_2025-Software_or_Data_Integrity_Failures.md b/2025/docs/fr/A08_2025-Software_or_Data_Integrity_Failures.md index 6c465c9b0..2ac6d2121 100644 --- a/2025/docs/fr/A08_2025-Software_or_Data_Integrity_Failures.md +++ b/2025/docs/fr/A08_2025-Software_or_Data_Integrity_Failures.md @@ -1,32 +1,30 @@ -# A08:2025 Software or Data Integrity Failures ![icon](../assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} +# A08:2025 Défaillances d'intégrité du logiciel ou des données ![icône](../assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} -## Background. +## Contexte -Software or Data Integrity Failures continues at #8, with a slight, clarifying name change from "Software *and* Data Integrity Failures". This category is focused on the failure to maintain trust boundaries and verify the integrity of software, code, and data artifacts at a lower level than Software Supply Chain Failures. This category focuses on making assumptions related to software updates and critical data, without verifying integrity. Notable Common Weakness Enumerations (CWEs) include *CWE-829: Inclusion of Functionality from Untrusted Control Sphere*, *CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes*, and *CWE-502: Deserialization of Untrusted Data*. - - -## Score table. +Les défaillances d'intégrité du logiciel ou des données restent à la 8e place, avec un léger changement de nom destiné à clarifier la différence avec « défaillances d'intégrité du logiciel *et* des données ». Cette catégorie porte sur l'incapacité à maintenir les frontières de confiance et à vérifier l'intégrité des logiciels, du code et des artefacts de données, à un niveau plus bas que celui des défaillances de la chaîne d'approvisionnement logicielle. Elle concerne les hypothèses relatives aux mises à jour logicielles et aux données critiques, lorsqu'elles ne sont pas vérifiées. Parmi les CWE notables figurent *CWE-829 : Inclusion de fonctionnalités provenant d'une sphère de contrôle non fiable*, *CWE-915 : Modification incorrectement contrôlée d'attributs d'objets déterminés dynamiquement* et *CWE-502 : Désérialisation de données non fiables*. +## Tableau des scores - - - - - - - - - @@ -51,72 +49,52 @@ Software or Data Integrity Failures continues at #8, with a slight, clarifying n
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+## Description +Les défaillances d'intégrité du logiciel et des données concernent le code et l'infrastructure qui ne protègent pas contre le traitement de code ou de données invalides ou non fiables comme s'ils étaient fiables et valides. Par exemple, une application peut dépendre de plugins, bibliothèques ou modules provenant de sources, dépôts et réseaux de diffusion de contenu (CDN) non fiables. Un pipeline CI/CD non sécurisé qui ne consomme ni ne fournit de contrôles d'intégrité logicielle peut permettre un accès non autorisé, l'introduction de code non sécurisé ou malveillant, ou la compromission du système. Autre exemple : une CI/CD récupère du code ou des artefacts dans des emplacements non fiables et ne les vérifie pas avant utilisation (en contrôlant leur signature ou un mécanisme similaire). Enfin, de nombreuses applications intègrent désormais une fonctionnalité de mise à jour automatique : les mises à jour sont téléchargées sans vérification suffisante de leur intégrité, puis appliquées à l'application auparavant considérée comme fiable. Des attaquants pourraient téléverser leurs propres mises à jour pour qu'elles soient distribuées et exécutées sur toutes les installations. Un autre exemple concerne les objets ou les données encodés ou sérialisés dans une structure qu'un attaquant peut observer et modifier, ce qui crée une vulnérabilité de désérialisation non sécurisée. -## Description. - -Software and data integrity failures relate to code and infrastructure that does not protect against invalid or untrusted code or data being treated as trusted and valid. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline without consuming and providing software integrity checks can introduce the potential for unauthorized access, insecure or malicious code, or system compromise. Another example of this is a CI/CD that pulls code or artifacts from untrusted places and/or doesn’t verify them before use (by checking the signature or similar mechanism). Lastly, many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations. Another example is where objects or data are encoded or serialized into a structure that an attacker can see and modify is vulnerable to insecure deserialization. - - -## How to prevent. - - - -* Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered. -* Ensure libraries and dependencies, such as npm or Maven, are only consuming trusted repositories. If you have a higher risk profile, consider hosting an internal known-good repository that's vetted. -* Ensure that there is a review process for code and configuration changes to minimize the chance that malicious code or configuration could be introduced into your software pipeline. -* Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes. -* Ensure that unsigned or unencrypted serialized data is not received from untrusted clients and subsequently used without some form of integrity check or digital signature to detect tampering or replay of the serialized data. - - -## Example attack scenarios. - -**Scenario #1 Inclusion of Web Functionality from an Untrusted Source:** A company uses an external service provider to provide support functionality. For convenience, it has a DNS mapping for `myCompany.SupportProvider.com` to `support.myCompany.com`. This means that all cookies, including authentication cookies, set on the `myCompany.com` domain will now be sent to the support provider. Anyone with access to the support provider’s infrastructure can steal the cookies of all of your users that have visited `support.myCompany.com` and perform a session hijacking attack. - -**Scenario #2 Update without signing:** Many home routers, set-top boxes, device firmware, and others do not verify updates via signed firmware. Unsigned firmware is a growing target for attackers and is expected to only get worse. This is a major concern as many times there is no mechanism to remediate other than to fix in a future version and wait for previous versions to age out. - -**Scenario #3 Use of Package from an Untrusted Source:** A developer has trouble finding the updated version of a package they are looking for, so they download it not from the regular, trusted package manager, but from a website online. The package is not signed, and thus there is no opportunity to ensure integrity. The package includes malicious code. - -**Scenario #4 Insecure Deserialization:** A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing the user state and passing it back and forth with each request. An attacker notices the "rO0" Java object signature (in base64) and uses the [Java Deserialization Scanner](https://github.com/federicodotta/Java-Deserialization-Scanner) to gain remote code execution on the application server. - -## References. - -* [OWASP Cheat Sheet: Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) -* [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) -* [OWASP Cheat Sheet: Deserialization](https://wiki.owasp.org/index.php/Deserialization_Cheat_Sheet) -* [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) -* [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) -* [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) -* [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) -* [Insecure Deserialization by Tenendo](https://tenendo.com/insecure-deserialization/) - - -## List of Mapped CWEs - -* [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) - -* [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) - -* [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) - -* [CWE-427 Uncontrolled Search Path Element](https://cwe.mitre.org/data/definitions/427.html) +## Comment s'en prémunir -* [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) +* utiliser des signatures numériques ou des mécanismes similaires pour vérifier que le logiciel ou les données proviennent de la source attendue et n'ont pas été modifiés ; +* s'assurer que les bibliothèques et dépendances, comme npm ou Maven, ne consomment que des dépôts fiables. Si votre profil de risque est élevé, envisager d'héberger un dépôt interne de référence, contrôlé et validé ; +* s'assurer qu'un processus de revue du code et des changements de configuration est en place afin de réduire le risque d'introduire du code ou une configuration malveillante dans votre pipeline logiciel ; +* s'assurer que le pipeline CI/CD dispose d'une séparation des responsabilités, d'une configuration et d'un contrôle d'accès appropriés afin de garantir l'intégrité du code circulant dans les processus de construction et de déploiement ; +* s'assurer que des données sérialisées non signées ou non chiffrées ne sont pas reçues de clients non fiables puis utilisées sans contrôle d'intégrité ou signature numérique permettant de détecter leur altération ou la relecture de ces données sérialisées. -* [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) +## Exemples de scénarios d'attaque -* [CWE-506 Embedded Malicious Code](https://cwe.mitre.org/data/definitions/506.html) +**Scénario n° 1 – Inclusion de fonctionnalités web provenant d'une source non fiable :** une entreprise utilise un fournisseur externe pour fournir des fonctionnalités d'assistance. Par commodité, elle dispose d'une correspondance DNS de `myCompany.SupportProvider.com` vers `support.myCompany.com`. Cela signifie que tous les cookies définis sur le domaine `myCompany.com`, y compris les cookies d'authentification, sont désormais envoyés au fournisseur d'assistance. Toute personne ayant accès à l'infrastructure de ce fournisseur peut voler les cookies de tous les utilisateurs ayant visité `support.myCompany.com` et mener une attaque de détournement de session. -* [CWE-509 Replicating Malicious Code (Virus or Worm)](https://cwe.mitre.org/data/definitions/509.html) +**Scénario n° 2 – Mise à jour non signée :** de nombreux routeurs domestiques, décodeurs, micrologiciels d'appareils et autres systèmes ne vérifient pas les mises à jour au moyen d'un micrologiciel signé. Les micrologiciels non signés sont une cible croissante pour les attaquants et la situation devrait empirer. Il s'agit d'une préoccupation majeure, car il n'existe souvent aucun mécanisme de remédiation autre que la correction dans une version ultérieure et l'attente de l'obsolescence des versions précédentes. -* [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) +**Scénario n° 3 – Utilisation d'un paquet provenant d'une source non fiable :** un développeur peine à trouver la version mise à jour d'un paquet recherché. Il le télécharge donc non pas depuis le gestionnaire de paquets habituel et fiable, mais depuis un site web. Le paquet n'est pas signé et il est donc impossible d'en garantir l'intégrité. Il contient du code malveillant. -* [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) +**Scénario n° 4 – Désérialisation non sécurisée :** une application React appelle un ensemble de microservices Spring Boot. Étant des programmeurs fonctionnels, les développeurs ont essayé de garantir l'immutabilité de leur code. La solution retenue consiste à sérialiser l'état utilisateur et à le transmettre dans chaque requête. Un attaquant remarque la signature « rO0 » d'un objet Java (en base64) et utilise le [Java Deserialization Scanner](https://github.com/federicodotta/Java-Deserialization-Scanner) pour obtenir l'exécution de code à distance sur le serveur d'application. -* [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) +## Références -* [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) +* [Aide-mémoire OWASP : sécurité de la chaîne d'approvisionnement logicielle](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) +* [Aide-mémoire OWASP : infrastructure as code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) +* [Aide-mémoire OWASP : désérialisation](https://wiki.owasp.org/index.php/Deserialization_Cheat_Sheet) +* [Contrôles d'intégrité logicielle SAFECode](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [Une cyberattaque « pire cauchemar » : l'histoire inconnue du piratage de SolarWinds](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) +* [Compromission du téléverseur Bash de CodeCov](https://about.codecov.io/security-update) +* [Securing DevOps, par Julien Vehent](https://www.manning.com/books/securing-devops) +* [Désérialisation non sécurisée, par Tenendo](https://tenendo.com/insecure-deserialization/) -* [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) +## Liste des CWE associées -* [CWE-926 Improper Export of Android Application Components](https://cwe.mitre.org/data/definitions/926.html) +* [CWE-345 Vérification insuffisante de l'authenticité des données](https://cwe.mitre.org/data/definitions/345.html) +* [CWE-353 Prise en charge manquante du contrôle d'intégrité](https://cwe.mitre.org/data/definitions/353.html) +* [CWE-426 Chemin de recherche non fiable](https://cwe.mitre.org/data/definitions/426.html) +* [CWE-427 Élément de chemin de recherche non contrôlé](https://cwe.mitre.org/data/definitions/427.html) +* [CWE-494 Téléchargement de code sans contrôle d'intégrité](https://cwe.mitre.org/data/definitions/494.html) +* [CWE-502 Désérialisation de données non fiables](https://cwe.mitre.org/data/definitions/502.html) +* [CWE-506 Code malveillant intégré](https://cwe.mitre.org/data/definitions/506.html) +* [CWE-509 Réplication de code malveillant (virus ou ver)](https://cwe.mitre.org/data/definitions/509.html) +* [CWE-565 Dépendance à des cookies sans validation ni contrôle d'intégrité](https://cwe.mitre.org/data/definitions/565.html) +* [CWE-784 Dépendance à des cookies sans validation ni contrôle d'intégrité dans une décision de sécurité](https://cwe.mitre.org/data/definitions/784.html) +* [CWE-829 Inclusion de fonctionnalités provenant d'une sphère de contrôle non fiable](https://cwe.mitre.org/data/definitions/829.html) +* [CWE-830 Inclusion de fonctionnalités web provenant d'une source non fiable](https://cwe.mitre.org/data/definitions/830.html) +* [CWE-915 Modification incorrectement contrôlée d'attributs d'objets déterminés dynamiquement](https://cwe.mitre.org/data/definitions/915.html) +* [CWE-926 Exportation incorrecte de composants d'une application Android](https://cwe.mitre.org/data/definitions/926.html) diff --git a/2025/docs/fr/A09_2025-Security_Logging_and_Alerting_Failures.md b/2025/docs/fr/A09_2025-Security_Logging_and_Alerting_Failures.md index 630f0fb74..51f85ce0a 100644 --- a/2025/docs/fr/A09_2025-Security_Logging_and_Alerting_Failures.md +++ b/2025/docs/fr/A09_2025-Security_Logging_and_Alerting_Failures.md @@ -1,33 +1,30 @@ -# A09:2025 Security Logging & Alerting Failures ![icon](../assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} +# A09:2025 Défaillances de la journalisation et des alertes de sécurité ![icône](../assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} +## Contexte -## Background. - -Security Logging & Alerting Failures retains its position at #9. This category has a slight name change to emphasize the alerting function needed to induce action on relevant logging events. This category will always be underrepresented in the data, and for the third time voted into a position in the list from the community survey participants. This category is incredibly difficult to test for, and has minimal representation in the CVE/CVSS data (only 723 CVEs); but can be very impactful for visibility and incident alerting and forensics. This category includes issues with *properly handling output encoding to log files (CWE-117), inserting sensitive data into log files (CWE-532), and insufficient logging (CWE-778).* - - -## Score table. +Les défaillances de la journalisation et des alertes de sécurité conservent leur 9e place. Cette catégorie change légèrement de nom afin de mettre l'accent sur la fonction d'alerte nécessaire pour déclencher une action à partir des événements de journalisation pertinents. Elle sera toujours sous-représentée dans les données et a de nouveau été élue par les participants à l'enquête communautaire pour figurer dans la liste. Cette catégorie est extrêmement difficile à tester et est peu représentée dans les données CVE/CVSS (seulement 723 CVE), mais elle peut avoir un impact considérable sur la visibilité, l'alerte et l'analyse forensique des incidents. Elle inclut notamment les problèmes de *gestion correcte de l'encodage de sortie dans les fichiers journaux (CWE-117), d'insertion de données sensibles dans les fichiers journaux (CWE-532) et de journalisation insuffisante (CWE-778)*. +## Tableau des scores - - - - - - - - - @@ -52,85 +49,66 @@ Security Logging & Alerting Failures retains its position at #9. This category h
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
- - -## Description. - -Without logging and monitoring, attacks and breaches cannot be detected, and without alerting it is very difficult to respond quickly and effectively during a security incident. Insufficient logging, continuous monitoring, detection, and alerting to initiate active responses occurs any time: - - -* Auditable events, such as logins, failed logins, and high-value transactions, are not logged or logged inconsistently (for instance, only logging successful logins, but not failed attempts). -* Warnings and errors generate no, inadequate, or unclear log messages. -* The integrity of logs is not properly protected from tampering. -* Logs of applications and APIs are not monitored for suspicious activity. -* Logs are only stored locally, and not properly backedup. -* Appropriate alerting thresholds and response escalation processes are not in place or effective. Alerts are not received or reviewed within a reasonable amount of time. -* Penetration testing and scans by dynamic application security testing (DAST) tools (such as Burp or ZAP) do not trigger alerts. -* The application cannot detect, escalate, or alert for active attacks in real-time or near real-time. -* You are vulnerable to sensitive information leakage by making logging and alerting events visible to a user or an attacker (see [A01:2025-Broken Access Control](A01_2025-Broken_Access_Control.md)), or by logging sensitive information that should not be logged (such as PII or PHI). -* You are vulnerable to injections or attacks on the logging or monitoring systems if log data is not correctly encoded. -* The application is missing or mishandling errors and other exceptional conditions, such that the system is unaware there was an error, and is therefore unable to log there was a problem. -* Adequate ‘use cases’ for issuing alerts are missing or outdated to recognize a special situation. -* Too many false positive alerts make it impossible to distinguish important alerts from unimportant ones, resulting in them being recognized too late or not at all (physical overload of the SOC team). -* Detected alerts cannot be processed correctly because the playbook for the use case is incomplete, out of date, or missing. - - -## How to prevent. - -Developers should implement some or all the following controls, depending on the risk of the application: - - -* Ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis. -* Ensure that every part of your app that contains a security control is logged, whether it succeeds or fails. -* Ensure that logs are generated in a format that log management solutions can easily consume. -* Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems. -* Ensure all transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar. -* Ensure all transactions that throw an error are rolled back and started over. Always fail closed. -* If your application or its users behave suspiciously, issue an alert. Create guidance for your developers on this topic so they can code against this or buy a system for this. -* DevSecOps and security teams should establish effective monitoring and alerting use cases including playbooks such that suspicious activities are detected and responded to quickly by the Security Operations Center (SOC) team. -* Add ‘honeytokens’ as traps for attackers into your application e.g. into the database, data, as real and/or technical user identity. As they are not used in normal business, any access generates logging data that can be alerted with nearly no false positives. -* Behavior analysis and AI support could be optionally an additional technique to support low rates of false positives for alerts. -* Establish or adopt an incident response and recovery plan, such as National Institute of Standards and Technology (NIST) 800-61r2 or later. Teach your software developers what application attacks and incidents look like, so they can report them. - -There are commercial and open-source application protection products such as the OWASP ModSecurity Core Rule Set, and open-source log correlation software, such as the Elasticsearch, Logstash, Kibana (ELK) stack, that feature custom dashboards and alerting that may help you combat these issues. There are also commercial observability tools that can help you respond to or block attacks in close to real-time. - - -## Example attack scenarios. - -**Scenario #1:** A children's health plan provider's website operator couldn't detect a breach due to a lack of monitoring and logging. An external party informed the health plan provider that an attacker had accessed and modified thousands of sensitive health records of more than 3.5 million children. A post-incident review found that the website developers had not addressed significant vulnerabilities. As there was no logging or monitoring of the system, the data breach could have been in progress since 2013, a period of more than seven years. - -**Scenario #2:** A major Indian airline had a data breach involving more than ten years' worth of personal data of millions of passengers, including passport and credit card data. The data breach occurred at a third-party cloud hosting provider, who notified the airline of the breach after some time. - -**Scenario #3:** A major European airline suffered a GDPR reportable breach. The breach was reportedly caused by payment application security vulnerabilities exploited by attackers, who harvested more than 400,000 customer payment records. The airline was fined 20 million pounds as a result by the privacy regulator. - - -## References. - -- [OWASP Proactive Controls: C9: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) - -- [OWASP Application Security Verification Standard: V16 Security Logging and Error Handling](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md) - -- [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) - -- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) - -- [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) - -- [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) - -- [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) - -- [Real world example of such failures in Snowflake Breach](https://www.huntress.com/threat-library/data-breach/snowflake-data-breach) - - -## List of Mapped CWEs - -* [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) - -* [CWE-221 Information Loss of Omission](https://cwe.mitre.org/data/definitions/221.html) - -* [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) - -* [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) - -* [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) +## Description + +Sans journalisation ni surveillance, les attaques et les compromissions ne peuvent pas être détectées ; sans alertes, il est très difficile de réagir rapidement et efficacement lors d'un incident de sécurité. Une journalisation, une surveillance continue, une détection ou des alertes insuffisantes pour déclencher des réponses actives peuvent se manifester lorsque : + +* les événements auditables, tels que les connexions, les échecs de connexion et les transactions de grande valeur, ne sont pas journalisés ou le sont de manière incohérente (par exemple, seuls les succès de connexion sont journalisés, et non les tentatives échouées) ; +* les avertissements et les erreurs ne produisent aucun message de journalisation, ou produisent des messages insuffisants ou peu clairs ; +* l'intégrité des journaux n'est pas correctement protégée contre les altérations ; +* les journaux des applications et des API ne sont pas surveillés pour détecter les activités suspectes ; +* les journaux sont stockés uniquement en local et ne sont pas correctement sauvegardés ; +* les seuils d'alerte appropriés et les processus d'escalade des réponses ne sont pas en place ou ne sont pas efficaces. Les alertes ne sont pas reçues ou examinées dans un délai raisonnable ; +* les tests d'intrusion et les analyses réalisées par des outils de test de sécurité applicative dynamiques (DAST), tels que Burp ou ZAP, ne déclenchent pas d'alertes ; +* l'application ne peut pas détecter, faire remonter ou signaler les attaques actives en temps réel ou quasi temps réel ; +* vous êtes exposé à une fuite d'informations sensibles en rendant les événements de journalisation et d'alerte visibles à un utilisateur ou à un attaquant (voir [A01:2025 - Contrôles d'accès défaillants](A01_2025-Broken_Access_Control.md)), ou en journalisant des informations sensibles qui ne devraient pas l'être (telles que des données personnelles ou de santé) ; +* vous êtes exposé à des injections ou attaques contre les systèmes de journalisation ou de surveillance si les données de journalisation ne sont pas correctement encodées ; +* l'application ne détecte pas ou gère mal les erreurs et autres conditions exceptionnelles, de sorte que le système ignore qu'une erreur s'est produite et ne peut donc pas journaliser le problème ; +* des cas d'utilisation adéquats pour l'émission d'alertes font défaut ou sont obsolètes et ne permettent pas de reconnaître une situation particulière ; +* trop de faux positifs rendent impossible la distinction entre les alertes importantes et les alertes secondaires. Elles sont alors reconnues trop tard, voire pas du tout, en raison de la surcharge de l'équipe du SOC ; +* les alertes détectées ne peuvent pas être traitées correctement parce que le guide opératoire correspondant au cas d'utilisation est incomplet, obsolète ou absent. + +## Comment s'en prémunir + +Les développeurs doivent implémenter tout ou partie des contrôles suivants, selon le risque de l'application : + +* s'assurer que tous les échecs de connexion, de contrôle d'accès et de validation des entrées côté serveur peuvent être journalisés avec suffisamment de contexte utilisateur pour identifier les comptes suspects ou malveillants et être conservés assez longtemps pour permettre une analyse forensique différée ; +* s'assurer que chaque partie de l'application contenant un contrôle de sécurité est journalisée, que le contrôle réussisse ou échoue ; +* s'assurer que les journaux sont générés dans un format facilement exploitable par les solutions de gestion des journaux ; +* s'assurer que les données de journalisation sont correctement encodées afin de prévenir les injections ou attaques contre les systèmes de journalisation et de surveillance ; +* s'assurer que toutes les transactions disposent d'une piste d'audit assortie de contrôles d'intégrité empêchant l'altération ou la suppression, par exemple au moyen de tables de base de données en ajout seulement ou d'un mécanisme équivalent ; +* s'assurer que toutes les transactions qui déclenchent une erreur sont annulées puis recommencées. Toujours échouer de manière sécurisée, en refusant par défaut ; +* si votre application ou ses utilisateurs ont un comportement suspect, émettre une alerte. Créer des recommandations pour vos développeurs afin qu'ils puissent programmer ce comportement, ou acheter un système qui le gère ; +* les équipes DevSecOps et de sécurité doivent établir des cas d'utilisation efficaces de surveillance et d'alerte, accompagnés de guides opératoires, afin que les activités suspectes soient détectées et traitées rapidement par l'équipe du centre des opérations de sécurité (SOC) ; +* ajouter des « honeytokens » comme pièges pour les attaquants dans votre application, par exemple dans la base de données, les données ou sous la forme d'une identité utilisateur réelle ou technique. Comme ils ne sont pas utilisés dans le fonctionnement normal, tout accès génère des données de journalisation qui peuvent déclencher une alerte avec presque aucun faux positif ; +* l'analyse comportementale et l'IA peuvent constituer une technique supplémentaire facultative pour maintenir un faible taux de faux positifs dans les alertes ; +* établir ou adopter un plan de réponse aux incidents et de reprise, tel que le NIST 800-61r2 ou une version ultérieure. Former les développeurs logiciels à reconnaître les attaques et incidents applicatifs afin qu'ils puissent les signaler. + +Il existe des produits commerciaux et open source de protection des applications, tels que l'OWASP ModSecurity Core Rule Set, ainsi que des logiciels open source de corrélation des journaux, comme la pile Elasticsearch, Logstash et Kibana (ELK), qui proposent des tableaux de bord personnalisés et des alertes susceptibles de vous aider à lutter contre ces problèmes. Il existe également des outils commerciaux d'observabilité qui peuvent vous aider à réagir ou à bloquer les attaques presque en temps réel. + +## Exemples de scénarios d'attaque + +**Scénario n° 1 :** l'exploitant du site web d'un organisme d'assurance santé pour enfants n'a pas pu détecter une compromission en raison de l'absence de surveillance et de journalisation. Un tiers a informé l'organisme qu'un attaquant avait accédé à des milliers de dossiers médicaux sensibles concernant plus de 3,5 millions d'enfants et les avait modifiés. L'analyse post-incident a révélé que les développeurs du site web n'avaient pas corrigé d'importantes vulnérabilités. Le système n'étant ni journalisé ni surveillé, la violation de données pouvait être en cours depuis 2013, soit pendant plus de sept ans. + +**Scénario n° 2 :** une grande compagnie aérienne indienne a subi une violation de données portant sur plus de dix ans de données personnelles de millions de passagers, notamment des données de passeport et de cartes bancaires. La violation s'est produite chez un fournisseur tiers d'hébergement cloud, qui a informé la compagnie aérienne de l'incident après un certain temps. + +**Scénario n° 3 :** une grande compagnie aérienne européenne a subi une violation de données à déclarer au titre du RGPD. La violation aurait été causée par des vulnérabilités de sécurité d'une application de paiement exploitées par des attaquants, qui ont collecté plus de 400 000 enregistrements de paiements clients. L'autorité de protection de la vie privée a infligé une amende de 20 millions de livres à la compagnie aérienne. + +## Références + +* [Contrôles proactifs OWASP : C9 : implémenter la journalisation et la surveillance](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) +* [OWASP Application Security Verification Standard : V16 Journalisation de sécurité et gestion des erreurs](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md) +* [Aide-mémoire OWASP : vocabulaire de la journalisation applicative](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) +* [Aide-mémoire OWASP : journalisation](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) +* [Intégrité des données : reprise après un rançongiciel et autres événements destructeurs](https://csrc.nist.gov/publications/detail/sp/1800-11/final) +* [Intégrité des données : identifier et protéger les actifs contre les rançongiciels et autres événements destructeurs](https://csrc.nist.gov/publications/detail/sp/1800-25/final) +* [Intégrité des données : détecter les rançongiciels et autres événements destructeurs et y répondre](https://csrc.nist.gov/publications/detail/sp/1800-26/final) +* [Exemple concret de telles défaillances lors de la compromission de Snowflake](https://www.huntress.com/threat-library/data-breach/snowflake-data-breach) + +## Liste des CWE associées + +* [CWE-117 Neutralisation incorrecte de la sortie pour les journaux](https://cwe.mitre.org/data/definitions/117.html) +* [CWE-221 Perte d'informations par omission](https://cwe.mitre.org/data/definitions/221.html) +* [CWE-223 Omission d'informations pertinentes pour la sécurité](https://cwe.mitre.org/data/definitions/223.html) +* [CWE-532 Insertion d'informations sensibles dans un fichier journal](https://cwe.mitre.org/data/definitions/532.html) +* [CWE-778 Journalisation insuffisante](https://cwe.mitre.org/data/definitions/778.html) diff --git a/2025/docs/fr/A10_2025-Mishandling_of_Exceptional_Conditions.md b/2025/docs/fr/A10_2025-Mishandling_of_Exceptional_Conditions.md index 6fdb956e4..55890d088 100644 --- a/2025/docs/fr/A10_2025-Mishandling_of_Exceptional_Conditions.md +++ b/2025/docs/fr/A10_2025-Mishandling_of_Exceptional_Conditions.md @@ -1,35 +1,32 @@ -# A10:2025 Mishandling of Exceptional Conditions ![icon](../assets/TOP_10_Icons_Final_Mishandling_of_Exceptional_Conditions.png){: style="height:80px;width:80px" align="right"} +# A10:2025 Mauvaise gestion des conditions exceptionnelles ![icône](../assets/TOP_10_Icons_Final_Mishandling_of_Exceptional_Conditions.png){: style="height:80px;width:80px" align="right"} +## Contexte -## Background. +La mauvaise gestion des conditions exceptionnelles est une nouvelle catégorie pour 2025. Elle contient 24 CWE et porte sur la gestion incorrecte des erreurs, les erreurs logiques, les échecs par ouverture et d'autres situations liées aux conditions anormales que les systèmes peuvent rencontrer. Certaines CWE de cette catégorie étaient auparavant associées à la mauvaise qualité du code. Cela nous semblait trop général ; à notre avis, cette catégorie plus précise fournit de meilleures recommandations. -Mishandling of Exceptional Conditions is a new category for 2025. This category contains 24 CWEs and focuses on improper error handling, logical errors, failing open, and other related scenarios stemming from abnormal conditions and systems may encounter. This category has some CWEs that were previously associated with poor code quality. That was too general for us; in our opinion, this more specific category provides better guidance. - -Notable CWEs included in this category: *CWE-209 Generation of Error Message Containing Sensitive Information, CWE-234 Failure to Handle Missing Parameter, CWE-274 Improper Handling of Insufficient Privileges, CWE-476 NULL Pointer Dereference,* and *CWE-636 Not Failing Securely ('Failing Open')*. - - -## Score table. +Parmi les CWE notables de cette catégorie figurent : *CWE-209 : génération d'un message d'erreur contenant des informations sensibles*, *CWE-234 : échec de la gestion d'un paramètre manquant*, *CWE-274 : gestion incorrecte de privilèges insuffisants*, *CWE-476 : déréférencement d'un pointeur NULL* et *CWE-636 : absence d'échec sécurisé (« échec par ouverture »)*. +## Tableau des scores - - - - - - - - - @@ -54,94 +51,72 @@ Notable CWEs included in this category: *CWE-209 Generation of Error Message Con
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+## Description +La mauvaise gestion des conditions exceptionnelles dans un logiciel se produit lorsque les programmes ne parviennent pas à prévenir, détecter et traiter des situations inhabituelles et imprévisibles, ce qui entraîne des plantages, des comportements inattendus et parfois des vulnérabilités. Cela peut correspondre à un ou plusieurs des trois échecs suivants : l'application n'empêche pas une situation inhabituelle de se produire, elle ne reconnaît pas cette situation au moment où elle se produit et/ou elle y répond mal ou pas du tout par la suite. -## Description. - -Mishandling exceptional conditions in software happens when programs fail to prevent, detect, and respond to unusual and unpredictable situations, which leads to crashes, unexpected behavior, and sometimes vulnerabilities. This can involve one or more of the following 3 failings; the application doesn’t prevent an unusual situation from happening, it doesn’t identify the situation as it is happening, and/or it responds poorly or not at all to the situation afterwards. - - - -Exceptional conditions can be caused by missing, poor, or incomplete input validation, or late, high level error handling instead at the functions where they occur, or unexpected environmental states such as memory, privilege, or network issues, inconsistent exception handling, or exceptions that are not handled at all, allowing the system to fall into an unknown and unpredictable state. Any time an application is unsure of its next instruction, an exceptional condition has been mishandled. Hard-to-find errors and exceptions can threaten the security of the whole application for a long time. - - - -Many different security vulnerabilities can happen when we mishandle exceptional conditions, - -such as logic bugs, overflows, race conditions, fraudulent transactions, or issues with memory, state, resource, timing, authentication, and authorization. These types of vulnerabilities can negatively affect the confidentiality, availability, and/or integrity of a system or it’s data. Attackers manipulate an application's flawed error handling to strike this vulnerability. - - -## How to prevent. - -In order to handle an exceptional condition properly we must plan for such situations (expect the worst). We must ‘catch’ every possible system error directly at the place where they occur and then handle it (which means do something meaningful to solve the problem and ensure we recover from the issue). As part of the handling, we should include throwing an error (to inform the user in an understandable way), logging of the event, as well as issuing an alert if we feel that is justified. We should also have a global exception handler in place in case there is ever something we have missed. Ideally, we would also have monitoring and/or observability tooling or functionality that watches for repeated errors or patterns that indicate an on-going attack, that could issue a response, defense, or blocking of some kind. This can help us block and respond to scripts and bots that focus on our error handling weaknesses. - - +Les conditions exceptionnelles peuvent être causées par une validation des entrées absente, mauvaise ou incomplète, par une gestion des erreurs tardive et de haut niveau au lieu d'être effectuée dans les fonctions où les erreurs se produisent, ou par des états inattendus de l'environnement tels que des problèmes de mémoire, de privilèges ou de réseau, une gestion incohérente des exceptions ou des exceptions qui ne sont pas gérées du tout, laissant le système entrer dans un état inconnu et imprévisible. Chaque fois qu'une application ne sait pas quelle instruction exécuter ensuite, une condition exceptionnelle a été mal gérée. Les erreurs et exceptions difficiles à détecter peuvent menacer la sécurité de toute l'application pendant longtemps. -Catching and handling exceptional conditions ensures that the underlying infrastructure of our programs are not left to deal with unpredictable situations. If you are part way through a transaction of any kind, it is extremely important that you roll back every part of the transaction and start again (also known as failing closed). Attempting to recover a transaction part way through is often where we create unrecoverable mistakes. +De nombreuses vulnérabilités peuvent apparaître lorsque nous gérons mal les conditions exceptionnelles, notamment des bugs logiques, des dépassements, des conditions de course, des transactions frauduleuses ou des problèmes de mémoire, d'état, de ressources, de temps, d'authentification et d'autorisation. Ces types de vulnérabilités peuvent nuire à la confidentialité, à la disponibilité et/ou à l'intégrité d'un système ou de ses données. Les attaquants exploitent la gestion défaillante des erreurs d'une application pour tirer parti de cette vulnérabilité. - +## Comment s'en prémunir -Whenever possible, add rate limiting, resource quotas, throttling, and other limits wherever possible, to prevent exceptional conditions in the first place. Nothing in information technology should be limitless, as this leads to a lack of application resilience, denial of service, successful brute force attacks, and extraordinary cloud bills. \ -Consider whether identical repeated errors, above a certain rate, should only be outputted as statistics showing how often they have occurred and in what time frame. This information should be appended to the original message so as not to interfere with automated logging and monitoring, see [A09:2025 Security Logging & Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md). +Pour gérer correctement une condition exceptionnelle, nous devons planifier ces situations (nous attendre au pire). Nous devons « intercepter » chaque erreur système possible directement à l'endroit où elle se produit, puis la gérer, c'est-à-dire effectuer une action utile pour résoudre le problème et garantir que nous récupérons de l'incident. Cette gestion doit notamment comprendre le déclenchement d'une erreur (pour informer l'utilisateur de manière compréhensible), la journalisation de l'événement et l'émission d'une alerte si cela est justifié. Nous devons également disposer d'un gestionnaire global d'exceptions au cas où un élément nous aurait échappé. Dans l'idéal, nous devrions aussi disposer d'outils ou de fonctionnalités de surveillance et d'observabilité qui suivent les erreurs répétées ou les tendances indiquant une attaque en cours, et qui peuvent déclencher une réponse, une défense ou un blocage. Cela peut nous aider à bloquer et à traiter les scripts et les bots qui ciblent les faiblesses de notre gestion des erreurs. -On top of this, we would want to include strict input validation (with sanitization or escaping for potentially hazardous characters that we must accept), and *centralized* error handling, logging, monitoring, and alerting, and a global exception handler. One application should not multiple functions for handling exceptional conditions, it should be performed in one place, the same way each time. We should also create project security requirements for all the advice in this section, perform threat modelling and/or secure design review activities in the design phase of our projects, perform code review or static analysis, as well as execute stress, performance, and penetration testing of the final system. +Intercepter et gérer les conditions exceptionnelles garantit que l'infrastructure sous-jacente de nos programmes n'est pas laissée seule face à des situations imprévisibles. Si vous êtes au milieu d'une transaction, quelle qu'elle soit, il est extrêmement important d'annuler chaque partie de la transaction et de recommencer (ce que l'on appelle également un échec par fermeture). Tenter de récupérer une transaction en cours est souvent à l'origine d'erreurs irrécupérables. - +Dans la mesure du possible, ajoutez des limitations de débit, quotas de ressources, mécanismes de limitation et autres limites afin d'empêcher les conditions exceptionnelles de se produire en premier lieu. Rien dans les technologies de l'information ne devrait être illimité, car cela entraîne un manque de résilience applicative, des dénis de service, des attaques par force brute réussies et des factures cloud extraordinaires. -If possible, your entire organization should handle exceptional conditions in the same way, as it makes it easier to review and audit code for errors in this important security control. +Demandez-vous si des erreurs identiques et répétées, au-delà d'un certain débit, devraient uniquement être produites sous forme de statistiques indiquant leur nombre et la période concernée. Ces informations doivent être ajoutées au message original afin de ne pas perturber la journalisation et la surveillance automatisées ; voir [A09:2025 - Défaillances de la journalisation et des alertes de sécurité](A09_2025-Security_Logging_and_Alerting_Failures.md). +En complément, nous voudrons inclure une validation stricte des entrées (avec nettoyage ou échappement des caractères potentiellement dangereux que nous devons accepter), ainsi qu'une gestion *centralisée* des erreurs, de la journalisation, de la surveillance et des alertes, et un gestionnaire global d'exceptions. Une application ne devrait pas disposer de plusieurs fonctions pour gérer les conditions exceptionnelles : cela doit être réalisé au même endroit et de la même manière à chaque fois. Nous devons également définir des exigences de sécurité du projet pour toutes les recommandations de cette section, effectuer des activités de modélisation des menaces et/ou de revue de conception sécurisée pendant la phase de conception des projets, réaliser des revues de code ou des analyses statiques et exécuter des tests de résistance, de performance et d'intrusion sur le système final. -## Example attack scenarios. +Si possible, toute votre organisation devrait gérer les conditions exceptionnelles de la même manière, car cela facilite la revue et l'audit du code à la recherche d'erreurs dans ce contrôle de sécurité important. -**Scenario #1:** Resource exhaustion via mishandling of exceptional conditions (Denial of Service) could be caused if the application catches exceptions when files are uploaded, but doesn’t properly release resources after. Each new exception leaves resources locked or otherwise unavailable, until all resources are used up. +## Exemples de scénarios d'attaque -**Scenario #2:** Sensitive data exposure via improper handling or database errors that reveals the full system error to the user. The attacker continues to force errors in order to use the sensitive system information to create a better SQL injection attack. The sensitive data in the user error messages are reconnaissance. +**Scénario n° 1 :** l'épuisement des ressources dû à une mauvaise gestion des conditions exceptionnelles (déni de service) peut se produire si l'application intercepte des exceptions lors du téléversement de fichiers, mais ne libère pas correctement les ressources ensuite. Chaque nouvelle exception laisse des ressources verrouillées ou indisponibles jusqu'à ce que toutes les ressources soient épuisées. -**Scenario #3:** State corruption in financial transactions could be caused by an attacker interrupting a multi-step transaction via network disruptions. Imagine the transaction order was: debit user account, credit destination account, log transaction. If the system doesn’t properly roll back the entire transaction (fail closed) when there is an error part way through, the attacker could potentially drain the user’s account, or possibly a race condition that allows the attacker to send money to the destination multiple times. +**Scénario n° 2 :** une exposition de données sensibles due à une gestion incorrecte ou à des erreurs de base de données révèle l'erreur système complète à l'utilisateur. L'attaquant continue de provoquer des erreurs afin d'utiliser les informations sensibles du système pour construire une meilleure attaque par injection SQL. Les données sensibles des messages d'erreur utilisateur servent à la reconnaissance. +**Scénario n° 3 :** la corruption d'état dans des transactions financières peut être causée par un attaquant qui interrompt une transaction en plusieurs étapes au moyen de perturbations réseau. Imaginons l'ordre suivant : débiter le compte utilisateur, créditer le compte destinataire, journaliser la transaction. Si le système n'annule pas correctement l'ensemble de la transaction (échec par fermeture) lorsqu'une erreur survient en cours de route, l'attaquant pourrait vider le compte de l'utilisateur ou exploiter une condition de course pour envoyer plusieurs fois de l'argent au destinataire. -## References. +## Références OWASP MASVS‑RESILIENCE -- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) - -- [OWASP Cheat Sheet: Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html) - -- [OWASP Application Security Verification Standard (ASVS): V16.5 Error Handling](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md#v165-error-handling) - -- [OWASP Testing Guide: 4.8.1 Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) - -* [Best practices for exceptions (Microsoft, .Net)](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) - -* [Clean Code and the Art of Exception Handling (Toptal)](https://www.toptal.com/developers/abap/clean-code-and-the-art-of-exception-handling) - -* [General error handling rules (Google for Developers)](https://developers.google.com/tech-writing/error-messages/error-handling) - -* [Example of real-world mishandling of an exceptional condition](https://www.firstreference.com/blog/human-error-and-internal-control-failures-cause-us62m-fine/) - -## List of Mapped CWEs -* [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) -* [CWE-215 Insertion of Sensitive Information Into Debugging Code](https://cwe.mitre.org/data/definitions/215.html) -* [CWE-234 Failure to Handle Missing Parameter](https://cwe.mitre.org/data/definitions/234.html) -* [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) -* [CWE-248 Uncaught Exception](https://cwe.mitre.org/data/definitions/248.html) -* [CWE-252 Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html) -* [CWE-274 Improper Handling of Insufficient Privileges](https://cwe.mitre.org/data/definitions/274.html) -* [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) -* [CWE-369 Divide By Zero](https://cwe.mitre.org/data/definitions/369.html) -* [CWE-390 Detection of Error Condition Without Action](https://cwe.mitre.org/data/definitions/390.html) -* [CWE-391 Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html) -* [CWE-394 Unexpected Status Code or Return Value](https://cwe.mitre.org/data/definitions/394.html) -* [CWE-396 Declaration of Catch for Generic Exception](https://cwe.mitre.org/data/definitions/396.html) -* [CWE-397 Declaration of Throws for Generic Exception](https://cwe.mitre.org/data/definitions/397.html) -* [CWE-460 Improper Cleanup on Thrown Exception](https://cwe.mitre.org/data/definitions/460.html) -* [CWE-476 NULL Pointer Dereference](https://cwe.mitre.org/data/definitions/476.html) -* [CWE-478 Missing Default Case in Multiple Condition Expression](https://cwe.mitre.org/data/definitions/478.html) -* [CWE-484 Omitted Break Statement in Switch](https://cwe.mitre.org/data/definitions/484.html) -* [CWE-550 Server-generated Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/550.html) -* [CWE-636 Not Failing Securely ('Failing Open')](https://cwe.mitre.org/data/definitions/636.html) -* [CWE-703 Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html) -* [CWE-754 Improper Check for Unusual or Exceptional Conditions](https://cwe.mitre.org/data/definitions/754.html) -* [CWE-755 Improper Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/755.html) -* [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) +* [Aide-mémoire OWASP : journalisation](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) +* [Aide-mémoire OWASP : gestion des erreurs](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html) +* [OWASP Application Security Verification Standard (ASVS) : V16.5 gestion des erreurs](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md#v165-error-handling) +* [Guide de test OWASP : 4.8.1 tests de gestion des erreurs](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) +* [Bonnes pratiques pour les exceptions (Microsoft, .NET)](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) +* [Clean Code et l'art de la gestion des exceptions (Toptal)](https://www.toptal.com/developers/abap/clean-code-and-art-of-exception-handling) +* [Règles générales de gestion des erreurs (Google for Developers)](https://developers.google.com/tech-writing/error-messages/error-handling) +* [Exemple réel de mauvaise gestion d'une condition exceptionnelle](https://www.firstreference.com/blog/human-error-and-internal-control-failures-cause-us62m-fine/) + +## Liste des CWE associées + +* [CWE-209 Génération d'un message d'erreur contenant des informations sensibles](https://cwe.mitre.org/data/definitions/209.html) +* [CWE-215 Insertion d'informations sensibles dans du code de débogage](https://cwe.mitre.org/data/definitions/215.html) +* [CWE-234 Échec de la gestion d'un paramètre manquant](https://cwe.mitre.org/data/definitions/234.html) +* [CWE-235 Gestion incorrecte de paramètres supplémentaires](https://cwe.mitre.org/data/definitions/235.html) +* [CWE-248 Exception non interceptée](https://cwe.mitre.org/data/definitions/248.html) +* [CWE-252 Valeur de retour non vérifiée](https://cwe.mitre.org/data/definitions/252.html) +* [CWE-274 Gestion incorrecte de privilèges insuffisants](https://cwe.mitre.org/data/definitions/274.html) +* [CWE-280 Gestion incorrecte de permissions ou privilèges insuffisants](https://cwe.mitre.org/data/definitions/280.html) +* [CWE-369 Division par zéro](https://cwe.mitre.org/data/definitions/369.html) +* [CWE-390 Détection d'une condition d'erreur sans action](https://cwe.mitre.org/data/definitions/390.html) +* [CWE-391 Condition d'erreur non vérifiée](https://cwe.mitre.org/data/definitions/391.html) +* [CWE-394 Code d'état ou valeur de retour inattendu](https://cwe.mitre.org/data/definitions/394.html) +* [CWE-396 Déclaration d'interception d'une exception générique](https://cwe.mitre.org/data/definitions/396.html) +* [CWE-397 Déclaration de levée d'une exception générique](https://cwe.mitre.org/data/definitions/397.html) +* [CWE-460 Nettoyage incorrect lors du déclenchement d'une exception](https://cwe.mitre.org/data/definitions/460.html) +* [CWE-476 Déréférencement d'un pointeur NULL](https://cwe.mitre.org/data/definitions/476.html) +* [CWE-478 Cas par défaut manquant dans une expression conditionnelle multiple](https://cwe.mitre.org/data/definitions/478.html) +* [CWE-484 Instruction break omise dans un switch](https://cwe.mitre.org/data/definitions/484.html) +* [CWE-550 Message d'erreur généré par le serveur contenant des informations sensibles](https://cwe.mitre.org/data/definitions/550.html) +* [CWE-636 Absence d'échec sécurisé (« échec par ouverture »)](https://cwe.mitre.org/data/definitions/636.html) +* [CWE-703 Vérification ou gestion incorrecte de conditions exceptionnelles](https://cwe.mitre.org/data/definitions/703.html) +* [CWE-754 Vérification incorrecte de conditions inhabituelles ou exceptionnelles](https://cwe.mitre.org/data/definitions/754.html) +* [CWE-755 Gestion incorrecte de conditions exceptionnelles](https://cwe.mitre.org/data/definitions/755.html) +* [CWE-756 Page d'erreur personnalisée manquante](https://cwe.mitre.org/data/definitions/756.html) diff --git a/2025/docs/fr/TRADUCTION.md b/2025/docs/fr/TRADUCTION.md new file mode 100644 index 000000000..3af70566c --- /dev/null +++ b/2025/docs/fr/TRADUCTION.md @@ -0,0 +1,60 @@ +# Référentiel des choix de traduction + +Ce document consigne les choix terminologiques appliqués à la traduction française du Top 10 2025. Il permet de vérifier les formulations retenues lorsqu'une traduction littérale, la terminologie OWASP existante et l'usage technique français ne coïncident pas. + +La référence historique est [`2017/fr/TRADUCTION.md`](../../../2017/fr/TRADUCTION.md), complétée par les formulations employées dans les documents français du Top 10 2017. La valeur de la colonne **Choix 2025** est la forme canonique utilisée dans les pages françaises de cette édition. + +| Terme source | Formulation antérieure ou alternative | Choix 2025 | Motif | +| --- | --- | --- | --- | +| Broken Access Control | « Manque dans le contrôle d'accès » ; « contrôle d'accès défaillant » | **Contrôles d'accès défaillants** | Reprend le wording déjà présent dans l'index 2025 et la notion de contrôle au sens collectif. | +| Security Misconfiguration | « Configurations défaillantes » | **Mauvaise configuration de sécurité** | Formulation explicite et cohérente avec le titre historique A6:2017. | +| Software Supply Chain Failures | « Nomenclature logicielle » ; « chaîne logistique logicielle » | **Défaillances de la chaîne d'approvisionnement logicielle** | *Supply chain* désigne l'écosystème de dépendances, de compilation et de distribution ; « nomenclature » désigne plutôt un SBOM et ne couvre pas le risque. | +| Cryptographic Failures | « Erreurs cryptographiques » | **Défaillances cryptographiques** | « Défaillances » reste aligné avec les titres du Top 10 et couvre les erreurs, les absences de chiffrement et la gestion des clés. | +| Authentication Failures | « Authentification de mauvaise qualité » ; « authentification défaillante » | **Défaillances de l'authentification** | Le titre 2025 porte sur l'ensemble des mécanismes d'authentification, pas uniquement sur les mots de passe. | +| Software or Data Integrity Failures | « Manque d'intégrité des données ou du logiciel » | **Défaillances d'intégrité du logiciel ou des données** | « Défaillances » décrit la cause racine ; l'ordre suit le titre anglais 2025 et distingue cette catégorie de la chaîne d'approvisionnement. | +| Security Logging & Alerting Failures | « Journalisation et surveillance insuffisantes » | **Défaillances de la journalisation et des alertes de sécurité** | *Alerting* n'est pas seulement de la surveillance : il s'agit du déclenchement d'une action à partir d'un événement pertinent. | +| Mishandling of Exceptional Conditions | « Mauvaise gestion des exceptions » | **Mauvaise gestion des conditions exceptionnelles** | La catégorie inclut plus que les exceptions de code : erreurs logiques, états anormaux, échecs par ouverture et conditions inattendues. | +| Lack of Application Resilience | « Déni de service » ; « manque de résilience applicative » | **Manque de résilience des applications** | Le nom 2025 exprime la cause racine plutôt que le symptôme « déni de service ». | +| Memory Management Failures | — | **Défaillances de la gestion de la mémoire** | Forme nominale cohérente avec les autres catégories et suffisamment large pour couvrir les dépassements, fuites et utilisations après libération. | +| Exploitability | « Exploitation » | **Exploitabilité** | Terme technique précis pour la facilité avec laquelle une faiblesse peut être exploitée ; « exploitation » peut désigner l'action elle-même. | +| Incidence Rate | « Fréquence » (pour *prevalence* dans la version 2017) | **Taux d'incidence** | Le document 2025 définit explicitement l'incidence comme le pourcentage d'applications concernées, indépendamment du nombre d'occurrences. | +| Detectability | « Détection » | **Détectabilité** | Désigne la facilité de détecter une faiblesse, et non l'activité de détection. | +| Ranking movement | « from #3 to #5 » | **de la 3e à la 5e place** | La mention « place » apparaît une seule fois, après le second rang ; cette forme est plus naturelle que « de la 3e place à la 5e place ». | +| Technical Impact / Business Impact | « Impact technique / impact métier » | **Impact technique / impact métier** | Formulation historique conservée. | +| Security Weakness / Vulnerability | « Vulnérabilité » | **Faiblesse** pour une CWE ; **vulnérabilité** lorsque le texte parle d'une vulnérabilité exploitable | CWE signifie *Common Weakness Enumeration* ; « faiblesse » respecte cette distinction, tandis que « vulnérabilité » reste naturel pour les descriptions et scénarios. | +| Threat Agents / Attack Vectors | « Facteurs de menace / vecteurs d'attaque » | **Acteurs de la menace / vecteurs d'attaque** | *Threat agent* désigne l'acteur ou la source de la menace, pas un facteur abstrait. | +| Threat Modeling | « Modélisation des menaces » | **Modélisation des menaces** | Formulation déjà employée dans les ressources OWASP en français. | +| Security Logging / Monitoring / Alerting | « Journalisation / surveillance / alertes » | **Journalisation / surveillance / alertes** | Les trois fonctions sont conservées séparément lorsqu'elles apparaissent ensemble. | +| Failing Open / Failing Closed | « Échec par ouverture / échec par fermeture » | **Échec par ouverture / échec par fermeture** | Traduction explicite et symétrique ; « autoriser par défaut » et « refuser par défaut » sont utilisés dans les recommandations lorsque le contexte l'exige. | +| Secure by Design | « Sécurité dès la conception » | **Sécurité par la conception** | Formulation courte retenue dans les titres et les descriptions ; le sens est expliqué dans la page A06. | +| Security Champion | « Champion de sécurité » | **Référent sécurité** | Terme plus naturel en français pour une personne qui porte la sécurité au sein d'une équipe. | +| Software Bill of Materials (SBOM) | « Nomenclature logicielle » | **Software Bill of Materials (SBOM)** | Le sigle et le terme international sont conservés pour permettre la recherche et éviter de confondre le SBOM avec la chaîne d'approvisionnement. | +| Resilience | « Résilience » | **Résilience** | Terme technique consacré ; la catégorie X01 utilise « résilience des applications ». | +| Common Weakness Enumeration (CWE) | « Common Weakness Enumerations » conservé en anglais dans les versions précédentes | **CWE** dans le texte courant ; « énumération des faiblesses courantes » uniquement lors d'une définition | Les éditions précédentes utilisent surtout le sigle ou le nom anglais. Éviter des formulations lourdes comme « une des 40 énumérations des faiblesses courantes ». | +| Server-Side Request Forgery (SSRF) | **Falsification de requête côté serveur (SSRF)** en 2021 | **Falsification de requête côté serveur (SSRF)** | La formulation reprend directement le titre français A10:2021 ; le sigle SSRF et le nom anglais officiel sont conservés lorsqu'ils sont nécessaires à la recherche. | +| Vibe coding | — | **Vibe coding** | L'expression est conservée comme nom de pratique émergente, avec une explication en français et des guillemets au premier emploi. | + +## Règles de cohérence + +* Les sigles et noms techniques (OWASP, CWE, CVE, CVSS, NVD, API, CORS, CSRF, SSRF, JWT, MFA, SSO, SLO, TLS, HSTS, SBOM, CI/CD, SAST, DAST, IAST, RAG et MCP) sont conservés. +* Les noms de produits, normes, projets et ressources sont conservés dans leur forme officielle ; leur fonction peut être traduite dans le texte qui les accompagne. +* Les titres de CWE sont traduits, mais leur identifiant et leur lien MITRE sont inchangés. +* Les exemples de code, commandes, URL, noms de paramètres et valeurs de configuration restent inchangés. +* Les pourcentages et les scores numériques restent ceux de la source ; les nombres dans le texte courant utilisent la convention française lorsque cela améliore la lisibilité. +* Les nombres décimaux utilisent une virgule (`3,80`) et le signe de pourcentage est précédé d'une espace (`3,80 %`). Si la succession d'une virgule de phrase et d'une virgule décimale alourdit la lecture, la phrase est reformulée ; le point décimal anglais n'est pas introduit. + +## Incohérences de la source à vérifier + +Ces points ne relèvent pas d'un choix de traduction, mais les versions anglaises consultées ne sont pas entièrement cohérentes. Ils sont conservés dans les pages françaises afin de ne pas modifier silencieusement le contenu source. + +* **A03 :** le paragraphe de contexte cite *CWE-477 - Use of Obsolete Function*, tandis que la liste des CWE associées cite *CWE-447 - Use of Obsolete Function*. La valeur et le lien MITRE corrects doivent être confirmés avant publication. +* **A05 / Introduction :** l'introduction générale parle de 38 CWE pour A05, alors que la page A05 et son tableau indiquent 37 CWE. La valeur de référence doit être confirmée. +* **A04 :** le paragraphe de contexte annonce trois CWE, mais énumère quatre identifiants (CWE-327, CWE-331, CWE-1241 et CWE-338). Le nombre ou la liste doit être confirmé. +* **X01 :** le tableau et le contexte annoncent 16 CWE, mais la liste publiée dans la source contient davantage d'éléments qui semblent provenir d'une autre catégorie. La liste complète doit être confirmée. + +## Cohérence grammaticale et éditoriale + +* Les versions françaises 2017 et 2021 emploient déjà **nous** pour la voix du projet et **vous** pour les conseils adressés à l'organisation ou au lecteur ; cette distinction est reconduite en 2025. +* Les recommandations destinées au lectorat utilisent **vous**, **votre** et **vos**. +* La description de la méthodologie et les décisions de l'équipe OWASP utilisent **nous**, **notre** et **nos** lorsqu'il s'agit bien de la voix des auteurs. +* Les accords des participes passés avec **avoir** et **être** ont été relus dans les pages françaises ; les corrections ponctuelles sont conservées dans des commits distincts par fichier. diff --git a/2025/docs/fr/X01_2025-Next_Steps.md b/2025/docs/fr/X01_2025-Next_Steps.md index 49d350e68..818b42cab 100644 --- a/2025/docs/fr/X01_2025-Next_Steps.md +++ b/2025/docs/fr/X01_2025-Next_Steps.md @@ -1,39 +1,36 @@ -# Next Steps +# Étapes suivantes -By design, the OWASP Top 10 is innately limited to the ten most significant risks. Every OWASP Top 10 has “on the cusp” risks considered at length for inclusion, but in the end, didn't make the cut. The other risks were more prevalent and impactful. +Par conception, le Top 10 de l'OWASP est limité aux dix risques les plus importants. Chaque édition du Top 10 examine longuement des risques « à la frontière » susceptibles d'être inclus, mais qui ne sont finalement pas retenus. D'autres risques se sont révélés plus fréquents et plus impactants. -The following two issues are well worth the effort to identify and remediate, organizations working towards a mature appsec program, security consultancies, or tool vendors wishing to expand coverage for their offerings. +Les deux sujets suivants méritent largement les efforts des organisations qui travaillent à la maturité de leur programme AppSec, des cabinets de conseil en sécurité ou des éditeurs d'outils qui souhaitent élargir la couverture de leurs offres. +## X01:2025 Manque de résilience des applications -## X01:2025 Lack of Application Resilience +### Contexte -### Background. - -This is a renaming of 2021’s Denial of Service. That was renamed as it described a symptom rather than a root cause. This category focuses on CWEs that describe weaknesses that are related to resilience issues. The scoring of this category was very close with A10:2025-Mishandling of Exceptional Conditions. Relevant CWEs include: *CWE-400 Uncontrolled Resource Consumption, CWE-409 Improper Handling of Highly Compressed Data (Data Amplification), CWE-674 Uncontrolled Recursion*, and *CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop').* - - -### Score table. +Il s'agit d'un changement de nom du déni de service de 2021. Cette catégorie a été renommée car le déni de service décrivait un symptôme plutôt qu'une cause racine. Elle se concentre sur les CWE qui décrivent des faiblesses liées aux problèmes de résilience. Le score de cette catégorie était très proche de celui de A10:2025 - Mauvaise gestion des conditions exceptionnelles. Les CWE pertinentes comprennent : *CWE-400 : consommation de ressources non contrôlée*, *CWE-409 : gestion incorrecte de données fortement compressées (amplification des données)*, *CWE-674 : récursion non contrôlée* et *CWE-835 : boucle dont la condition de sortie est inaccessible (« boucle infinie »)*. +### Tableau des scores - - - - - - - - - @@ -58,126 +55,120 @@ This is a renaming of 2021’s Denial of Service. That was renamed as it describ
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+### Description +Cette catégorie représente une faiblesse systémique de la manière dont les applications réagissent aux contraintes, aux défaillances et aux cas limites dont elles ne peuvent pas se remettre. Lorsqu'une application ne gère pas correctement, ne supporte pas ou ne surmonte pas les conditions inattendues, les contraintes de ressources et les autres événements défavorables, cela peut facilement entraîner des problèmes de disponibilité (le plus souvent), mais aussi une corruption des données, la divulgation d'informations sensibles, des défaillances en cascade et/ou le contournement de contrôles de sécurité. -### Description. - -This category represents a systemic weakness in how applications respond to stress, failures, and edge cases that it is unable to recover from failure. When an application does not gracefully handle, withstand, or recover from unexpected conditions, resource constraints, and other adverse events it can easily result in availability issues (most commonly), but also data corruption, sensitive data disclosure, cascading failures, and/or bypasses of security controls. +En outre, [X02:2025 - Défaillances de la gestion de la mémoire](#x022025-défaillances-de-la-gestion-de-la-mémoire) peut également provoquer la défaillance de l'application, voire du système entier. -Furthermore [X02:2025 Memory Management Failures](#x022025-memory-management-failures) can also lead to failure of the application or even the entire system. +### Comment s'en prémunir -### How to prevent +Pour prévenir ce type de vulnérabilité, vous devez concevoir vos systèmes en prévoyant les défaillances et la reprise : -In order to prevent this type of vulnerability you must design for failure and recovery of your systems. +* ajouter des limites, des quotas et des mécanismes de basculement, en accordant une attention particulière aux opérations qui consomment le plus de ressources ; +* identifier les pages gourmandes en ressources et planifier en conséquence : réduire la surface d'attaque, notamment en n'exposant pas aux utilisateurs inconnus ou non fiables les gadgets et fonctions inutiles qui nécessitent beaucoup de ressources (par exemple du processeur ou de la mémoire) ; +* effectuer une validation stricte des entrées à l'aide de listes d'autorisation et de limites de taille, puis tester rigoureusement ; +* limiter la taille des réponses et ne jamais renvoyer de réponses brutes au client (les traiter côté serveur) ; +* choisir par défaut un état sûr et fermé (jamais ouvert), refuser par défaut et annuler en cas d'erreur ; +* éviter les appels synchrones bloquants dans les threads de requête (utiliser l'asynchrone ou le non-bloquant, prévoir des délais d'expiration, des limites de concurrence, etc.) ; +* tester soigneusement les fonctionnalités de gestion des erreurs ; +* implémenter des modèles de résilience tels que les coupe-circuits, les cloisons, la logique de nouvelle tentative et la dégradation progressive ; +* effectuer des tests de performance et de charge ; ajouter de l'ingénierie du chaos si votre appétence au risque le permet ; +* implémenter et concevoir une redondance lorsque cela est raisonnable et financièrement abordable ; +* implémenter la surveillance, l'observabilité et les alertes ; +* filtrer les adresses d'expéditeur invalides conformément à la RFC 2267 ; +* bloquer les botnets connus à partir de leurs empreintes, de leurs adresses IP ou dynamiquement selon leur comportement ; +* preuve de travail : lancer du côté des *attaquants* les opérations consommatrices de ressources, afin qu'elles aient peu d'impact sur les utilisateurs normaux mais affectent les bots qui tentent d'envoyer un grand nombre de requêtes. Rendre la preuve de travail plus difficile lorsque la charge générale du système augmente, notamment pour les systèmes moins fiables ou qui semblent être pilotés par des bots ; +* limiter la durée des sessions côté serveur en fonction de l'inactivité et prévoir une expiration finale ; +* limiter le stockage des informations liées aux sessions. -* Add limits, quotas, and failover functionality, paying special attention to the most resource consuming operations -* Identify resource intensive pages and plan ahead: Reduce attack surface especially not exposing unneeded ‘gadgets’ and functions that require a lot of resources (e.g. CPU, memory) to unknown or untrusted users -* Perform strict input validation with allow-lists and size limitations, then test thoroughly -* Limit response sizes, and never send raw responses back to the client (process on the server side) -* Default to safe/closed (never open), deny by default and roll back if there’s an error -* Avoid blocking synchronous calls in request threads (use asynchronous/non-blocking, have timeouts, have concurrency limits, etc.) -* Carefully test your error handling functionality -* Implement resilience patterns such as circuit breakers, bulkheads, retry logic, and graceful degradation -* Do performance and load testing; add chaos engineering if you have the risk appetite for it -* Implement and architect for redundancy where reasonable and affordable -* Implement monitoring, observability, and alerting -* Filter invalid sender addresses in accordance with RFC 2267 -* Block known botnets by finger prints, IPs, or dynamically by behavior -* Proof-of-Work: initiate resource consuming operations at the *attackers* side that does not have big impacts on normal users but impacts bots trying to send a huge amount of requests. Make the Proof-of-Work more difficult if the general load of the system raises, especially for systems that are less trustworthy or appear to be bots -* Limit server side session time based on inactivity and a final timeout -* Limit session bound information storage +### Exemples de scénarios d'attaque +**Scénario n° 1 :** les attaquants consomment intentionnellement des ressources applicatives pour provoquer des défaillances dans le système, ce qui entraîne un déni de service. Il peut s'agir de l'épuisement de la mémoire, du remplissage de l'espace disque, de la saturation du processeur ou de l'ouverture d'un nombre illimité de connexions. -### Example attack scenarios. +**Scénario n° 2 :** le fuzzing des entrées conduit à des réponses conçues pour perturber la logique métier de l'application. -**Scenario #1:** Attackers intentionally consume application resources to trigger failures within the system, resulting in denial of service. This could be memory exhaustion, filling up disk space, CPU saturation, or opening endless connections. +**Scénario n° 3 :** les attaquants ciblent les dépendances de l'application, mettent hors service des API ou d'autres services externes et empêchent l'application de continuer à fonctionner. -**Scenario #2:** Input fuzzing that leads to crafted responses that break application business logic. +### Références -**Scenario #3:** Attackers focus on the application’s dependencies, taking down APIs or other external services, and the application is unable to continue. - - -### References. - -* [OWASP Cheat Sheet: Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) +* [Aide-mémoire OWASP : déni de service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) * [OWASP MASVS‑RESILIENCE](https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/) -* [ASP.NET Core Best Practices (Microsoft)](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices?view=aspnetcore-9.0) -* [Resilience in Microservices: Bulkhead vs Circuit Breaker (Parser)](https://medium.com/@parserdigital/resilience-in-microservices-bulkhead-vs-circuit-breaker-54364c1f9d53) -* [Bulkhead Pattern (Geeks for Geeks)](https://www.geeksforgeeks.org/system-design/bulkhead-pattern/) +* [Bonnes pratiques ASP.NET Core (Microsoft)](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices?view=aspnetcore-9.0) +* [Résilience des microservices : cloison contre coupe-circuit (Parser)](https://medium.com/@parserdigital/resilience-in-microservices-bulkhead-vs-circuit-breaker-54364c1f9d53) +* [Modèle de cloison (Geeks for Geeks)](https://www.geeksforgeeks.org/system-design/bulkhead-pattern/) * [NIST Cybersecurity Framework (CSF)](https://www.nist.gov/cyberframework) -* [Avoid Blocking Calls: Go Async in Java (Devlane)](https://www.devlane.com/blog/avoid-blocking-calls-go-async-in-java) - -### List of Mapped CWEs -* [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) -* [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) -* [CWE-256 Plaintext Storage of a Password](https://cwe.mitre.org/data/definitions/256.html) -* [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) -* [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) -* [CWE-286 Incorrect User Management](https://cwe.mitre.org/data/definitions/286.html) -* [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) -* [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) -* [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) -* [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) -* [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html) -* [CWE-382 J2EE Bad Practices: Use of System.exit()](https://cwe.mitre.org/data/definitions/382.html) -* [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) -* [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) -* [CWE-436 Interpretation Conflict](https://cwe.mitre.org/data/definitions/436.html) -* [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')](https://cwe.mitre.org/data/definitions/444.html) -* [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) -* [CWE-454 External Initialization of Trusted Variables or Data Stores](https://cwe.mitre.org/data/definitions/454.html) -* [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) -* [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) -* [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) -* [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) -* [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) -* [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) -* [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) -* [CWE-628 Function Call with Incorrectly Specified Arguments](https://cwe.mitre.org/data/definitions/628.html) -* [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) -* [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) -* [CWE-653 Improper Isolation or Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) -* [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) -* [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) -* [CWE-676 Use of Potentially Dangerous Function](https://cwe.mitre.org/data/definitions/676.html) -* [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) -* [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) -* [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) -* [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) -* [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) -* [CWE-1022 Use of Web Link to Untrusted Target with window.opener Access](https://cwe.mitre.org/data/definitions/1022.html) -* [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) - - -## X02:2025 Memory Management Failures - -### Background. - -Languagess like Java, C#, JavaScript/TypeScript (node.js), Go, and "safe" Rust are memory safe. Memory management problems tend to happen in non-memory safe languages such as C and C++. This category scored the lowest on the community survey and low in the data despite having the third most related CVEs. We believe this is due to the predominance of web applications over more traditional desktop applications. Memory management vulnerabilities frequently have the highest CVSS scores. - - -### Score table. - +* [Éviter les appels bloquants : passer à l'asynchrone en Java (Devlane)](https://www.devlane.com/blog/avoid-blocking-calls-go-async-in-java) + +### Liste des CWE associées + +* [CWE-73 Contrôle externe du nom ou du chemin d'un fichier](https://cwe.mitre.org/data/definitions/73.html) +* [CWE-183 Liste permissive des entrées autorisées](https://cwe.mitre.org/data/definitions/183.html) +* [CWE-256 Stockage en clair d'un mot de passe](https://cwe.mitre.org/data/definitions/256.html) +* [CWE-266 Attribution incorrecte de privilèges](https://cwe.mitre.org/data/definitions/266.html) +* [CWE-269 Gestion incorrecte des privilèges](https://cwe.mitre.org/data/definitions/269.html) +* [CWE-286 Gestion incorrecte des utilisateurs](https://cwe.mitre.org/data/definitions/286.html) +* [CWE-311 Chiffrement manquant de données sensibles](https://cwe.mitre.org/data/definitions/311.html) +* [CWE-312 Stockage en clair d'informations sensibles](https://cwe.mitre.org/data/definitions/312.html) +* [CWE-313 Stockage en clair dans un fichier ou sur un disque](https://cwe.mitre.org/data/definitions/313.html) +* [CWE-316 Stockage en clair d'informations sensibles en mémoire](https://cwe.mitre.org/data/definitions/316.html) +* [CWE-362 Exécution concurrente utilisant une ressource partagée avec une synchronisation incorrecte (« condition de course »)](https://cwe.mitre.org/data/definitions/362.html) +* [CWE-382 Mauvaises pratiques J2EE : utilisation de System.exit()](https://cwe.mitre.org/data/definitions/382.html) +* [CWE-419 Canal principal non protégé](https://cwe.mitre.org/data/definitions/419.html) +* [CWE-434 Téléversement sans restriction de fichiers de type dangereux](https://cwe.mitre.org/data/definitions/434.html) +* [CWE-436 Conflit d'interprétation](https://cwe.mitre.org/data/definitions/436.html) +* [CWE-444 Interprétation incohérente des requêtes HTTP (« désynchronisation des requêtes/réponses HTTP »)](https://cwe.mitre.org/data/definitions/444.html) +* [CWE-451 Présentation incorrecte d'informations critiques dans l'interface utilisateur (UI)](https://cwe.mitre.org/data/definitions/451.html) +* [CWE-454 Initialisation externe de variables ou de magasins de données de confiance](https://cwe.mitre.org/data/definitions/454.html) +* [CWE-472 Contrôle externe d'un paramètre web supposé immuable](https://cwe.mitre.org/data/definitions/472.html) +* [CWE-501 Violation de frontière de confiance](https://cwe.mitre.org/data/definitions/501.html) +* [CWE-522 Identifiants insuffisamment protégés](https://cwe.mitre.org/data/definitions/522.html) +* [CWE-525 Utilisation du cache d'un navigateur web contenant des informations sensibles](https://cwe.mitre.org/data/definitions/525.html) +* [CWE-539 Utilisation de cookies persistants contenant des informations sensibles](https://cwe.mitre.org/data/definitions/539.html) +* [CWE-598 Utilisation de la méthode GET avec des chaînes de requête sensibles](https://cwe.mitre.org/data/definitions/598.html) +* [CWE-602 Application côté client de la sécurité côté serveur](https://cwe.mitre.org/data/definitions/602.html) +* [CWE-628 Appel de fonction avec des arguments spécifiés incorrectement](https://cwe.mitre.org/data/definitions/628.html) +* [CWE-642 Contrôle externe de données d'état critiques](https://cwe.mitre.org/data/definitions/642.html) +* [CWE-646 Dépendance au nom ou à l'extension d'un fichier fourni de l'extérieur](https://cwe.mitre.org/data/definitions/646.html) +* [CWE-653 Isolation ou compartimentage incorrect](https://cwe.mitre.org/data/definitions/653.html) +* [CWE-656 Dépendance à la sécurité par l'obscurité](https://cwe.mitre.org/data/definitions/656.html) +* [CWE-657 Violation des principes de conception sécurisée](https://cwe.mitre.org/data/definitions/657.html) +* [CWE-676 Utilisation d'une fonction potentiellement dangereuse](https://cwe.mitre.org/data/definitions/676.html) +* [CWE-693 Défaillance d'un mécanisme de protection](https://cwe.mitre.org/data/definitions/693.html) +* [CWE-799 Contrôle incorrect de la fréquence des interactions](https://cwe.mitre.org/data/definitions/799.html) +* [CWE-807 Dépendance à des entrées non fiables dans une décision de sécurité](https://cwe.mitre.org/data/definitions/807.html) +* [CWE-841 Application incorrecte d'un flux comportemental](https://cwe.mitre.org/data/definitions/841.html) +* [CWE-1021 Restriction incorrecte des couches ou cadres d'interface utilisateur rendus](https://cwe.mitre.org/data/definitions/1021.html) +* [CWE-1022 Utilisation d'un lien web vers une cible non fiable avec accès à window.opener](https://cwe.mitre.org/data/definitions/1022.html) +* [CWE-1125 Surface d'attaque excessive](https://cwe.mitre.org/data/definitions/1125.html) + +## X02:2025 Défaillances de la gestion de la mémoire + +### Contexte + +Des langages comme Java, C#, JavaScript/TypeScript (Node.js), Go et Rust dans son sous-ensemble sûr garantissent la sécurité de la mémoire. Les problèmes de gestion de la mémoire surviennent surtout dans les langages qui ne garantissent pas cette sécurité, comme C et C++. Cette catégorie a obtenu le score le plus faible dans l'enquête communautaire et un score faible dans les données, malgré le troisième plus grand nombre de CVE associés. Nous pensons que cela s'explique par la prédominance des applications web sur les applications de bureau plus traditionnelles. Les vulnérabilités de gestion de la mémoire obtiennent fréquemment les scores CVSS les plus élevés. + +### Tableau des scores - - - - - - - - - @@ -202,123 +193,117 @@ Languagess like Java, C#, JavaScript/TypeScript (node.js), Go, and "safe" Rust a
CWEs Mapped + CWE associées Max Incidence Rate + Taux d'incidence maximal Avg Incidence Rate + Taux d'incidence moyen Max Coverage + Couverture maximale Avg Coverage + Couverture moyenne Avg Weighted Exploit + Exploitabilité moyenne pondérée Avg Weighted Impact + Impact moyen pondéré Total Occurrences + Total des occurrences Total CVEs + Total des CVE
+### Description +Lorsqu'une application doit gérer elle-même la mémoire, il est très facile de commettre des erreurs. Les langages sûrs pour la mémoire sont de plus en plus utilisés, mais de nombreux systèmes anciens sont encore en production dans le monde entier, de nouveaux systèmes bas niveau nécessitent l'utilisation de langages qui ne garantissent pas la sécurité de la mémoire, et des applications web interagissent avec des mainframes, des appareils IoT, des micrologiciels et d'autres systèmes qui peuvent être contraints de gérer leur propre mémoire. Parmi les CWE représentatives figurent *CWE-120 : copie d'un tampon sans vérification de la taille de l'entrée (« dépassement de tampon classique »)* et *CWE-121 : dépassement de tampon fondé sur la pile*. -### Description. - -When an application is forced to manage memory itself, it is very easy to make mistakes. Memory safe languages are being used more often, but there are still many legacy systems in production worldwide, new low-level systems that require the use of non-memory safe languages, and web applications that interact with mainframes, IoT devices, firmware, and other systems that may be forced to manage their own memory. Representative CWEs are *CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')* and *CWE-121 Stack-based Buffer Overflow*. - -Memory management failures can happen when: - -* You do not allocate enough memory for a variable -* You do not validate input, causing an overflow of the heap, the stack, a buffer -* You store a data value that is larger than the type of the variable can hold -* You attempt to use unallocated memory or address spaces -* You create off-by-one errors (counting from 1 instead of zero) -* You try to access an object after its been freed -* You use uninitialized variables -* You leak memory or otherwise use up all available memory in error until our application fails - -Memory management failures can lead to failure of the application or even the entire system, see also [X01:2025 Lack of Application Resilience](#x012025-lack-of-application-resilience) - - -### How to prevent. - -The best way to prevent memory management failures is to use a memory-safe language. Examples include Rust, Java, Go, C#, Python, Swift, Kotlin, JavaScript, etc. When creating new applications, try hard to convince your organization that it is worth the learning curve to switch to a memory-safe language. If performing a full refactor, push for a rewrite in a memory-safe language when it is possible and feasible. +Les défaillances de gestion de la mémoire peuvent se produire lorsque : -If you are unable to use a memory-safe language, perform the following: +* vous n'allouez pas assez de mémoire pour une variable ; +* vous ne validez pas les entrées, ce qui provoque un dépassement du tas, de la pile ou d'un tampon ; +* vous stockez une valeur de données plus grande que ce que le type de la variable peut contenir ; +* vous tentez d'utiliser une mémoire ou un espace d'adressage non alloué ; +* vous créez des erreurs de décalage d'une unité (vous comptez à partir de 1 au lieu de zéro) ; +* vous tentez d'accéder à un objet après sa libération ; +* vous utilisez des variables non initialisées ; +* vous fuyez de la mémoire ou utilisez toute la mémoire disponible à la suite d'une erreur, jusqu'à faire échouer votre application. -* Enable the following server features that make memory management errors harder to exploit: address space layout randomization (ASLR), Data Execution Protection (DEP), and Structured Exception Handling Overwrite Protection (SEHOP). -* Monitor your application for memory leaks. -* Validate all input to your system very carefully, and reject all input that does not meet expectations. -* Study the language you are using and make a list of unsafe and more-safe functions, then share that list with your entire team. If possible, add it to your secure coding guideline or standard. For example, in C, prefer strncpy() over strcpy() and strncat() over strcat(). -* If your language or framework offers memory safety libraries, use them. For example: Safestringlib or SafeStr. -* Use managed buffers and strings rather than raw arrays and pointers whenever possible. -* Take secure coding training that focuses on memory issues and/or your language of choice. Inform your trainer that you are concerned about memory management failures. -* Perform code reviews and/or static analyses. -* Use compiler tools that help with memory management such as StackShield, StackGuard, and Libsafe. -* Perform fuzzing on every input to your system. -* If you have a penetration test performed, inform your tester that you are concerned about memory management failures and that you would like them to pay special attention to this while testing. -* Fix all compiler errors *and* warnings. Do not ignore warnings because your program compiles. -* Ensure your underlying infrastructure is regularly patched, scanned, and hardened. -* Monitor your underlying infrastructure specifically for potential memory vulnerabilities and other failures. -* Consider using [canaries](https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries) to protect your address stack from overflow attacks. +Les défaillances de gestion de la mémoire peuvent entraîner la défaillance de l'application, voire du système entier ; voir également [X01:2025 - Manque de résilience des applications](#x012025-manque-de-résilience-des-applications). -### Example attack scenarios. +### Comment s'en prémunir -**Scenario #1:** Buffer overflows are the most famous memory vulnerability, a situation where an attacker submits more information into a field than it can accept, such that it overflows the buffer created for the underlying variable. In a successful attack, the overflow characters overwrite the stack pointer, allowing the attacker to insert malicious instructions into your program. +Le meilleur moyen de prévenir les défaillances de gestion de la mémoire est d'utiliser un langage sûr pour la mémoire. Rust, Java, Go, C#, Python, Swift, Kotlin et JavaScript en sont des exemples. Lors de la création de nouvelles applications, efforcez-vous de convaincre votre organisation que la courbe d'apprentissage justifie le passage à un langage sûr pour la mémoire. En cas de refonte complète, préconisez la réécriture dans un langage sûr pour la mémoire lorsque cela est possible et réalisable. -**Scenario #2:** Use-After-Free (UAF) happens often enough that it’s a semi-common browser bug bounty submission. Imagine a web browser processing JavaScript that manipulates DOM elements. The attacker crafts a JavaScript payload that creates an object (such as a DOM element) and obtains references to it. Through careful manipulation, they trigger the browser to free the object's memory while keeping a dangling pointer to it. Before the browser realizes the memory has been freed, the attacker allocates a new object that occupies the *same* memory space. When the browser tries to use the original pointer, it now points to attacker-controlled data. If this pointer was for a virtual function table, the attacker can redirect code execution to their payload. +Si vous ne pouvez pas utiliser un langage sûr pour la mémoire, effectuez les opérations suivantes : -**Scenario #3:** A network service that accepts user input, doesn’t properly validate or sanitize it, then passes it directly to the logging function. The input from the user is passed to the logging function as syslog(user_input) instead of syslog("%s", user_input), which doesn’t specify the format. The attacker sends malicious payloads containing format specifiers such as %x to read stack memory (sensitive data disclosure) or %n to write to memory addresses. By chaining together multiple format specifiers they could map out the stack, locate important addresses, and then overwrite them. This would be a Format string vulnerability (uncontrolled string format). +* activer les fonctionnalités serveur qui rendent les erreurs de gestion de la mémoire plus difficiles à exploiter : randomisation de l'espace d'adressage (ASLR), protection contre l'exécution des données (DEP) et protection contre l'écrasement de la gestion structurée des exceptions (SEHOP) ; +* surveiller l'application à la recherche de fuites de mémoire ; +* valider très soigneusement toutes les entrées du système et rejeter toute entrée qui ne respecte pas les attentes ; +* étudier le langage utilisé et dresser une liste des fonctions non sûres et plus sûres, puis la partager avec toute l'équipe. Si possible, l'ajouter aux recommandations ou à la norme de codage sécurisé. Par exemple, en C, préférer `strncpy()` à `strcpy()` et `strncat()` à `strcat()` ; +* utiliser les bibliothèques de sécurité mémoire proposées par le langage ou le framework, par exemple Safestringlib ou SafeStr ; +* utiliser autant que possible des tampons et chaînes gérés plutôt que des tableaux et pointeurs bruts ; +* suivre une formation au codage sécurisé centrée sur les problèmes de mémoire et/ou sur le langage choisi. Informer le formateur de vos préoccupations concernant les défaillances de gestion de la mémoire ; +* effectuer des revues de code et/ou des analyses statiques ; +* utiliser des outils du compilateur qui facilitent la gestion de la mémoire, tels que StackShield, StackGuard et Libsafe ; +* effectuer un fuzzing sur chaque entrée du système ; +* si un test d'intrusion est réalisé, informer le testeur de vos préoccupations concernant les défaillances de gestion de la mémoire et lui demander d'y prêter une attention particulière ; +* corriger toutes les erreurs et tous les avertissements du compilateur. Ne pas ignorer les avertissements sous prétexte que le programme compile ; +* s'assurer que l'infrastructure sous-jacente est régulièrement corrigée, analysée et renforcée ; +* surveiller spécifiquement l'infrastructure sous-jacente pour détecter les vulnérabilités mémoire potentielles et autres défaillances ; +* envisager d'utiliser des [canaris](https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries) pour protéger la pile d'adresses contre les attaques par dépassement. -Note: modern browsers use many levels of defenses to defend against such attacks, including [browser sandboxing](https://www.geeksforgeeks.org/ethical-hacking/what-is-browser-sandboxing/#types-of-browser-sandboxing) ASLR, DEP/NX, RELRO, and PIE. A memory management failure attack on a browser is not a simple attack to carry out. +### Exemples de scénarios d'attaque -### References. +**Scénario n° 1 :** les dépassements de tampon sont la vulnérabilité mémoire la plus connue. Un attaquant soumet davantage d'informations dans un champ que celui-ci ne peut en accepter, ce qui fait déborder le tampon créé pour la variable sous-jacente. Lors d'une attaque réussie, les caractères en dépassement écrasent le pointeur de pile, permettant à l'attaquant d'insérer des instructions malveillantes dans le programme. -* [OWASP community pages: Memory leak,](https://owasp.org/www-community/vulnerabilities/Memory_leak) [Doubly freeing memory,](https://owasp.org/www-community/vulnerabilities/Doubly_freeing_memory) [& Buffer Overflow](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) -* [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) -* [Project Zero Blog](https://googleprojectzero.blogspot.com) -* [Microsoft MSRC Blog](https://www.microsoft.com/en-us/msrc/blog) +**Scénario n° 2 :** l'utilisation après libération (Use-After-Free, UAF) est suffisamment fréquente pour constituer un signalement semi-courant dans les programmes de bug bounty des navigateurs. Imaginez un navigateur web qui traite du JavaScript manipulant des éléments du DOM. L'attaquant élabore une charge JavaScript qui crée un objet (par exemple un élément DOM) et obtient des références vers celui-ci. Par une manipulation soigneuse, il force le navigateur à libérer la mémoire de l'objet tout en conservant un pointeur pendant. Avant que le navigateur ne réalise que la mémoire a été libérée, l'attaquant alloue un nouvel objet qui occupe le même espace mémoire. Lorsque le navigateur tente d'utiliser le pointeur original, celui-ci pointe désormais vers des données contrôlées par l'attaquant. Si ce pointeur correspondait à une table de fonctions virtuelles, l'attaquant peut rediriger l'exécution du code vers sa charge utile. -### List of Mapped CWEs -* [CWE-14 Compiler Removal of Code to Clear Buffers](https://cwe.mitre.org/data/definitions/14.html) -* [CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer](https://cwe.mitre.org/data/definitions/119.html) -* [CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')](https://cwe.mitre.org/data/definitions/120.html) -* [CWE-121 Stack-based Buffer Overflow](https://cwe.mitre.org/data/definitions/121.html) -* [CWE-122 Heap-based Buffer Overflow](https://cwe.mitre.org/data/definitions/122.html) -* [CWE-124 Buffer Underwrite ('Buffer Underflow')](https://cwe.mitre.org/data/definitions/124.html) -* [CWE-125 Out-of-bounds Read](https://cwe.mitre.org/data/definitions/125.html) -* [CWE-126 Buffer Over-read](https://cwe.mitre.org/data/definitions/126.html) -* [CWE-190 Integer Overflow or Wraparound](https://cwe.mitre.org/data/definitions/190.html) -* [CWE-191 Integer Underflow (Wrap or Wraparound)](https://cwe.mitre.org/data/definitions/191.html) -* [CWE-196 Unsigned to Signed Conversion Error](https://cwe.mitre.org/data/definitions/196.html) -* [CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition](https://cwe.mitre.org/data/definitions/367.html) -* [CWE-415 Double Free](https://cwe.mitre.org/data/definitions/415.html) -* [CWE-416 Use After Free](https://cwe.mitre.org/data/definitions/416.html) -* [CWE-457 Use of Uninitialized Variable](https://cwe.mitre.org/data/definitions/457.html) -* [CWE-459 Incomplete Cleanup](https://cwe.mitre.org/data/definitions/459.html) -* [CWE-467 Use of sizeof() on a Pointer Type](https://cwe.mitre.org/data/definitions/467.html) -* [CWE-787 Out-of-bounds Write](https://cwe.mitre.org/data/definitions/787.html) -* [CWE-788 Access of Memory Location After End of Buffer](https://cwe.mitre.org/data/definitions/788.html) -* [CWE-824 Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html) +**Scénario n° 3 :** un service réseau accepte une entrée utilisateur, ne la valide ni ne la nettoie correctement, puis la transmet directement à la fonction de journalisation. L'entrée utilisateur est transmise à la fonction de journalisation sous la forme `syslog(user_input)` au lieu de `syslog("%s", user_input)`, sans spécifier le format. L'attaquant envoie des charges utiles malveillantes contenant des spécificateurs de format tels que `%x` pour lire la mémoire de la pile (divulgation de données sensibles) ou `%n` pour écrire à des adresses mémoire. En combinant plusieurs spécificateurs de format, il peut cartographier la pile, localiser des adresses importantes puis les écraser. Il s'agit d'une vulnérabilité de chaîne de format (format de chaîne non contrôlé). +Remarque : les navigateurs modernes utilisent plusieurs niveaux de défense contre ces attaques, notamment le [bac à sable du navigateur](https://www.geeksforgeeks.org/ethical-hacking/what-is-browser-sandboxing/#types-of-browser-sandboxing), ASLR, DEP/NX, RELRO et PIE. Une attaque par défaillance de gestion de la mémoire contre un navigateur n'est pas simple à réaliser. +### Références -## X03:2025 Inappropriate Trust in AI Generated Code ('Vibe Coding') +* [Pages communautaires OWASP : fuite de mémoire](https://owasp.org/www-community/vulnerabilities/Memory_leak), [double libération de mémoire](https://owasp.org/www-community/vulnerabilities/Doubly_freeing_memory) et [dépassement de tampon](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) +* [Awesome Fuzzing : liste de ressources de fuzzing](https://github.com/secfigo/Awesome-Fuzzing) +* [Blog Project Zero](https://googleprojectzero.blogspot.com) +* [Blog Microsoft MSRC](https://www.microsoft.com/en-us/msrc/blog) -### Background. +### Liste des CWE associées -Currently the entire world is talking about and using AI, and this includes software developers. Although there are currently no CVEs or CWEs related to AI generated code, it is well known and documented that AI generated code often contains more vulnerabilities than code written by human beings. +* [CWE-14 Suppression par le compilateur du code qui efface les tampons](https://cwe.mitre.org/data/definitions/14.html) +* [CWE-119 Restriction incorrecte d'opérations dans les limites d'un tampon mémoire](https://cwe.mitre.org/data/definitions/119.html) +* [CWE-120 Copie d'un tampon sans vérification de la taille de l'entrée (« dépassement de tampon classique »)](https://cwe.mitre.org/data/definitions/120.html) +* [CWE-121 Dépassement de tampon fondé sur la pile](https://cwe.mitre.org/data/definitions/121.html) +* [CWE-122 Dépassement de tampon fondé sur le tas](https://cwe.mitre.org/data/definitions/122.html) +* [CWE-124 Écriture avant le début d'un tampon (« sous-dépassement de tampon »)](https://cwe.mitre.org/data/definitions/124.html) +* [CWE-125 Lecture hors limites](https://cwe.mitre.org/data/definitions/125.html) +* [CWE-126 Lecture au-delà de la fin d'un tampon](https://cwe.mitre.org/data/definitions/126.html) +* [CWE-190 Dépassement ou bouclage d'entier](https://cwe.mitre.org/data/definitions/190.html) +* [CWE-191 Sous-dépassement d'entier (bouclage)](https://cwe.mitre.org/data/definitions/191.html) +* [CWE-196 Erreur de conversion d'un type non signé vers un type signé](https://cwe.mitre.org/data/definitions/196.html) +* [CWE-367 Condition de course entre vérification et utilisation (TOCTOU)](https://cwe.mitre.org/data/definitions/367.html) +* [CWE-415 Double libération](https://cwe.mitre.org/data/definitions/415.html) +* [CWE-416 Utilisation après libération](https://cwe.mitre.org/data/definitions/416.html) +* [CWE-457 Utilisation d'une variable non initialisée](https://cwe.mitre.org/data/definitions/457.html) +* [CWE-459 Nettoyage incomplet](https://cwe.mitre.org/data/definitions/459.html) +* [CWE-467 Utilisation de sizeof() sur un type pointeur](https://cwe.mitre.org/data/definitions/467.html) +* [CWE-787 Écriture hors limites](https://cwe.mitre.org/data/definitions/787.html) +* [CWE-788 Accès à un emplacement mémoire après la fin du tampon](https://cwe.mitre.org/data/definitions/788.html) +* [CWE-824 Accès à un pointeur non initialisé](https://cwe.mitre.org/data/definitions/824.html) +## X03:2025 Confiance inappropriée dans le code généré par l'IA (« vibe coding ») -### Description. +### Contexte -We are seeing software development practices change to include not only code written with the assistance of AI, but code written and committed almost entirely without human oversight (often referred to as vibe coding). Just as it was never a good idea to copy code snippets from blogs or websites without thinking twice, the problem is exacerbated in this case. Good, secure code snippets were and are rare and might be statistically neglected by AI due to system constraints. +Le monde entier parle actuellement de l'IA et l'utilise, notamment les développeurs logiciels. Bien qu'il n'existe actuellement aucun CVE ou CWE lié au code généré par l'IA, il est bien connu et documenté que le code généré par l'IA contient souvent davantage de vulnérabilités que le code écrit par des êtres humains. +### Description -### How to prevent. -We urge all people who write code to consider the following when using AI: +Les pratiques de développement logiciel évoluent pour inclure non seulement du code écrit avec l'aide de l'IA, mais aussi du code écrit et commité presque entièrement sans supervision humaine (ce que l'on appelle souvent le *vibe coding*). De même qu'il n'a jamais été judicieux de copier sans réfléchir des extraits de code depuis des blogs ou des sites web, le problème est ici amplifié. Les extraits de code corrects et sécurisés étaient et restent rares, et peuvent être statistiquement négligés par l'IA en raison de contraintes liées à ses systèmes. -* You should be able to read and fully understand all code you submit, even if it is written by an AI or copied from an online forum. You are responsible for all code that you commit. -* You should review all AI-assisted code thoroughly for vulnerabilities, ideally with your own eyes and also with security tooling made for this purpose (such as static analysis). Consider using classic code review techniques as described in [OWASP Cheat Sheet Series: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). -* Ideally, write your own code, let the AI suggest improvements, check the AI's code, and let the AI make corrections until you are satisfied with the result. -* Consider using a Retrieval Augmented Generation (RAG) server with your own collected and reviewed secure code samples and documentation, such as your organization’s security coding guideline, standard, or policy, and have the RAG server enforce any policies or standards. -* Consider purchasing tooling that implements guardrails for privacy and security for use with your AI(s) of choice. -* Consider purchasing a private AI, ideally with a contract agreement (including a privacy agreement) that the AI is not to be trained on your organization’s data, queries, code or any other sensitive information. -* Consider implementing an Model Context Protocol (MCP) server in-between your IDE and AI, then set it up to enforce the use of your security tooling of choice. -* Implement policies and processes as part of your SDLC to inform developers (and all employees) of how they should and should not use AI within your organization. -* Create a list of good and effective prompts, that take IT security best practices into account. Ideally they should also consider your internal secure coding guidelines. Developers can use this prompts as a starting point for their programs. -* AI is likely to become part of each phase of your system development life cycle, both how to use it effectively and safely. Use it wisely. -* Actually it is **not** recommended to use vibe coding for complex functions, business critical programs, or programs that are used for a long time. -* Implement technical checks and safeguards against the use of Shadow AI. -* Train your developers on your policies, as well as safe AI usage and best practices for using AI in software development. +### Comment s'en prémunir +Nous invitons toutes les personnes qui écrivent du code à tenir compte des éléments suivants lorsqu'elles utilisent l'IA : -### References. +* vous devez pouvoir lire et comprendre entièrement tout le code que vous soumettez, même s'il a été écrit par une IA ou copié depuis un forum en ligne. Vous êtes responsable de tout le code que vous commitez ; +* vous devez examiner soigneusement tout code assisté par l'IA afin d'y rechercher des vulnérabilités, idéalement de vos propres yeux et à l'aide d'outils de sécurité conçus à cet effet (comme l'analyse statique). Envisagez d'utiliser les techniques classiques de revue de code décrites dans la [série d'aide-mémoire OWASP : revue de code sécurisé](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) ; +* dans l'idéal, écrivez votre propre code, laissez l'IA proposer des améliorations, vérifiez le code de l'IA et laissez-la apporter des corrections jusqu'à ce que le résultat vous convienne ; +* envisagez d'utiliser un serveur de génération augmentée par récupération (RAG) contenant vos propres exemples de code sécurisé et relu ainsi que votre documentation, comme les recommandations, normes ou politiques de codage sécurisé de votre organisation, et faites appliquer vos politiques ou normes par le serveur RAG ; +* envisagez d'acheter des outils qui implémentent des garde-fous de confidentialité et de sécurité pour les IA de votre choix ; +* envisagez d'acheter une IA privée, idéalement avec un accord contractuel (y compris un accord de confidentialité) stipulant que l'IA ne doit pas être entraînée sur les données, requêtes, codes ou autres informations sensibles de votre organisation ; +* envisagez d'implémenter un serveur Model Context Protocol (MCP) entre votre IDE et votre IA, puis configurez-le pour imposer l'utilisation des outils de sécurité de votre choix ; +* implémentez des politiques et des processus dans votre SDLC afin d'informer les développeurs (et tous les employés) de la manière dont ils doivent, ou ne doivent pas, utiliser l'IA dans votre organisation ; +* créez une liste de prompts pertinents et efficaces qui tiennent compte des bonnes pratiques de sécurité informatique. Dans l'idéal, ils doivent également prendre en compte vos recommandations internes de codage sécurisé. Les développeurs peuvent utiliser ces prompts comme point de départ pour leurs programmes ; +* l'IA fera probablement partie de chaque phase du cycle de vie du développement des systèmes. Apprenez à l'utiliser efficacement et en toute sécurité, et utilisez-la avec discernement ; +* il n'est **pas** recommandé d'utiliser le *vibe coding* pour les fonctions complexes, les programmes critiques pour le métier ou les programmes utilisés pendant une longue période ; +* implémentez des contrôles et des garde-fous techniques contre l'utilisation d'une IA fantôme (*Shadow AI*) ; +* formez vos développeurs à vos politiques ainsi qu'à une utilisation sûre de l'IA et aux bonnes pratiques d'utilisation de l'IA dans le développement logiciel. + +### Références -* [OWASP Cheat Sheet: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) +* [Aide-mémoire OWASP : revue de code sécurisé](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) +### Liste des CWE associées -### List of Mapped CWEs --none- +- aucune - diff --git a/2025/docs/fr/index.md b/2025/docs/fr/index.md index 92d66fe64..636d341a2 100644 --- a/2025/docs/fr/index.md +++ b/2025/docs/fr/index.md @@ -26,15 +26,15 @@ Commencez par l'[Introduction](0x00_2025-Introduction.md) pour découvrir les no 1. [A01:2025 - Contrôles d'accès défaillants](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - Mauvaise configuration de sécurité](A02_2025-Security_Misconfiguration.md) -3. [A03:2025 - Défaillances de la nomenclature logicielle](A03_2025-Software_Supply_Chain_Failures.md) +3. [A03:2025 - Défaillances de la chaîne d'approvisionnement logicielle](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - Défaillances cryptographiques](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - Injection](A05_2025-Injection.md) 6. [A06:2025 - Conception non sécurisée](A06_2025-Insecure_Design.md) 7. [A07:2025 - Défaillances de l'authentification](A07_2025-Authentication_Failures.md) -8. [A08:2025 - Manque d'intégrité des données ou du logiciel](A08_2025-Software_or_Data_Integrity_Failures.md) -9. [A09:2025 - Carence des systèmes de contrôle et d'alerte](A09_2025-Security_Logging_and_Alerting_Failures.md) -10. [A10:2025 - Mauvaise gestion des exceptions](A10_2025-Mishandling_of_Exceptional_Conditions.md) +8. [A08:2025 - Défaillances d'intégrité du logiciel ou des données](A08_2025-Software_or_Data_Integrity_Failures.md) +9. [A09:2025 - Défaillances de la journalisation et des alertes de sécurité](A09_2025-Security_Logging_and_Alerting_Failures.md) +10. [A10:2025 - Mauvaise gestion des conditions exceptionnelles](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- -**Remarque :** Les traductions seront ajoutées dès qu'elles seront disponibles. +**Remarque :** Les traductions françaises sont disponibles pour l'ensemble des pages de cette édition. diff --git a/2025/mkdocs.yml b/2025/mkdocs.yml index 13daf9db5..771af9696 100644 --- a/2025/mkdocs.yml +++ b/2025/mkdocs.yml @@ -57,18 +57,18 @@ plugins: Introduction: Introduction About OWASP: À propos de l'OWASP What are Application Security Risks?: Quels sont les risques liés à la sécurité des applications ? - Establishing a Modern Application Security Program: Miette en place un programme moderne de sécurité des applications + Establishing a Modern Application Security Program: Mise en place d'un programme moderne de sécurité des applications Top 10:2025 List: Top 10:2025 A01 Broken Access Control: A01 - Contrôles d'accès défaillants A02 Security Misconfiguration: A02 - Mauvaise configuration de sécurité - A03 Software Supply Chain Failures: A03 - Défaillances de la nomenclature logicielle + A03 Software Supply Chain Failures: A03 - Défaillances de la chaîne d'approvisionnement logicielle A04 Cryptographic Failures: A04 - Défaillances cryptographiques A05 Injection: A05 - Injection A06 Insecure Design: A06 - Conception non sécurisée A07 Authentication Failures: A07 - Défaillances de l'authentification - A08 Software or Data Integrity Failures: A08 - Manque d'intégrité des données ou du logiciel - A09 Security Logging and Alerting Failures: A09 - Carence des systèmes de contrôle et d'alerte - A10 Mishandling of Exceptional Conditions: A10 - Mauvaise gestion des exceptions + A08 Software or Data Integrity Failures: A08 - Défaillances d'intégrité du logiciel ou des données + A09 Security Logging and Alerting Failures: A09 - Défaillances de la journalisation et des alertes de sécurité + A10 Mishandling of Exceptional Conditions: A10 - Mauvaise gestion des conditions exceptionnelles Next Steps: Étapes suivantes nav_translations: