Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact The Validator.isValidSafeHTML method can result in false negatives where it reports some input as safe (i.e., returns true), but really isn't, and using that same input as-is can in certain circumstances result in XSS vulnerabilities. Because this method cannot be fixed, it is being deprecated and will be removed in one years time from when this advisory is published. Full details may be found in ESAPI Security Bulletin #12. Note that all versions of ESAPI, that have this method (which dates back to at least the ESAPI 1.3 release more than 15 years ago) have this issue and it will continue to exist until we remove these two methods in a future ESAPI release. Patches There is no patch. We do not believe that it is possible to patch this pretentiously named method other then perhaps renaming it to something like Validator.mightThisBeValidSafeHTML to dissuade developers from using it. Workarounds Stop using this method. Note that Validator.getValidSafeHTML is believed to be safe…
Recommended action: Upgrade to 2.6.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact ESAPI 2.5.2.0 and later addressed the DoS vulnerability described in CVE-2023-24998, which Apache Commons FileUpload 1.5 attempted to remediate. But while writing up a new security bulletin regarding the impact on the affected ESAPI HTTPUtilities.getFileUploads methods (or more specifically those methods in the DefaultHTTPUtilities implementation class), I realized that a DoS vulnerability still persists in ESAPI and for that matter in Apache Commons FileUpload as well. Related to CVE-2023-24998 Patches ESAPI 2.5.2.0 or later. Workarounds - See the 'Solutions' section of Security Bulletin 11, in the References section. If you are not using ESAPI file uploads, see also the 'Workarounds' section. - Deploy an external WAF or other suitable DoS protection. - Add additional defenses to your code using HTTPUtilities.getFileUpload, such as requiring prior authentication, restricting how many / much content can be uploaded per user per day or per hour, etc. (It is the opinion of the…
Recommended action: Upgrade to 2.5.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The authenticated-encryption feature in the symmetric-encryption implementation in the OWASP Enterprise Security API (ESAPI) for Java 2.x before 2.1.0 does not properly resist tampering with serialized ciphertext, which makes it easier for remote attackers to bypass intended cryptographic protection mechanisms via an attack against authenticity in the default configuration, involving a null MAC and a zero MAC length.
Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The authenticated-encryption feature in the symmetric-encryption implementation in the OWASP Enterprise Security API (ESAPI) for Java 2.x before 2.1.0.1 does not properly resist tampering with serialized ciphertext, which makes it easier for remote attackers to bypass intended cryptographic protection mechanisms via an attack against the intended cipher mode in a non-default configuration, a different vulnerability than CVE-2013-5679.
Recommended action: Upgrade to 2.1.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There is a potential for an XSS vulnerability in ESAPI caused by a incorrect regular expression for "onsiteURL" in the antisamy-esapi.xml configuration file that can cause URLs with the "javascript:" scheme to NOT be sanitized. See the reference below for full details. Patches Patched in ESAPI 2.3.0.0 and later. See important remediation details in the reference given below. Workarounds Manually edit your antisamy-esapi.xml configuration files to change the "onsiteURL" regular expression as per remediation instructions in the reference below. References Security Bulletin 8 For more information If you have any questions or comments about this advisory: Email one of the project co-leaders. See email addresses listed on the OWASP ESAPI wiki page, under "Leaders". Send email to one of the two ESAPI related Google Groups listed under Where to Find More Information on ESAPI on our README.md page.
Recommended action: Upgrade to 2.3.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The default implementation of Validator.getValidDirectoryPath(String, String, File, boolean) may incorrectly treat the tested input string as a child of the specified parent directory. This potentially could allow control-flow bypass checks to be defeated if an attack can specify the entire string representing the 'input' path. Patches This vulnerability is patched in release 2.3.0.0 of ESAPI. See https://github.com/ESAPI/esapi-java-legacy/releases/tag/esapi-2.3.0.0 for details. Workarounds Yes; in theory, one could write the own implementation of the Validator interface. This would most easily be done by sub-classing a version of the affected DefaultValidator class and then overriding the affected getValidDirectoryPath() to correct the issue. However, this is not recommended. For more information If you have any questions or comments about this advisory: Email one of the project co-leaders. See email addresses listed on the OWASP ESAPI wiki page, under "Leaders". Send email…
Recommended action: Upgrade to 2.3.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It was found that all OWASP ESAPI for Java up to version 2.0 RC2 are vulnerable to padding oracle attacks.
Recommended action: Upgrade to 2.0GA or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.