[Esapi-dev] New "ESAPI for Java" release - 2.1.0
Kevin W. Wall
kevin.w.wall at gmail.com
Tue Sep 3 04:07:17 UTC 2013
Duh! Forgot one person to thank. Special kudos to Jeffrey Walton for his
general feedback with regards to a longer term fix which is still being
designed. (This was posted to the ESAPI-Dev list last week.)
On Mon, Sep 2, 2013 at 11:45 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> 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
> Most importantly, if fixes Google Issue #306 which is closed with this
> release. See
> 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
> 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
> 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,
> 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
"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