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

Chris Schmidt chrisisbeef at gmail.com
Sat Aug 29 13:22:37 EDT 2009


My thread safety point was primarily aimed at Jr level developers and  
small projects that said developers usually end up coding things they  
may not fully understand. At the very least the documentation should  
call out potential thread safety issues within classes.

I can say at this point I have manually reviewed about a third of the  
code and haven't notice anything that stands out that isn't  
documented, so this may be a non issue completely, however I also plan  
on putting together some jmeter teats that can be run against a very  
basic webapp using all the features of esapi under load with several  
concurrent threads at once to get a good comprehensive snapshot of  
potential problem areas

As for the group code review I would be more than happy to lend my  
eyes to it as well, time is a little difficult to come by right now  
but I will do what o can.

Sent from my iPwn

On Aug 29, 2009, at 10:28 AM, Jim Manico <jim.manico at owasp.org> wrote:

> 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>  
> wrote:
>> 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/7f2cd5b6/attachment.html 

More information about the OWASP-ESAPI mailing list