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

Jim Manico jim.manico at owasp.org
Sat Aug 29 04:09:14 EDT 2009


Kevin,

Please disagree with me, especially intelligent and respectful  
disagreement.

Hungarian notation is something I am fond of because I like verbosity;  
I'm sure those of you who know me in person are chuckling :) I enjoy  
looking at a variable and grocking it's scope and type; my mind just  
works that way. But like I said, I'm alone in this opinion in the Java  
world and I have no intention of suggesting we use it in ESAPI, nor do  
I code with HN for my employeer or clients, just my personal projects.  
Moving on, you win. I will not bring this up again, but we can  
continue this conversation in private if you like if you play nice.

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?

I think Mike is making intelligent name change suggestions. Perhaps  
Mike can  take a look at the current naming conventions and make more  
surgical suggestions?

Last, this is a all-volunteer project that moves at the speed of  
volunteers. :) If anyone wants to fund the ESAPI in some way, I'm sure  
we can move things along faster.

Jim Manico

On Aug 29, 2009, at 2:30 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  
wrote:

> 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