esapi-java-legacy

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 137 est in_progress Voici comment l'intégrer :

Ce sont les critères du niveau Basique. Vous pouvez également afficher les critères des niveaux Argent ou Or.

        

 Notions de base 13/13

  • Identification

    ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications.

    Quel(s) langage(s) de programmation sont utilisés pour implémenter le projet ?
  • Contenu basique du site Web du projet


    Le site du projet DOIT décrire succinctement ce que le logiciel fait (quel problème résout-il ?). [description_good]

    Le site Web du projet DOIT fournir des informations sur la façon d'obtenir, de fournir des commentaires (comme des signalements de bogues ou des demandes d'amélioration) et de contribuer au logiciel. [interact]

    https://github.com/ESAPI/esapi-java-legacy, specifically in the README.md which is displayed on that page.



    L'information sur la façon de contribuer DOIT expliquer le processus de contribution (par exemple, les pull requests sont-ils utilisés ?) (URL requise) [contribution]

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.



    Les informations sur la façon de contribuer DEVRAIENT inclure les exigences pour des contributions acceptables (par exemple, une référence à toute norme de codage requise). (URL requise) [contribution_requirements]

    See "How can I contribute or help with bug fixes?" section of https://github.com/ESAPI/esapi-java-legacy/blob/develop/README.md


  • Licence FLOSS

    Sous quelle(s) licence(s) le projet est-il distribué ?



    Le logiciel produit par le projet DOIT être distribué en tant que FLOSS. [floss_license]

    The BSD-3-Clause license is approved by the Open Source Initiative (OSI).

    Note that documentation is released under Creative Commons BY-SA licenses (2.0, 3.0, and 4.0, depending on when authored). The BSD-3-Clause license is approved by the Open Source Initiative (OSI).



    Il est PROPOSÉ que toute licence requise pour le logiciel produit par le projet soit approuvée par l'Open Source Initiative (OSI). [floss_license_osi]

    The BSD-3-Clause license is approved by the Open Source Initiative (OSI).



    Le projet DOIT afficher la ou les licences de ses résultats dans un emplacement standard dans leur dépôt source. (URL requise) [license_location]
  • Documentation


    Le projet DOIT fournir une documentation de base pour le logiciel produit par le projet. [documentation_basics]

    Most of the documentation on ESAPI may be found under https://github.com/ESAPI/esapi-java-legacy/tree/develop/documentation. Since ESAPI is a widely used Java API, the latest Javadoc (which is the low-level documentation for its use) is available at https://www.javadoc.io/doc/org.owasp.esapi/esapi/. Additional ESAPI documentation (e..g,, the ESAPI-AppSensor integration) is referenced off the main ESAPI page on the OWASP wiki site.



    Le projet DOIT fournir une documentation de référence qui décrit l'interface externe (entrée et sortie) du logiciel produit par le projet. [documentation_interface]

    The low-level API documentation for ESAPI is available at https://www.javadoc.io/doc/org.owasp.esapi/esapi/


  • Autre


    Les sites du projet (site Web, dépôt et URLs de téléchargement) DOIVENT supporter HTTPS en utilisant TLS. [sites_https]

    Given only https: URLs.



    Le projet DOIT avoir un ou plusieurs mécanismes de discussion (y compris les changements et les problèmes proposés) qui peuvent être recherchés, permettent de désigner les messages et les sujets par une URL, permettent aux nouvelles personnes de participer à certaines des discussions et ne nécessitent pas d'installation côté client de logiciels propriétaires. [discussion]

    GitHub supports discussions on issues and pull requests. As of 2022-05-10, we also added a GitHub Discussions board.



    Le projet DEVRAIT fournir de la documentation en anglais et être en mesure d'accepter les signalements de bogues et les commentaires sur le code en anglais. [english]

    The README.md file, displayed on the main GitHub page at https://github.com/ESAPI/esapi-java-legacy describes all of this.



    Le projet DOIT être maintenu. [maintained]


(Avancé) Quels autres utilisateurs ont les droits supplémentaires pour modifier cette soumission de badge? Actuellement : []



We have a lot of documentation, but 1) much of it is outdated, 2) much of it is disorganized and/or hard to find, and 3) a lot of it is not the "right" documentation to serve the intended audience (e.g., I'm thinking of developer user guides here in the "how to use sense").

  • Dépôt source public sous contrôle de version


    Le projet DOIT avoir un dépôt source sous contrôle de version qui est publiquement lisible et possède une URL. [repo_public]

    Repository on GitHub, which provides public git repositories with URLs. See https://github.com/ESAPI/esapi-java-legacy for details.



    Le dépôt source du projet DOIT suivre les changements apportés, qui a effectué les changements et quand les changements ont été effectués. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    Pour permettre une analyse collaborative, le dépôt source du projet DOIT inclure des versions provisoires pour examen entre versions officielles ; Il NE DOIT PAS inclure que les dernières versions. [repo_interim]

    On-going development and bug-fixes are made on the (default) 'develop' branch. The latest official release is available on the 'master' branch. We also have tagged releases based on release # and have branches corresponding to each release #.



    Il est PROPOSÉ qu'un logiciel reconnu de contrôle de version distribué soit utilisé (par exemple, git) pour le dépôt source du projet. [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


  • Numérotation unique de la version


    Les résultats du projet DOIVENT avoir un identifiant de version unique pour chaque version destinée à être utilisée par les utilisateurs. [version_unique]

    Release #s are updated according to semantic versioning format for each release. The latest (possibly unstable) release is available from the (default) 'develop' branch. The latest previous official release is available from the 'master' branch.



    Il est PROPOSÉ d'utiliser le format de numérotation de version appelé Versionage Sémantique (SemVer) ou Versionage Calendaire (CalVer). Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro. [version_semver]


    Il est PROPOSÉ que les projets identifient chaque version dans leur système de contrôle de version. Par exemple, il est PROPOSÉ que ceux qui utilisent git identifient chaque version à l'aide des tags de git. [version_tags]

    Done with git tags. Also each tag corresponding to an official release has a corresponding Git branch.


  • Notes de version


    Le projet DOIT fournir, avec chaque distribution, des notes de version qui sont un résumé lisible par les humains des changements majeurs dans cette version afin d'aider les utilisateurs à déterminer s'ils doivent se mettre à niveau et quel sera l'impact de la mise à niveau. Les notes de version NE DOIVENT PAS être la sortie brute d'un journal de contrôle de version (par exemple, les résultats de la commande « git log » ne sont pas des notes de version). Les projets dont les résultats ne sont pas destinés à être réutilisés dans plusieurs emplacements (tels que le logiciel pour un site Web ou un service unique) ET qui utilisent la livraison continue PEUVENT sélectionner « N/A ». (URL requise) [release_notes]

    The changelog is usually incorporated into the release notes. For the latest release notes, see https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/esapi4java-core-2.1.0.1-release-notes.txt



    Les notes de version DOIVENT identifier toutes les vulnérabilités connues du public corrigées dans cette version qui avaient déjà une affectation CVE ou similaire lors de la création de la version. Ce critère peut être marqué comme non applicable (N/A) si les utilisateurs ne peuvent pas en général mettre à jour le logiciel eux-mêmes (par exemple, comme c'est souvent le cas pour les mises à jour du noyau). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. S'il n'y a pas de notes de version ou qu'il n'y a pas eu de vulnérabilité publiquement connue, choisissez N/A. [release_notes_vulns]

    There was some dispute over whether or not https://github.com/ESAPI/esapi-java-legacy/issues/354 was considered a vulnerability or not. We did not seek getting a CVE for this because it was the same type of Java deserialization issue as was Apache Commons COLLECTIONS-580 bug, which Mitre supposed refused to issue a CVE for. (Not to mention that getting a CVE is a royal PITA!) We did announce this one the 2 ESAPI public mailing lists shortly after I created the GitHub issue for it. That code was closed on 2016-01-19 by removing the vulnerable method as I decided it was too dangerous to leave in only a deprecated state for 2 whole years (as per our normal deprecation policy). Other vulnerabilities, are discussed in detail in published security bulletins and summarized in https://github.com/ESAPI/esapi-java-legacy/blob/develop/Vulnerability-Summary.md, which is referenced from our project README file.


  • Procédure de signalement des bogues


    Le projet DOIT fournir un processus permettant aux utilisateurs de soumettre des signalements de bogue (par exemple, en utilisant un suivi des problèmes ou une liste de diffusion). (URL requise) [report_process]

    GitHub issues: https://github.com/ESAPI/esapi-java-legacy/issues/new is the preferred way, but we have had users announce bugs on the mailing lists. In those cases, one of the ESAPI contributors will turn those into a GitHub issue. There are plans to integrate with an instance of Atlassian's JIRA, but the synchronization of that with GitHub failed and so we are back to using GitHub Issues alone at the moment.



    Le projet DEVRAIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]

    Le projet DOIT confirmer une majorité des signalements de bogues soumis au cours des 2 à 12 derniers mois (inclus) ; la réponse ne doit pas nécessairement inclure une correction. [report_responses]

    ESAPI contributors get email and can respond directly via there or via GitHub. Note that we may have some bugs from the very early days that contributors created that were not formally acknowledged. Generally those were ones that one contributor asked another contributor via email to file a bug report using Google Code (which we were using back then). However, since moving things to GitHub and getting a few additional contributors, we have been doing better.



    Le projet DEVRAIT répondre à une majorité (>50%) des demandes d'amélioration au cours des 2 à 12 derniers mois (inclus). [enhancement_responses]

    Same way as previous question.



    Le projet DOIT avoir une archive publique pour les signalements et les réponses pour une recherche ultérieure. (URL requise) [report_archive]

    GitHub issues (https://github.com/ESAPI/esapi-java-legacy/issues) are searchable. In addition, the two ESAPI mailing lists are archived and searchable as well. And as of 2022-05-10, we now support a GitHub Discussions board at https://github.com/ESAPI/esapi-java-legacy/discussions


  • Processus de signalement de vulnérabilité


    Le projet DOIT publier le processus de signalement des vulnérabilités sur le site du projet. (URL requise) [vulnerability_report_process]

    The process for reporting vulnerabilities is now described in the README.md file which is displayed on the main GitHub page at https://github.com/ESAPI/esapi-java-legacy. The ESAPI security vulnerability reporting process is also described at https://github.com/ESAPI/esapi-java-legacy/security/policy



    Si les signalements de vulnérabilités privés sont pris en charge, le projet DOIT inclure la façon d'envoyer l'information de manière confidentielle. (URL requise) [vulnerability_report_private]

    Le temps de réponse initial du projet pour tout signalement de vulnérabilité reçu au cours des 6 derniers mois DOIT être inférieur ou égal à 14 jours. [vulnerability_report_response]

    Met. Some details may be found at https://github.com/ESAPI/esapi-java-legacy/security/advisories?state=published. Technically, I guess we didn't "respond" to the one at https://github.com/ESAPI/esapi-java-legacy/security/advisories/GHSA-q77q-vx4q-xx6q, but that's because Kevin Wall (one of the ESAPI project co-leads) reported it himself.


  • Système de construction opérationnel


    Si le logiciel produit par le projet nécessite d'être construit pour être utilisé, le projet DOIT fournir un système de construction fonctionnel qui peut reconstruire automatiquement le logiciel à partir du code source. [build]

    Non-trivial build file in repository: https://github.com/ESAPI/esapi-java-legacy/blob/develop/pom.xml. Starting with ESAPI 2.3.0.0, we now also distribute ESAPI with a CycloneDX SBOM file that is uploaded to Maven Central.



    Il est PROPOSÉ d'utiliser des outils courants pour la construction du logiciel. [build_common_tools]

    Non-trivial build file in repository: https://github.com/ESAPI/esapi-java-legacy/blob/develop/pom.xml. All tools required to build the software are available under FLOSS licenses. Only Maven 3.3.9 or later and Java 8 or later (we use OpenJDK, but any version should work) is be needed to build ESAPI and run the JUnit tests. (Maven will pull in the rest of the dependencies.)



    Le projet DEVRAIT être constructible en utilisant uniquement des outils FLOSS. [build_floss_tools]

    OpenJDK, Maven, JUnit, and various FLOSS 3rd party Java libraries such as various Apache Commons libraries, etc.


  • Suite de tests automatisée


    Le projet DOIT utiliser au moins une suite de tests automatisée publiée publiquement comme FLOSS (cette suite de tests peut être maintenue sous la forme d'un projet FLOSS distinct). Le projet DOIT clairement montrer ou documenter comment exécuter la ou les suites de tests (par exemple, via un script d'intégration continue (CI) ou via la documentation dans des fichiers tels que BUILD.md, README.md ou CONTRIBUTING.md). [test]

    As of release 2.5.0.0, there are now 4274 JUnit tests in 131 Java source files (with 0 tests skipped)'mvn test' and all tests passing. There is also a GitHub CI/CD workflow that executes 'mvn -B package --file pom.xml' every time a git PR is created.



    Une suite de tests DEVRAIT être invocable d'une manière standard pour ce langage. [test_invocation]

    mvn test



    Il est PROPOSÉ que la suite de tests couvre la plupart (ou idéalement toutes) les branches du code, les champs de saisie et les fonctionnalités. [test_most]

    70% code coverage as measured by coveralls.io (under https://coveralls.io/github/bkimminich/esapi-java-legacy?branch=develop)



    Il est PROPOSÉ que le projet utilise une intégration continue (où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat). [test_continuous_integration]
  • Nouveau test de fonctionnalité


    Le projet DOIT avoir une politique générale (formelle ou non) qui spécifie que, dès qu'une nouvelle fonctionnalité majeure est ajoutée au logiciel produit par le projet, des tests de cette fonctionnalité devraient être ajoutés à une suite de tests automatisée. [test_policy]

    The project (unfortunately) has a small enough # of contributors on the team that this is well understood. That said, no new major functionality is intended for esapi-java-legacy (i.e., ESAPI 2.x releases). Any new functionality will be done under ESAPI 3.0 (https://github.com/ESAPI/esapi-java) that is a project that will not [or, at least very unlikely] be backward compatible with ESAPI 2.x releases. However, we believe this is also applicable to bug fixes as well and as such, have updated Step 4 in the CONTRIBUTING-TO-ESAPI.txt file to mention adding JUnit tests to confirm fixes.



    Le projet DOIT avoir la preuve que la politique de test pour l'ajout de tests a été respectée dans les dernières modifications majeures apportées au logiciel produit par le projet. [tests_are_added]

    Really, not applicable as no new functionality is planned / intended. See above question for details. (Seriously, I'm having enough trouble just getting enough people to address bug fixes.)



    Il est PROPOSÉ que cette politique sur l'ajout de tests (voir la politique de test) soit documentée dans les instructions pour les propositions de modification. [tests_documented_added]

    Again, N/A. See the two previous questions.


  • Options d'avertissement


    Le projet DOIT activer une ou plusieurs options d'avertissement du compilateur, un mode du langage « sûr » ou utiliser un outil « linter » séparé pour rechercher des erreurs de qualité de code ou des erreurs simples courantes, s'il existe au moins un outil FLOSS qui peut implémenter ce critère dans le langage sélectionné. [warnings]

    The next official ESAPI major release will include '-Xlint:all' in the pom.xml. Since the latest release (2.2.0.0), we have been using '-Xlint:all,-deprecation,-rawtypes,-unchecked'.



    Le projet DOIT résoudre les avertissements. [warnings_fixed]

    Addressed with the exceptions of the warnings that are currently (deliberately) ignored; see previous question. This is being addressed now, but we currently do not have it ALL.



    Il est PROPOSÉ que les projets soient maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]

    Toying with the idea of also adding '-Werror' to terminate compilation if there are any ideas, but need to bounce that idea off the other contributors first before deciding on anything definitive.


  • Connaissance du développement sécurisé


    Le projet DOIT avoir au moins un développeur principal qui sait comment concevoir un logiciel sécurisé. (Voir les « détails » pour les exigences exactes.) [know_secure_design]

    Both project co-leaders (Kevin W. Wall and Matt Seilt) are experienced professional appsec engineers who have been 10+ years of application security experience.



    Au moins l'un des principaux développeurs du projet DOIT connaître les types courants d'erreurs qui conduisent à des vulnérabilités dans ce genre de logiciel, ainsi qu'au moins une méthode pour contrer ou atténuer chacun d'eux. [know_common_errors]

    ESAPI in fact is designed to address common appsec errors such as OT10. E.g., see slide 3 in https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/esapi4java-2.0-javadoc-pictures.pptx


  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Le logiciel produit par le projet DOIT utiliser, par défaut, uniquement les protocoles cryptographiques et les algorithmes publiés publiquement et revus par des experts (si des protocoles et algorithmes cryptographiques sont utilisés). [crypto_published]

    By DEFAULT, only AES is enabled. Users however, could in principle, add whatever stupid symmetric encryption algorithm is supported by some JVE implementation, like SuperRoysSecretSnakeOilCryptoSauce that requires a 1M bit key and implements a pseudo-one time pad. Let's face it, there is no patch for stupidity. It's open source, so if we tried to white-list algorithms, people could just rewrite that part of the source code and recompile.



    Si le logiciel produit par le projet est une application ou une bibliothèque, et si son objectif principal n'est pas d'implémenter de la cryptographie, alors il DEVRAIT simplement appeler un logiciel spécialement conçu pour implémenter des fonctions cryptographiques ; il ne DEVRAIT PAS ré-implémenter les siennes. [crypto_call]

    We rely on JCE implementations, such as SunJCE or BouncyCastle, etc. We provide more user friendly wrappers around the JCE crypto so that people don't have to understand what cipher modes and IVs and padding schemes are all about. We also provide an encrypt-then-MAC approach to CBC mode for earlier versions of JDK that don't support out-of-the-box authenticated encryption modes and for projects that are not permitted to use alternative FLOSS JCE implementations such as BouncyCastle.



    Toutes les fonctionnalités du logiciel produit par le projet qui dépendent de la cryptographie DOIVENT être réalisables à l'aide de FLOSS. [crypto_floss]

    SunJCE (available as part of OpenJDK) or BouncyCastle are both FLOSS JCE implementations.



    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT utiliser des longueurs de clés par défaut qui satisfont au moins aux exigences minimales du NIST jusqu'à l'année 2030 (comme indiqué en 2012). Il DOIT être possible de configurer le logiciel afin que les plus petites longueurs de clés soient complètement désactivées. [crypto_keylength]

    The default min key size is 128 bits for AES, or either 112 bit, 2-key TDES for DESede (or 3-key if the JCE Unlimited Strength Jurisdiction Polciy files are installed as part of the JRE.



    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes cryptographiques cassés (par exemple, MD4, MD5, DES unique, RC4, Dual_EC_DRBG) ou utiliser des modes de chiffrement inappropriés dans le contexte, sauf si ils sont nécessaires pour implémenter un protocole d'interopérabilité (où le protocole implémenté est la version la plus récente du standard supporté largement par l'écosystème du réseau, l'écosystème requiert l'utilisation de cet algorithme ou mode, et cet écosystème n'offre pas d'alternative plus sûre). La documentation DOIT décrire tous les risques de sécurité appropriés et les parades connues si ces algorithmes ou modes cassés sont nécessaires pour un protocole d'interopérabilité. [crypto_working]

    Use SHA-256 by default for most hashing, but users can decide by tweaking properties in ESAPI.properties to use whatever MessageDigest or Mac that is available. (Again, we do not try to prevent stupidity this being open source, but we do try to make it intentional if you want to shoot off your own foot.)



    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DEVRAIENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). [crypto_weaknesses]

    We do use HMacSHA1, but according to Bellare, Canetti & Krawczyk (1996), this should still be secure as they showed that HMAC security doesn’t require that the underlying hash function be collision resistant, but only that it acts as a pseudo-random function. (Or at least that was my take away when I read it 10+ years ago. But if I'm wrong, please advise. We wanted an HMAC value that was short as possible, but HMAC-MD5 just didn't feel right.) We also use SecureRandom to generate random #s for things like IVs, etc. which ought to be okay even though it uses SHA1PRNG as its CSRNG.



    Les mécanismes de sécurité dans le logiciel produit par le projet DEVRAIENT implémenter la confidentialité persistante pour les protocoles d'échange de clés afin qu'une clé de session dérivée d'un ensemble de clés à long terme ne soit pas compromise si l'une des clés à long terme est compromise dans le futur. [crypto_pfs]

    We currently do not do any sort of key-agreement. All symmetric encryption is assumed to use pre-shared keys, presumably shared out-of-band. This is something that is being considered for ESAPI 3.0 though.



    Si le logiciel produit par le projet entraîne la sauvegarde de mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être sauvegardés comme hachages itérés avec un salage par utilisateur en utilisant un algorithme d'étirement de clé (itéré) (par exemple Argon2id, Bcrypt, Scrypt, ou PBKDF2). Voir également le pense-bête sur le stockage des clés d'OWASP. [crypto_password_storage]

    We don't store passwords per se, except temporally for unit testing (created by FileBasedAuthenticator) where they are hashed with per-user random salt.



    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT générer toutes les clés cryptographiques et les nonces en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé, et NE DOIVENT PAS le faire en utilisant des générateurs qui ne seraient pas cryptographiquement sécurisés. [crypto_random]

    We use an implementation of NIST SP 800-108 Key Derivation Function (which uses SHA-256 for it's CSPRNG under the hood.) Design and implementation details are available at: https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/Analysis-of-ESAPI-2.0-KDF.pdf


  • Livraison sécurisée contre les attaques man-in-the-middle (MITM)


    Le projet DOIT utiliser un mécanisme de livraison qui contrecarre les attaques MITM. L'utilisation de https ou ssh+scp est acceptable. [delivery_mitm]

    We enforce either https: for all our ESAPI-related web sites or https or ssh from the git command line. Also, in several ESAPI classes, we ensure that the client is using https.



    Un hachage cryptographique (par exemple, un sha1sum) NE DOIT PAS être récupéré par http et utilisé sans vérifier une signature cryptographique. [delivery_unsigned]

    ESAPI is downloaded from https://search.maven.org/#search%7Cga%7C1%7Cesapi. The jar is signed by my (Kevin Wall's) private key. My public key is available from the MIT key server should anyone actually wish to confirm it. (Yeah; right. Sigh.)


  • Vulnérabilités publiquement identifiées et corrigées


    Il ne DOIT pas y avoir de vulnérabilités non corrigées de gravité moyenne ou supérieure connues publiquement depuis plus de 60 jours. [vulnerabilities_fixed_60_days]

    As of ESAPI 2.5.0.0, there are no now true positives identified as vulnerabilities in ESAPI. (As of the 2.5.0.0 release, we completely removed the Log4J 1.2.17 dependency.) It only took us 2 years to remove it because that is our formal deprecation policy and it would have broken many client applications. (We also confirmed there were no exploitable CVEs related to Log4J in our standard configuration.)

    However, there are still occasional false positives flagged by various Software Compositional Analysis (SCA) tools / services (e.g., OWASP Dependency Check, BlackDuck, Verisign SourceClear, Snyk, Sonatype NexusIQ, etc.) that flag ESAPI as being vulnerable to some CVE or another. These are almost always in a transitive dependency. We thoroughly investigate these and either proceed to remediate them, or if they are false positives, explain the rationale as to why they are not exploitable in a security bulletin and then reference that in the Vulnerability-Summary.md file.

    CVE-2013-5960 is still unfixed even though NIST says that it was fixed 2.1.0.1 (which is true for the default ESAPI configuration), but CVE-2013-5960 is actually a design flaw, not a coding bug, and I (the author) do not really believe that the core issue has been remediated even though I believe that NIST / MITRE got the CVSSv2 score wrong. (But what point is there disputing that since they think it is already closed.) But the reason it is not exploitable in the default configuration is that only Authenticated Encryption cipher modes (GCM, CCM, IAPM, EAX, OCB, and CWC) are offered in the default configuration and the only non-AE mode offered by default is CBC. The PoC exploit code exploit for CVE-2013-5960 required OFB mode to be added to the ESAPI.properties file as a non-AE cipher mode. One may be able to do that via social engineering, but that should reflect a lower CVSSv2 score.

    in that the CVSSv2 base score is 5.8 but I would contend that they did not take into account that one needs to convince the intended victim to first accept additional non-authenticated cipher modes and, place them in the ESAPI.properties file. Could happen, but that social engineering side was not taken into the equation.

    Note that correctly fixing CVE-2013-5960 requires a major redesign in the encrypt-then-MAC calculation. When I started looking at it more deeply, I realized there were additional things that should be MAC'd as well such as the version #, etc. (I since have become aware of Schneier & Ferguson's Horton Principle and am making design changes as a result.) Doing it securely in a manner that can be backward compatible is tough and it would be nice to have someone else with some applied cryptography knowledge since Jeffrey Walton is no longer contributing toward OWASP.

    However, I am marking this as 'met' because I think even if NIST had left this as open, had the adjusted it for the DEFAULT ESAPI configuration, the CVSSv2 score would have been LOW rather than MEDIUM.



    Les projets DEVRAIENT corriger rapidement toutes les vulnérabilités critiques après leur signalement. [vulnerabilities_critical_fixed]

    You'll get no argument from me. But given that ESAPI all but died (see https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Should_I_use_ESAPI_3F and http://off-the-wall-security.blogspot.com/2014/03/esapi-no-longer-owasp-flagship-project.html), I'm happen that it's at least still crawling along. Any help is always appreciated!


  • Autres problèmes de sécurité


    Les dépôts publics NE DOIVENT PAS fuiter un certificat privé valide (par exemple, un mot de passe ou une clé privée) qui est destiné à limiter l'accès public. [no_leaked_credentials]

    We store no passwords or private keys on any public repositories. My private signing key is encrypted on my GPG keyring and that passphrase is stored in PasswordSafe on my personal laptop (and backed up!) and secured by a secure passphrase known only to me.


  • Analyse statique de code


    Au moins un outil d'analyse statique de code (au-delà des avertissements du compilateur et des modes « sûrs » des languages) DOIT être appliqué à toute distribution majeure proposée avant sa sortie s'il existe au moins un outil FLOSS qui implémente ce critère dans le langage sélectionné. [static_analysis]

    I use FindSecurityBugs and PMD when I use Eclipse. Several of us also have a Coverity instance (e.g.,, https://scan.coverity.com/projects/bkimminich-esapi-java-legacy and https://scan.coverity.com/projects/owasp-esapi-java, which our Coverity badge will eventually be referring to).



    Il est PROPOSÉ qu'au moins l'un des outils d'analyse statique utilisés pour le critère d'analyse statique inclue des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé. [static_analysis_common_vulnerabilities]

    Coverity is being used. I have also ran it through HP Fortify a few times. It has been fully analyzed by the secure code review team where I work, and while I cannot provide details, no vulnerabilities were discovered. I did find 1 or 2 bugs [since reported] as a result of the Fortify scan though.



    Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse statique de code DOIVENT être corrigées en temps approprié après leur confirmation. [static_analysis_fixed]

    No medium or high severity vulnerabilities were discovered.



    Il est PROPOSÉ que l'analyse statique du code source se produise à chaque commit ou au moins quotidiennement. [static_analysis_often]

    We regularly run PMD, spotbugs, and findsecbugs and review new findings. I believe that Bjorn Kimminich has integrated the Coverity scan with his Travis-CI builds, but it has been run since April 2016. I have run CodeQL recently, but it is not yet fully integrated into our GitHub workflow.


  • Analyse dynamique de code


    Il est PROPOSÉ qu'au moins un outil d'analyse dynamique soit appliqué à tout candidat pour une version majeure du logiciel avant sa distribution. [dynamic_analysis]

    Not sure exactly how this applies, but N/A isn't something that I can choose. There were early versions of web-based software (e.g., ESAPI Swingset) that demonstrated how to use ESAPI, but it is not directly attackable via DAST as it is simply an SDK (i.e., a library).



    Il est PROPOSÉ que, si le logiciel produit par le projet comprend un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple, C ou C ++), au moins un outil dynamique (par exemple, un fuzzer ou un scanner d'application Web) soit utilisé de façon routinière en combinaison avec un mécanisme pour détecter des problèmes de sécurité mémoire tels que les dépassements de zone mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, choisissez « non applicable » (N/A). [dynamic_analysis_unsafe]

    We use Java.



    Il est PROPOSÉ que le projet utilise une configuration pour au moins une analyse dynamique (comme le test ou le fuzzing) qui active de nombreuses assertions. Dans de nombreux cas, ces assertions ne doivent pas être activées dans les versions de production. [dynamic_analysis_enable_assertions]

    There are runtime assertions, but ironically most people disable those (they, in fact are disabled by default in Java), so instead I am changing most of them to explicit runtime checks (except for things like certain invariants or sanity checks in private methods where we still have some assertions). Violations of runtime checks will throw some sort of RuntimeException, notably IllegalArgumentException for most of the precondition failures.



    Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse de code dynamique DOIVENT être corrigées en un temps approprié après leur confirmation. [dynamic_analysis_fixed]

    None discovered because using DAST on ESAPI directly really makes no sense; there is nothing for DAST to test against.



Ces données sont disponibles sous une licence Creative Commons Attribution version 3.0 ou ultérieure (CC-BY-3.0+). Chacun peut librement partager et adapter les données, à condition de créditer leur origine. Veuillez créditer Kevin W. Wall et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Kevin W. Wall.
Soumission créée le 2016-05-10 23:31:58 UTC, dernière mise à jour le 2022-08-16 02:34:46 UTC.

Retour