[Esapi-dev] New "ESAPI for Java" release - 2.1.0

Kevin W. Wall kevin.w.wall at gmail.com
Tue Sep 3 03:45:09 UTC 2013


All,

A new version of ESAPI, release 2.1.0, has been uploaded to
both the Google Code downloads list as well as being made
available via Maven Central.

Full release notes are available with the Google Code download at
<http://code.google.com/p/owasp-esapi-java/downloads/detail?name=esapi-2.1.0-dist.zip&can=2&q=>

Most importantly, if fixes Google Issue #306 which is closed with this
release. See
<http://code.google.com/p/owasp-esapi-java/issues/detail?can=1&q=306&colspec=ID%20Type%20Status%20Priority%20Milestone%20Component%20Owner%20Summary&sort=-id&id=306>
for details of that issue.

Please note that this new ESAPI jar (esapi-2.1.0.jar) is *NOT* a
signed jar. OWASP's code signing certificate had expired. We will
sign the jar and re-release this (or possibly another patch release)
once we obtain the new code signing certificate.

Note that if you had been following along the discussion of Philippe Arteau's
finds first posted to the ESAPI-Dev mailing list (for details, see
<http://lists.owasp.org/pipermail/esapi-dev/2013-August/002285.html>),
this is what Google Issue #306 addresses. I have applied for a CVE identifier,
and once obtained, we will left everyone know the CVE ID and get this
appropriately documented for NIST's NVD, etc.

While technically, this Google Issue is an "exposure" rather than a
"vulnerability" (in Mitre's usage of the terms at https://cve.mitre.org/),
it is still important that you patch this, especially if you were using
ESAPI's symmetric crypto with CBC mode (the default) to encrypt something
that might be exposed to the Internet, such as HTTP parameters or
HTTP cookies, as this exposure would allow one to develop a padding
oracle attack. (Note that if you are using one of the "combined"
cipher modes such as CCM or GCM, you would not be affected by this
issue.)

Finally, while it looks as though there were a lot of files recently
changed (there were), the actual fix boiled down to changing 2 lines
of code...one to change a log message and the other to return 'false'
rather than 'true'. Because that original code branch was there to
handle backward compatibility with ESAPI 1.4 (in hindsight, a really
bad idea; my bad for not resisting more than I did), changing the
code to return 'false' broke that backward compatibility. Consequently,
I removed the deprecated encrypt() / decrypt() methods from the Encryptor
interface. Most of the other changes was either new test cases, general
code cleanup, or related to the removal of those interface methods.

If you have any questions, feel free to send them to the list or directly
to me and I will attempt to answer them as I find time.

Compute securely,
-kevin
P.S.- Special thanks to Philippe Arteau for bringing this to our
attention and to Chris Schmidt for building the
        final release deployment and fixing the pom.xml that I had
apparently screwed up.
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein


More information about the Esapi-dev mailing list