[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Jim Manico jim.manico at owasp.org
Wed Dec 2 00:35:54 EST 2009


I like it; I'm in - and I think this exactly matches what Jeff was  
saying, too. (PCMIIW).

And I think we should drop the DOM XSS APIs for 2.0 and belay those  
changes until 2.1. That makes the change proposal fairly minimal.

So I still want to do this for 2.0, including the generic API....

Jim Manico

On Dec 2, 2009, at 12:23 AM, Chris Schmidt <chrisisbeef at gmail.com>  
wrote:

> 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.
>
> Thoughts?
>
> 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/20091202/eb19c664/attachment-0001.html 


More information about the OWASP-ESAPI mailing list