[Esapi-user] Lastest emails on safe vs unsafe API calls

Chris Schmidt chrisisbeef at gmail.com
Thu Feb 3 11:19:51 EST 2011


Mike ­ I think that you are saying exactly what I was generally implying at
a later point. Methods like this should not even be exposed as part of the
API ­ this is a general purpose method, not a security method and as such
should not be exposed in a Security API.

I agree with what you said 100%


On 2/3/11 9:11 AM, "mike.waters at comcast.net" <mike.waters at comcast.net>
wrote:

> My $0.02 as a user of ESAPI.
> 
> <SNIP>
> 
> What if I want to be able to write to a relative path that is a sibling or
> parent of my current path from my code?
> </SNIP>
> 
> 
> I depend on ESAPI to prevent this.  In my opinion you are asking for 'General
> Purpose' behavior from a security library.  I believe that all public
> interfaces into the API should assume they are receiving untrusted data.  The
> only way I would even consider allowing (at least in my shop) what you are
> asking for is if the method name clearly states it is for trusted data - but
> then I still have reservations.  Upstream changes from your previously
> sanitized data may become unsanitized (e.g. a new path of code execution is
> introduced), or perhaps a new developer sees that code XYZ is calling method
> doSomethingWithTrustedData(), so they call the same method with untrusted
> data.  It just isn't safe.  You can accidentally refactor yourself into
> trouble in this model.
> 
> 
> <SNIP> 
> Now we have provided a broken API by adding this validation. You are battling
> 2 specifications here, and I think that causes some problems. I personally
> have used some of the ESAPI utility functions for things that had absolutely
> nadda to do with the webapp itself, just because they were available to use.
> So do we go out on the limb and say that ESAPI utilty functions should always
> assume that *all data* being handed to them is from an untrusted source?
> </SNIP>
> 
> 
> Again, I believe that you are asking for 'General Purpose' functionality from
> a security API if you start assuming trusted data.
> 
>  
> <SNIP>
> 
> I think that is really what all of my side of the debate boils down to - being
> a security API - should it be implied that the methods we provide will treat
> all data as untrusted data - when in fact, a good deal of the time - the code
> that calls utility methods like this will not in fact be calling it with
> untrusted data? (at least in any app that I wrote - perhaps that is just my
> way of thinking tho)
> </SNIP>
> 
> In my opinion, Yes, all public methods should assume data is untrusted.  Even
> if we end up spending a few more clock cycles because of this, I am ok with
> that.
> 
> Again, just my opinion, but this is how I would like to see the product move
> forward.
> 
> Thanks for your time.  You are building a good product.  Keep up the good
> work.
> 
> -Mike
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20110203/22f9ca99/attachment.html 


More information about the Esapi-user mailing list