[Esapi-user] Fortify vs ESAPI 2.0

Chris Schmidt chris.schmidt at owasp.org
Thu Feb 3 01:02:16 EST 2011


> This code is public because someone cut and pasted a generic Base64 chuck of
> code from another project without vetting.

Point and case about the antipattern...

>> What if I want to be able to write to a relative path that is a sibling
>> orparent of my current path from my code?
> 
> Then we build you a new secure API for that use case if the current methods
> do not satisfy your security need.

This is not an API - this is an implementation... The API should be the same
regardless of the implementation. If this is something that we feel should
be exposed in the API, it should A) not be static B) share the same
signature regardless of the implementation behind it. In other words the API
should be 

Interface MyDecoderInterface {
   boolean decodeFileToFile( ... );
} 

Class MyDecoderWithTraversalAllowed implements MyDecoderInterface { ... }
Class MyDecoderStandard implements MyDecoderInterface { ... }
Class MyDecoderTrustedInput implements MyDecoderInterface { ... }
// ...

Instead of having:

Interface MyDecoderInterface {
   boolean decodeFileToFile( ... );
   boolean decodeFileToFileWithTraversalAllowed( ... );
   boolean decodeFileToFileTrustedInput( ... );
   // ...
} 

Class MyUberDecoderImpl implements MyDecoderInterface { ... }

> Java is highly vulnerable to path traversal attacks. Jeff wrote several very
> impressive fileIO validators that will stand the test of time. With a little
> modification we can extend the APIs in a secure fashion to fit your need.

Agreed, and I think those *implementations* make a lot of sense in when
dealing with purely untrusted data.





More information about the Esapi-user mailing list