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

Kevin W. Wall kevin.w.wall at gmail.com
Sat Aug 29 19:21:56 EDT 2009

Chris Schmidt wrote:
> Jim
> 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 agree that at a minimum we need to point this out in the javadoc.
Whether or not this will be sufficient, I'm guessing not for all cases,
although it will certainly help.

Given the intelligent code completion mechanisms in many IDEs, I have
a feeling that many developers look solely at the method and argument
names when coding and never read the complete javadoc.

To that end, it might help to illustrate secure and insecure uses in
ESAPI Swingset as well. If there's not too many of these things, we
could show how improper of the API causes thread safety issues which
can lead to TOCTTOU security vulnerabilities. This style of showing
both secure and insecure practice is already used in ESAPI Swingset
so extending it to TOCTTOU issues should fit in rather naturally.

> 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

I really hope that it's a non-issue, and I think testing with jmeter should
be helpful. But one think I've observed in years of writing multi-threaded
code is that sometimes you have to have significant CPU parallelism to turn
up some of the nastier race conditions. At one place I consulted about
a dozen yrs ago, I wrote some multi-threaded C++ code using Posix threads.
My development was on a 4 CPU server. It worked great there. I did 2 weeks of
testing, including load testing, on an 8 CPU server and no problems there
either. It was finally deployed to a 16 CPU server and worked fine for
about 2 weeks, but after that it would fail fairly regularly, but because
it was hard to reproduce (it didn't happen when we enabled debug logging),
it was a royal pain to track down. Turned there was a small section of code
that was missing a needed critical section. A formal code inspection probably
would have found it, but that company for whom I was consulting at the time
did not believe that code inspections were worth doing.

> 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.

Jim and I are just starting to put together a schedule, but looks like it
won't be for a about 2 wks or so at the soonest so hopefully that time-frame
may work out a bit better for you.

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

More information about the OWASP-ESAPI mailing list