[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Jeff Williams jeff.williams at owasp.org
Fri Dec 4 13:37:13 EST 2009


This seems confusing to me.  It's really important that the developer
understands what order the Codecs are being applied in.  Otherwise they
won't get what they expect.  Any thoughts on the CodecChain class I
suggested before?  You'd end up with something like.

 

CodecChain embeddedURLCodecChain = new CodecChain();

embeddedURLCodecChain.addCodec( new PercentEncoder() );

embeddedURLCodecChain.addCodec( new HTMLEntityCodec() );

embeddedURLCodecChain.addCodec( new JavaScriptCodec() );

 

String url = ESAPI.encoder.encode( input, embeddedURLCodecChain );

<%=url%>

 

--Jeff

 

 

From: Chris Schmidt [mailto:chrisisbeef at gmail.com] 
Sent: Friday, December 04, 2009 12:51 PM
To: Jeff Williams
Cc: Dan Cornell; Jim Manico; owasp-esapi; Mike Boberski
Subject: Re: [OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

 

Also - for the use case, I think allowing Codecs to be chained with
Constructor injection would be a good idea... 

 

ESAPI.encoder().encode( new HTMLParameterEncoder( new FlashVarEncoder( new
SOAPEncoder() ), input );

On Fri, Dec 4, 2009 at 9:49 AM, Jeff Williams <jeff.williams at owasp.org>
wrote:

In this case, I think we're okay. The DefaultValidator follows the same
pattern we're suggesting here. Most common usage will be through the
ESAPI.encoder() interface.  But the implementation will rely on a set of
powerful Codecs under the hood.  Advanced users can use these Codecs
directly if they're doing something unusual.

--Jeff



-----Original Message-----
From: owasp-esapi-bounces at lists.owasp.org

[mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Dan Cornell
Sent: Wednesday, December 02, 2009 12:13 PM
To: Jim Manico

Cc: owasp-esapi; Dan; Mike Boberski
Subject: Re: [OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

I agree that simple takes precedence over generic.  There is nothing
worse than overwrought, over-OO-patterned APIs that make it hard to do
common things. In fact if I recall an original goal of ESAPI was to
make secure coding easy for the average developer

 However I would be a little concerned that "both" would be
potentially confusing (hence not simple)

Thanks

Dan


Sent from my iPhone

On Dec 2, 2009, at 10:44 AM, "Jim Manico" <jim.manico at owasp.org> wrote:

> I think the "simple" APIs are more important and I was worried they
> were going away for generic APIs. "Both" is ideal.
>
> - Jim
>
> On Dec 2, 2009, at 12:40 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>
> wrote:
>
>> Chris Schmidt 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?
>>
>> Both/and rather than either/or makes sense. I just can't comment on
>> how
>> feasible or simple it is based on the fact I haven't really studied
>> this
>> particular section of code very much. To me, it just sounded as
>> though it
>> were an either/or decision based on Jim's reply to Jeff, so that was
>> what
>> I was responding to.
>>
>> -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
>
_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi

_______________________________________________
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/20091204/4f3a4f5c/attachment-0001.html 


More information about the OWASP-ESAPI mailing list