esapi / esapi-java Goto Github PK

Starting at around 10.Apr.2023, the following started to fail on the Java project:

[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '8.0': 
[ERROR] 
[ERROR] neko-htmlunit-2.66.0.jar: CVE-2023-26119(9.8)

This dependency comes from the latest esapi.jar

+- org.owasp.esapi:esapi:jar:2.5.1.0:compile
|  +- xom:xom:jar:1.3.8:compile
|  +- commons-beanutils:commons-beanutils:jar:1.9.4:compile
|  |  +- commons-logging:commons-logging:jar:1.2:compile
|  |  \- commons-collections:commons-collections:jar:3.2.2:compile
|  +- commons-configuration:commons-configuration:jar:1.10:compile
|  +- commons-lang:commons-lang:jar:2.6:compile
|  +- org.apache.commons:commons-collections4:jar:4.4:compile
|  +- org.apache-extras.beanshell:bsh:jar:2.0b6:compile
|  +- org.owasp.antisamy:antisamy:jar:1.7.2:compile
|  |  +- net.sourceforge.htmlunit:neko-htmlunit:jar:2.66.0:compile
|  |  +- org.apache.xmlgraphics:batik-css:jar:1.16:compile
|  |  |  +- org.apache.xmlgraphics:batik-shared-resources:jar:1.16:compile
|  |  |  +- org.apache.xmlgraphics:batik-util:jar:1.16:compile
|  |  |  |  +- org.apache.xmlgraphics:batik-constants:jar:1.16:compile
|  |  |  |  \- org.apache.xmlgraphics:batik-i18n:jar:1.16:compile
|  |  |  \- org.apache.xmlgraphics:xmlgraphics-commons:jar:2.7:compile
|  |  +- xerces:xercesImpl:jar:2.12.2:compile
|  |  \- xml-apis:xml-apis-ext:jar:1.3.04:compile
|  \- xml-apis:xml-apis:jar:1.4.01:compile

The ticket in antisamy — nahsra/antisamy#321
The ticket in neko-htmlunit — HtmlUnit/htmlunit-neko#20

esapi denpend log4j，but there is a cve in log4j, link is https://nvd.nist.gov/vuln/detail/CVE-2019-17571，update the jar please.

I'd like to add Travis CI to this project, so that we can increase it's adoption among open source contributors.

The ESAPI Validator component uses the various Encoder.canonicalize methods, which creates a tight coupling between the Validator and Encoder. We want to avoid that for ESAPI 3, therefore I am proposing to create a lightweight Canonicalizer component and move the Encoder.canonicalize methods to it. That should minimize dependencies for the Validator. ESAPI 3, since it is a major change and thus is permitted to break interfaces, would be a good time to do that.

Many (all?) .java source files and a few remaining copies of variations of ESAPI properties files in https://github.com/ESAPI/esapi-java-legacy still have references to the old OWASP ESAPI wiki page of:
http://www.owasp.org/index.php/ESAPI
These should all be changed to the new URL of:
https://owasp.org/www-project-enterprise-security-api/
if any of them are copied from ESAPI 2.x and used for ESAPI 3.x.

Hey guys, is ESAPI 2.0 officially dead now? What's the status on version 3.0 - word on the street is that this is dead and isn't really maintained anymore. Being asked to move away from it now.

Hi

I use org.owasp.dependencycheck to check vulnerabilities on my project and esapi to filter all data provided by users.
Unfortunately, the owasp plugin shows a critical issue on log4j... coming for esapi module

log4j with version 1.2.17 is very old and must be replace at least by org.apache.logging.log4j » log4j-core or by org.slf4j:slf4j-api.

Could you please update the dependencies?

Thanks in advance

Any news when the first version of 3.0.0 will be released?

Thank you.

When I add esapi-2.2.3.0.jar to my OSGI project, the bundle will not load due to an unresolved reference to com.ibm.uvm.tools. Is there a circumvention for this so I can use ESAPI in my project?

Hi,

We are using latest version of esapi dependency in our project
i.e. org.owasp.esapi : esapi : 2.2.3.1

Its having log4j » log4j vulnerabilities
[9.8] [CVE-2019-17571] [log4j] [1.2.17] ( https://nvd.nist.gov/vuln/detail/CVE-2019-17571 )

Can you please upgrade log4j to log4j2?

Thanks.

Our static code scanner reports that the latest version of ESAPI (2.5.1.0) depends on the Apache Commons FileUpload library version 1.4 which is vulnerable to CVE-2023-24998

Are you planning on releasing a new version that uses version 1.5 and configures it so that the vulnerability is mitigated by default:

Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured.

If not, can you recommend a way to address this vulnerability report?

The filters class cannot be use after the migration to jakarta EE because class as org.owasp.filters.ClickjackFilter still referer to javax.* instead of jakarta.*

Junit test:

    @Test
    public void testESAPIPercentEncoding() {
        String input = "%E2%84%A2";
        String expected = "™";
        Encoder e = ESAPI.encoder();
        assertEquals(expected, e.canonicalize(input));
    }

ESAPI.validator().getValidInput("HTTP header value (" + name + "): " + value, value, "HTTPHeaderValue", 150, true);

if found length limit 150 in SecurityWrapperRequest.java getHeader method,but it throws a exception when is use it to get user-agent for ie8, it's 162 chractors,