[Esapi-user] Fortify vs ESAPI 2.0

Jim Manico jim.manico at owasp.org
Wed Feb 2 22:54:08 EST 2011


I fixed this problem, Chris. The solution is of removing those system
out's is checked in.

And please, no shame. Mistakes happen. Plus, it was Jeff's code from the
original codebase. :P

Let he who writes the perfect code throw the first stone. (or more like,
the 10th stone in our case).

If you have a moment, check out the Fortify data. Lots of interesting
stuff in there (as well as tons of FP to wade through).

Regards,
- Jim

> I agree with that as well - but that system out is inexcusable. 
> 
> Sent from my iPwn
> 
> On Feb 2, 2011, at 8: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
>> _______________________________________________
>> Esapi-user mailing list
>> Esapi-user at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/esapi-user



More information about the Esapi-user mailing list