esapi-java-legacy

遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。

如果这是您的项目,请在您的项目页面上显示您的徽章状态!徽章状态如下所示: 项目137的徽章级别为in_progress 这里是如何嵌入它:

这些是通过级别条款。您还可以查看白银黄金级别条款。

        

 基本 13/13

  • 识别

    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.

    用什么编程语言实现项目?
  • 基本项目网站内容


    项目网站必须简明扼要地描述软件的作用(它解决了什么问题?)。 [description_good]

    项目网站必须提供有关如何获取和提供反馈(错误报告或增强功能)以及如何贡献的信息。 [interact]

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



    关于如何贡献的信息必须解释贡献流程(例如,是否使用拉请求?) (需要网址) [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/.



    关于如何贡献的信息应包括对可接受的贡献的要求(例如,引用任何所需的编码标准)。 (需要网址) [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


  • FLOSS许可证

    项目使用什么许可证发布?



    项目生产的软件必须作为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).



    建议由项目生成的软件的任何必需的许可证是由开放源码促进会(OSI)批准的许可证(英文)[floss_license_osi]

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



    项目必须将其许可证在其源代码存储库中的标准位置发布。 (需要网址) [license_location]
  • 文档


    项目必须为项目生成的软件提供基本文档。 [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.



    项目必须提供描述项目生成的软件的外部接口(输入和输出)的参考文档。 [documentation_interface]

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


  • 其他


    项目网站(网站,存储库和下载URL)必须使用TLS支持HTTPS。 [sites_https]

    Given only https: URLs.



    该项目必须有一个或多个讨论机制(包括建议的更改和问题),可搜索,允许通过URL访问消息和主题,使新人能够参与一些讨论,并且不需要客户端安装专有软件。 [discussion]

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



    项目应该提供英文文档,并能够接受英文的代码的错误报告和评论。 [english]

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



    必须维护该项目。 [maintained]


(高级)哪些用户还有额外权限编辑此徽章条目?目前:[]



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").

  • 公开的版本控制的源代码存储库


    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]

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



    项目的源代码存储库必须跟踪所做的更改,谁进行了更改,何时进行了更改。 [repo_track]

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



    为了实现协作检视,项目的源代码存储库必须包括临时版本,以便检视版本之间的变化;它不得仅包括最终版本。 [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 #.



    建议使用通用分布式版本控制软件(例如,git)作为项目的源代码存储库。 [repo_distributed]

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


  • 唯一版本编号


    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [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.



    建议使用语义版本控制(SemVer)格式进行发布。 [version_semver]


    建议项目识别其版本控制系统中的每个版本。例如,建议使用git的项目,使用git标签识别每个版本。 [version_tags]

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


  • 发行说明


    该项目必须在每个版本中提供发布说明,这是该版本中主要变化的可读的摘要,以帮助用户确定是否应升级,升级影响将如何。发行说明不能是版本控制日志的原始输出(例如,“git log”命令结果不是发行说明)。其产出不适用于多个地点的项目(如单个网站或服务的软件),并采用持续交付,可以选择“N/A”。 (需要网址) [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



    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞,选择“不适用”。 [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.


  • 错误报告流程


    项目必须为用户提交错误报告(例如,使用问题跟踪器或邮件列表)提供相关流程。 (需要网址) [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.



    项目必须使用问题跟踪器来跟踪每个问题。 [report_tracker]

    该项目必须响应过去2-12个月内(含)提交的大多数错误报告;响应不需要包括修复。 [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.



    该项目应该对过去2-12个月内(包括)的大部分(> 50%)的增强请求作出回应。 [enhancement_responses]

    Same way as previous question.



    该项目必须有一个公开的报告和回复的档案供后续搜索。 (需要网址) [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


  • 漏洞报告流程


    项目必须在项目网站上发布报告漏洞的流程。 (需要网址) [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



    如果支持私有漏洞报告,项目必须包括如何以保密的方式发送信息。 (需要网址) [vulnerability_report_private]

    该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 [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.


  • 可工作的构建系统


    如果项目生成的软件需要构建使用,项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 [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.



    建议使用通用工具来构建软件。 [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.)



    该项目应该仅使用FLOSS工具来构建。 [build_floss_tools]

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


  • 自动测试套件


    该项目必须使用至少一个作为FLOSS公开发布的自动测试套件(该测试套件可以作为单独的FLOSS项目维护)。 [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.



    测试套件应该以该语言的标准方式进行调用。 [test_invocation]

    mvn test



    建议测试套件覆盖大部分(或理想情况下所有)代码分支,输入字段和功能。 [test_most]

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



    建议项目实施持续集成,将新的或更改的代码经常集成到中央代码库中,并对结果进行自动化测试。 [test_continuous_integration]
  • 新功能测试


    该项目必须有通用的策略(正式或非正式),当主要的新功能被添加到项目生成的软件中,该功能的测试应该同时添加到自动测试套件。 [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.



    该项目必须有证据表明,在项目生成的软件的最近重大变化中,已经遵守了添加测试的条款: test_policy [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.)



    建议您在更改提案的说明文档中添加测试策略要求(请参阅test_policy)。 [tests_documented_added]

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


  • 警告标志


    该项目必须启用一个或多个编译器警告标志,“安全”语言模式,或者使用单独的“linter”工具查找代码质量错误或常见的简单错误,如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 [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'.



    该项目必须处理警告。 [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.



    建议在实际情况下,项目以最严格方式对待项目生成的软件中的告警。 [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.


  • 安全开发知识


    该项目必须至少有一个主要开发人员知道如何设计安全软件。 [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.



    该项目的主要开发人员中,至少有一个必须知道导致这类型软件漏洞的常见错误类型,以及至少有一种方法来对付或缓解这些漏洞。 [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


  • 使用基础的良好加密实践

    请注意,某些软件不需要使用加密机制。

    项目生成的软件默认情况下,只能使用由专家公开发布和审查的加密协议和算法(如果使用加密协议和算法)。 [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.



    如果项目生成的软件是应用程序或库,其主要目的不是实现加密,那么它应该只调用专门设计实现加密功能的软件,而不应该重新实现自己的。 [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.



    项目所产生的软件中,所有依赖于密码学的功能必须使用FLOSS实现。 [crypto_floss]

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



    项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年(如2012年所述)的NIST最低要求。必须提供配置,以使较小的密钥长度被完全禁用。 [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.



    项目产生的软件中的默认安全机制不得取决于已被破解的密码算法(例如,MD4,MD5,单DES,RC4,Dual_EC_DRBG)或使用不适合上下文的密码模式(例如,ECB模式几乎不适当,因为它揭示了密文中相同的块,如 ECB企鹅所示。CTR模式通常是不合适的,因为如果重复输入状态,则它不执行认证并导致重复)。 [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.)



    由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式(例如,SHA-1密码散列算法或SSH中的CBC模式)。 [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.



    项目产生的软件中的安全机制应该​​对密钥协商协议实施完美的前向保密(PFS),如果长期密钥集合中的一个长期密钥在将来泄露,也不能破坏从一组长期密钥导出的会话密钥。 [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.



    如果项目产生的软件存储用于外部用户认证的密码,则必须使用密钥拉伸(迭代)算法(例如,PBKDF2,Bcrypt或Scrypt)将密码存储为每用户盐值不同的迭代散列 。 [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.



    由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数,并且不得使用密码学不安全的生成器。 [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


  • 安全交付防御中间人(MITM)的攻击


    该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 [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.



    不得通过http协议获取加密散列(例如,sha1sum)并直接使用,而不检查密码学签名。 [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.)


  • 修正公开的漏洞


    被公开了超过60天的中等或更高严重程度的漏洞,必须被修复。 [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.



    项目在得到报告后应该迅速修复所有致命漏洞。 [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!


  • 其他安全问题


    公共存储库不得泄漏旨在限制公众访问的有效私人凭证(例如,工作密码或私钥)。 [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.


  • 静态代码分析


    如果至少有一个FLOSS工具以所选择的语言实现此条款,则至少需要将一个静态代码分析工具应用于软件发布之前任何提议的主要生成版本。 [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).



    建议至少有一个用于static_analysis标准的静态分析工具包括在分析语言或环境中查找常见漏洞的规则或方法。 [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.



    使用静态代码分析发现的所有中,高严重性可利用漏洞必须在确认后及时修复。 [static_analysis_fixed]

    No medium or high severity vulnerabilities were discovered.



    建议每次提交或至少每天执行静态源代码分析。 [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.


  • 动态代码分析


    建议在发布之前,至少将一个动态分析工具应用于软件任何发布的主要生产版本。 [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).



    建议如果项目生成的软件包含使用内存不安全语言编写的软件(例如C或C++),则至少有一个动态工具(例如,fuzzer或web应用扫描程序)与检测缓冲区覆盖等内存安全问题的机制例行应用。如果该项目生成的软件没有以内存不安全语言编写,请选择“不适用”(N / A)。 [dynamic_analysis_unsafe]

    We use Java.



    建议由项目生成的软件包括许多运行时断言,在动态分析期间检查。 [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.



    通过动态代码分析发现的所有严重性为中,高的可利用漏洞必须在确认后及时修复。 [dynamic_analysis_fixed]

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



此数据在知识共享署名3.0或更高版本许可证(CC-BY-3.0 +) 下可用。所有内容都可以自由分享和演绎,但必须给予适当的署名。请署名为Kevin W. Wall和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者: Kevin W. Wall.
最后更新于 2016-05-10 23:31:58 UTC, 最后更新于 2022-08-16 02:34:46 UTC。

后退