[Esapi-user] Fortify vs ESAPI 2.0

Kevin W. Wall kevin.w.wall at gmail.com
Wed Feb 2 23:00:45 EST 2011

On 02/02/2011 10:43 PM, Jeffrey Walton wrote:
> On Wed, Feb 2, 2011 at 10:34 PM, Jim Manico <jim.manico at owasp.org> wrote:
>> I'm running the latest version of Fortify 360 against the trunk of ESAPI 2.0.
>> (and privacy issues leaking password data)
>>    protected DefaultUser getUserFromRememberToken() {
>>        try {
>> .
>> .
>> .
>>            String username = data[0];
>>            String password = data[1];
>>            System.out.println("DATA0: " + username);
>>            System.out.println("DATA1:" + password);
> The issue with passwords is confirmed. A Oracle/Sun example of PBE can
> be found at http://download.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html.
> Scroll about half way down to "Using Password-Based Encryption":
>     It would seem logical to collect and store the password in
>     an object of type java.lang.String. However, here's the
>     caveat: Objects of type String are immutable, i.e., there are
>     no methods defined that allow you to change (overwrite) or
>     zero out the contents of a String after usage. This feature
>     makes String objects unsuitable for storing security sensitive
>     information such as user passwords. You should always
>     collect and store security sensitive information in a char
>     array instead.

True, that. And "leaking" it to stdout even worse. :)

That said, in some sense you are screwed by the Java Servlet
interface. The way that Sun (or should we blame it on Oracle now?)
defined HttpServletRequest, just about any way that you are going
to get any information from a web client is going to return a String.
So, sure, you can xlate it into a char[] or byte[], but what do you
do with the original String reference? The best you can hope for**
is to set it to null and hope the GC runs and the memory is soon
reused. (You dare not call System.gc(), at least not every time.)

So in some sense you are screwed against certain attacks. Apparently
the fools who wrote this particular API believed that no one ever
shared servers and that all servers were otherwise secure.

** In reality, if one is not using a Java SecurityManager, one can use
   one of the clever reflection tricks described by Jeff Williams in
   "Enterprise Java Rootkits" paper presented at BH USA 2009.
Kevin W. Wall
"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, co-creator of MIME

More information about the Esapi-user mailing list