[Esapi-user] Fortify vs ESAPI 2.0

Chris Schmidt chris.schmidt at owasp.org
Wed Feb 2 23:43:16 EST 2011

Oh - and please don't anyone take this as me just bashing static analysis -
I definitely think it has it's place in the world, I'm just not convinced it
is the right solution for finding security issues in API code. Like I said,
the data is useful to an extent, but we should be just glancing at these
quickly and only looking into the obvious issues like System.out'ing a
password. :)

Also Jim - while I don't have time tonite for sure, I am not sure how to
open up those fortify results you sent along... Is it just xml or something
with a custom extension?

Chris Schmidt
ESAPI Project Manager (http://www.esapi.org)
ESAPI4JS Project Owner (http://bit.ly/9hRTLH)
Blog: http://yet-another-dev.blogspot.com

On 2/2/11 9:36 PM, "Chris Schmidt" <chris.schmidt at owasp.org> wrote:

> Herein lies the problem with most static analysis - a complete lack of
> context.. This could potentially be an issue if we are ever passing
> untrusted data into this method, but this is more of a documentation issue
> that anything else I think. This is a standard utility method that *must
> never* be called without first validating the parameters. Short of that you
> are talking about adding another layer of path validation here and that is
> additional configuration as well as potential difficulty for OS specific
> validation functions. I think issues like this should be left well enough
> alone and the documentation should state that the parameters of this
> *utility method* are not validated and as such *must be validated prior to
> calling the method* according to the validation requirements of the calling
> context. 
>> 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 ) );
> In other words if I call the method like this:
>    String inFile = request.getParameter("inFile");
>    String outFile = request.getParameter("outFile");
>    if ( Base64.decodeFileToFile(inFile,outFile) {
>       // ...
>    }
> Then, yes - there is a real security issue there. However, if I am calling
> it like:
>    if ( Base64.decodeFileToFile(
>         Constants.TMP_DIR + "valid-file-" + System.currentTimeMilliseconds()
> ) {
>         // ...
>     }
> Then would you still consider that to be vulnerable code? Perhaps if the
> first argument wasn't being validated somehow, it could be possible to write
> portions of files out to a predictable location on the hard drive - but you
> are controlling that location, and you are keeping outside of the proverbial
> sandbox (hopefully) so that in order to get to that file, there would have
> to be some type of additional vulnerability (LFI) to really exploit the
> weakness. You show me the static analysis that can identify that type of
> problem and I will buy you an island.. :)
> Maybe I am looking at this too critically, but this is just one of the
> "potential issues" reported - and really if I was too spend this much time
> (10-15 minutes) analyzing each *potential finding* (and it would likely be
> more like 30-60 minutes for a good analysis of each) we would not be
> releasing GA until 2046..
> Don't get me wrong Jim - I think this kind of thing is at least valuable to
> know, and I haven't yet had a chance to actually look at the findings
> reported by Fortify, however, I think that due to the nature of the code -
> static analysis just really can't offer a super viable and accurate analysis
> of ESAPI. It is a library at the end of the day, and while there are likely
> things in the library code that have separate issues (like the System.out of
> the password) the vast majority of findings that are going to be reported
> just don't make sense since any method (if used incorrectly) could generally
> be exploited to do something wrong, somehow.
> Like you said, we aren't perfect and we definitely don't write perfect code
> - the best thing we can do with findings like these is document the intended
> purpose and hope like hell that developers pay attention to our warnings and
> documents.
> Wow - I am starting to write e-mails like Kevin; short novellas. :)
> On 2/2/11 8:34 PM, "Jim Manico" <jim.manico at owasp.org> wrote:
> Chris Schmidt
> ESAPI Project Manager (http://www.esapi.org)
> ESAPI4JS Project Owner (http://bit.ly/9hRTLH)
> Blog: http://yet-another-dev.blogspot.com
> _______________________________________________
> 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