[Esapi-user] Fortify vs ESAPI 2.0

Jim Manico jim.manico at owasp.org
Thu Feb 3 01:13:04 EST 2011


We are in agreement about cut and pasting code from other projects. Good!

The design your are suggesting below is very flexible for a framework, but overkill for a simple security API. We are about to split ways (core and framework) and shall meet in the middle in a few months. :)

I still think that ALL FileIO •public• APIs should assume that input data is untrusted and therefor require strong validation. Anything else does not belong in ESAPI!

-Jim Manico
http://manico.net

On Feb 3, 2011, at 12:02 AM, Chris Schmidt <chris.schmidt at owasp.org> wrote:

> 
>> 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