[Esapi-user] Fortify vs ESAPI 2.0

Thu Feb 3 20:32:09 EST 2011

Very good point(s) Kevin. And thoughts on this John?

-Jim Manico
http://manico.net

On Feb 2, 2011, at 10:00 PM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:

> 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.
> [SNIP]
>>> (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.
> 
> -kevin
> -------------
> ** 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
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user