[OWASP-ESAPI] ESAPI-related SQLi/XSS cheat sheet questions

Jim Manico jim.manico at owasp.org
Sat Aug 29 12:28:34 EDT 2009

I do not have metrics but I am witnessing the 1.4 encoder and  
validation library being used extensively in a very high availabilty  
enviornment (many millions of hits per day) without any noticable  
threadsafety issues.

Then again, these issues tend to rear their ugly heads in inopportune  
times, so I think this is a prudent conversation.

And Chris, Kevin and I are planning a group code review of the  
encryptor changes, and I'd be happy to increase scope and have you  
join us.

We are also getting ready to modify the entre codebase to a custom  
form of Hungarian notion per Kevins encouragement. •wink• Just  
kidding. :)

Jim Manico

On Aug 29, 2009, at 11:52 AM, Chris Schmidt <chrisisbeef at gmail.com>  

> It is interesting the the thread safety issue reared it's head at  
> this point. I was getting ready to start going through the classes  
> in the ESAPI and identifying potential thread safety issues. It  
> isn't guaranteed that we will be able to resolve any thread safety  
> issues, but at bare minimum methods and classes that are not thread  
> safe should be documented as such. Especially in a J2EE world where  
> thread safety is a much more complex issue unless you are  
> consistently thinking about it.
> I think that it is important that Jr. level developers be able to  
> use the ESAPI safely and very few developers of that level have a  
> solid grasp on thread safety in general, so the more we can do to  
> help these developers mitigate thread safety issues, the better off  
> the world will be. :)
> I will keep the list posted as to potential issues I find and my  
> proposed solutions, if any.
> Chris
> On Sat, Aug 29, 2009 at 7:12 AM, Kevin W. Wall  
> <kevin.w.wall at gmail.com> wrote:
> Jim Manico wrote:
> > Kevin,
> > ...
> > The case where a developer is using multiple implementations of the
> > encoder seems odd to me a best, but I get your edge-case-ish  
> point. Do
> > you have a suggestion to clean this up?
> Given enough developers to use ESAPI Java, someone likely will do
> this. If we want to keep the same interfaces, then we could simply
> point out warnings, or we could make the 'setters' protected, which
> would require them to subclass the ESAPI class first to do something
> stupid like this. I really haven't thought very hard about  
> alternatives
> at this point. I'll ruminate a bit more on it to see if I come up with
> anything. But making classes reusable, extensible, and also thread- 
> safe
> w/out a big performance hit is not a simple task.
> -kevin
> --
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts  
> agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of  
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090829/1d8f7819/attachment.html 

More information about the OWASP-ESAPI mailing list