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

Chris Schmidt chrisisbeef at gmail.com
Sat Aug 29 11:52:58 EDT 2009

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.


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 MIME
> _______________________________________________
> 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/8dabd34d/attachment.html 

More information about the OWASP-ESAPI mailing list