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

mike.waters at comcast.net mike.waters at comcast.net
Thu Feb 3 11:11:15 EST 2011

My $0.02 as a user of ESAPI. 


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? 


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. 


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? 


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. 


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

More information about the Esapi-user mailing list