[Esapi-user] Fortify vs ESAPI 2.0

Thu Feb 3 20:23:24 EST 2011

Very well said. 

https://www.securecoding.cert.org/confluence/display/java/MSC10-J.+Limit+the+lifetime+of+sensitive+data

...describes this threat well. 

I'll place this in the issue tracker.

Regards,

-Jim Manico
http://manico.net

On Feb 2, 2011, at 9:43 PM, Jeffrey Walton <noloader at gmail.com> 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.
>> 
>> I squashed the test cases and other unnecessary code.
>> 
>> I staged up the results here (this is the raw Fortify results file).
>> 
>> http://manico.net/ESAPI20.fpr
>> 
>> There are several false positive findings (XSS in validation exceptions, we can't encode - we do not know the context of display yet).
>> 
>> There are also several potential real findings (path manipulation in our Base64 encoder)
>> 
>> public static boolean decodeFileToFile( String infile, String outfile )
>>    {
>>        boolean success = false;
>>        java.io.InputStream in = null;
>>        java.io.OutputStream out = null;
>>        try{
>>            in  = new Base64.InputStream(
>>                      new java.io.BufferedInputStream(
>>                      new java.io.FileInputStream( infile ) ),
>>                      Base64.DECODE );
>>            out = new java.io.BufferedOutputStream( new
>> java.io.FileOutputStream( outfile ) );
>> 
>> (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.
> 
> Jeff