esapi-java-legacy

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

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

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 #.

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

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.

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

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

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.

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.

GitHub issues: https://github.com/ESAPI/esapi-java-legacy/issues/

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.

Same way as previous question.

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

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

See https://github.com/ESAPI/esapi-java-legacy/security/policy for details.

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.

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.

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

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

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.

mvn test

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

Travis-CI (currently run as https://travis-ci.org/bkimminich/esapi-java-legacy)

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.

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

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

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'.

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.

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

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

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.

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.

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

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.

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

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.

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.

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

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

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.

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

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.

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!

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.

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

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.

No medium or high severity vulnerabilities were discovered.

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.

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

We use Java.

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.

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