[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Chris Schmidt chrisisbeef at gmail.com
Wed Dec 2 00:23:26 EST 2009

Is there any reason that we cannot provide both?

There are certainly cases where an approach like I suggested would be ideal
(such as with DSL's and the like) but I also agree that in 90% of the cases,
having ESAPI.encoder().encoderForHTML( stuff ) will be not only sufficient,
but ideal.

Under the covers, why couldn't ESAPI.encoder().encodeForHTML( stuff )
delegate to encoder.encode( EncoderTarget.HTML_DOC, stuff ) or something
similar. In that case, we appease the K.I.S.S. paradigm while providing a
rich API when it is needed.

I personally work with Apache Lucene *alot* and this is the way that the
Apache guys solved similar problems with text analysis. They provide simple
implementations of Analysis algorythms out of the box that can be plugged in
anywhere, but also expose a rich API that allows developers to do just about
anything they want with text and tokens where requirements necessitate it.


On Mon, Nov 30, 2009 at 11:11 PM, Kevin W. Wall <kevin.w.wall at gmail.com>wrote:

> Jim Manico wrote:
> > Jeff,
> >
> > I love this extensibly and complexity under the hood.
> >
> > But in the spirit of easy for developers, •nothing• in my mind beats
> > ESAPI.encodeForHTML and the like. Then, we can provide explicit JavaDoc
> > for each function and encoding use case, hopefully making it abundantly
> > clear to a developer when to use each encoder function. If we genericise
> > overly much, we make our (ESAPI dev team) lives easier at the expense of
> > more complex APIs for end developers. In that vein, I still want to see
> > encodeForMySQL and encodeForOracle return.
> >
> > And this battle, easy APIs vs genericism - it's an epic struggle like
> > good vs evil and Jedi vs sith, etc. It's not a battle that is easily won.
> My $.02 on this, is that in general, it is better to make things simpler
> for the general web application developers who will be _using_ ESAPI than
> to favor easing the development of the ESAPI dev teams. As tempting as the
> latter may seem (to make our lives simpler) it _almost_ always is the wrong
> thing to do. The ESAPI dev team only needs to get it correct once (or
> perhaps
> a few times, at most), whereas each web application developer using ESAPI
> has to get it correct each time they use these encoders, which could be
> hundreds, if not thousands of times for a given application. If it's too
> clumsy to use, it won't be used at all and hence the vulnerabilities
> that would otherwise be prevented will not be plugged and instead could
> many times be responsible as the root case of many actual security
> breaches.
> (Translation: It doesn't help if its not used or not used correctly.)
> Also, we are (supposedly ;-) the security experts so it should be easier
> for us to get it correct once in the ESAPI API than for web application
> developers using ESAPI to get correct if the API is cumbersome to use.
> So, IMO, if you must choose, keep things simple for the end user rather
> than
> making them simple for the API developer. The only exception I would make
> to this is that if making things simple for the end user complicates things
> for the API developer to such a degree that it results in much higher code
> and/or design complexity, then you may want to rethink things on a
> case-by-case
> basis in order to arrive at the right balance since the additional
> complexity
> itself will lead to more insecure code.
> Other than that, if this functionality was in ESAPI 1.4 (I've not looked),
> then it behooves us to deprecate the interfaces you are trying to get
> rid of ASAP (preferably in ESAPI 2.0). That would of course imply some
> alternative APIs to use instead. OTOH, if this functionality was not in
> 1.4, I would not advise rushing to get it into 2.0...waiting until 2.1
> in this case should be perfectly fine...instead, just note the absence of
> such
> functionality in the ESAPI documentation.
> However from where I sit, there does not seem to a general consensus on
> what the API for these encode changes should look like, so if at all
> possible, I would advise that we mull it over and not rush putting
> something in place that is not well thought out. (Been there, done
> that and you don't want to go there.) That, plus as someone (Mike B.,
> think) mentioned, it *is* rather late in the 2.0 development cycle to
> put this in if the intent is to complete ESAPI 2.0 by YE2009.
> -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/20091201/60a75644/attachment-0001.html 

More information about the OWASP-ESAPI mailing list