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

Kevin W. Wall kevin.w.wall at gmail.com
Sat Aug 29 02:30:50 EDT 2009


A few minor disagreements with Jim's comments. (Am I allowed to do that
yet? Not sure if "open source" means "open forum", but Stallman's always
saying "free as in speech, not free as in beer", even though most of
us would rather have free beer. ;-)

Jim Manico wrote:
> ESAPI encoding functions are not quite statics, but a singleton pattern
> (similar performance characteristics)
> 
> ESAPI.encoder().encodeForMikeBoberski(userData); and so on.

Technically these are not SINGLETON patterns, because a singleton pattern
assures that on one object of a given type (class) will every be created
and returned.

Because we have setters for things, multiple ones _could_ be returned.
E.g., imagine these in 2 different servlets or JSPs:
	// Servlet 1
   Encoder dfltEncoder = ESAPI.encoder();
   // use dfltEncoder ...

	// Servlet 2
   ESAPI.setEncoder("com.myCompany.special.CompanyEncoder");
   Encoder otherEncoder = ESAPI.encoder();
   // use otherEncoder ...

At this point we have two different Encoders, so this is not a singleton.
(And BTW, that's a concern I have, because in the above if I were to store
come through the same first line again later on, I would--probably
unexpectedly--get a different value. And if I were storing that in a static
(class instance) variable, I could run into thread safety problems.)

It's more like one of the factory-related patterns. (I'm too tired
to remember each one or look at up right not since it's almost 2am.
That's left as an exercise for the reader.)

> We do have a coding naming convention yet - we are still jumping off of
> Jeff's extensive original work and using his style, which is clean to me.

I'm fine with it too, but there are some salient points about its use, such
as don't store values and expect them to be same object later on in a different
thread. So ought to be clear of the potential issues of this use. Even using
like
	String safeURL = ESAPI.encoder().decodeFromURL("some_URL_string");

could give potentially different results if 2 different Encoder implementations
have different semantics for decodeFromURL(String).

> I'd like to move to Hungarian notation, my preference for coding. But
> I've given up that battle long ago. Being a Java Developer who likes
> Hungarian notation is a lonely community of one.

Jim is proposing information hiding, as in "if it was hard to write, it should
be hard to read". Start with Hungarian notation and then develop Navajo
notation. Yeah, that's the ticket! :)

Surely you jest. (At least, I hope!) Hungarian notation _might_ be acceptable
in a language without strong typing like C (although I'd still argue it is
horrid even there; Dennis Ritchie would probably switch to Pascal if he had
to use Hungarian notation ito code in C ;-) for a language with strong typing
and especially in the day and age of IDEs, I think it is pretty hard to defend.

> And Mike, we are lucky to have active volunteers, I'm not a fan of a big
> name change for the 2.0 release, which will be ready soon. :) Can we
> revisit the name change game post 2.0?

Well, two things here. First of all, I think Mike _may_ have been talking
about name changes in ESAPI PHP...at least that's what he provided examples
from.

Secondly, if we DO think a name change is in order, I do think that sooner
rather than later is the better option, especially if you can deprecate the
older name(s) now but keep them for a point release or two to give people
time to switch. Stability in interfaces is very important for generally
reusable class libraries so one can't just refactor whenever one would
like. However, having said that, if a change is truly in order, I think
it is better to do it sooner rather than later for the simple reason that
there likely are much less users of EASPI Java 1.4 than there will be
for ESAPI Java 2.0. The larger your user community grows, the harder it will
be to make such changes. (Which means if we are putting things into 2.0
that we are not comfortable with, we probably should state in a CAVEAT in
the Javadoc that the particular interface or semantics, etc. is tentative
and may change in a future release.)

I think that Mike should make his case / proposal for what he thinks needs
to be changed and we discuss it and weigh the pros and cons. That way we
can judge the impact and allow the community to have a voice as well.

Just my $.02,
-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


More information about the OWASP-ESAPI mailing list