[Esapi-dev] Question about ESAPI encoding

Mon Sep 20 00:31:45 EDT 2010

(Joined the esapi-dev list on a different email account)

Jeff, I'm proposing that doing this for just the html, html attribute,
javascript, and css codecs *shouldnt* be overly complex. I'm also
confused on how this idea would break in multiple / nested encodings
anymore than the current codecs already do.

Maybe the best way to do this is to test it out .. I'd like to
volunteer for this but I can't realistically say when I'll get around
to it. If anyone else cares to do this in the interim I'd be much
obliged.

On 9/19/10, Jeff Williams <jeff.williams at owasp.org> wrote:
> Hi Rohit, I think we’re proposing essentially the same thing, except that
> your approach doesn’t work for all the different escaping formats because it
> would be prohibitively complex to write a parser to handle them all.  The
> ESAPI Codecs are intentionally very simple to hide some of this complexity.
> It also won’t really do what you want if there are double or nested encoding
> scenarios.  You’ll end up with messed up HTML.  My assertion is that 99% of
> the time, you want to canonicalize fully, then escape properly.
>
>
>
> --Jeff
>
>
>
> From: Sethi, Rohit [mailto:rohit at securitycompass.com]
> Sent: Sunday, September 19, 2010 3:15 PM
> To: 'jeff.williams at owasp.org'; 'jim at manico.net'
> Subject: Re: Question about ESAPI encoding
>
>
>
> Jeff, forgive my ignorance on the subject. I'm not sure I understand the
> need to canonicalize prior to encoding. If there was a simple option to not
> encode existing escaped sequences for the specific codec in question then I
> believe this - without canonicalization - will still achieve the goal. For
> example looking at &amp;lt; the encoder would spot "&amp;", avoid encoding
> it, and the characters rendered in the browser would be "&lt;" which is the
> display html syntax you discussed below.
>
> I think I'm missing your point about nested encoding schemes. In what
> scenario would the above solution fail with nested encodings?
>
>
>
>   _____
>
> From: Jeff Williams <jeff.williams at owasp.org>
> To: James Manico <jim at manico.net>
> Cc: Sethi, Rohit
> Sent: Sat Sep 18 21:37:24 2010
> Subject: Re: Question about ESAPI encoding
>
> The right way to do this is to canonicalize before encode. The approach
> suggested won't work if there are multiple or nested encoding schemes used
> in the data. ESAPI used to do exactly this. But there was some pushback
> because a site that wants to display html syntax (for example) won't work
> anymore as I requires double escaping.  I like the idea of making an option
> for this at the risk of confusing some.  Actually I like better the idea of
> making this the default and providing an option to allow multiple encoding
> of a single type.
>
> --Jeff
>
>
>
> Jeff Williams
>
> Aspect Security
>
> work: 410-707-1487
>
> main: 301-604-4882
>
>
>
>
>
>
> On Sep 18, 2010, at 7:46 PM, James Manico <jim at manico.net> wrote:
>
> Jeff,
>
>
>
> Any thoughts here sir? Good idea from Rohit….
>
>
>
> Rohit, can I send this to the ESAPI-dev list?
>
>
>
> - Jim
>
>
>
> From: Sethi, Rohit [mailto:rohit at securitycompass.com]
> Sent: Thursday, September 16, 2010 5:07 AM
> To: James Manico
> Subject: Question about ESAPI encoding
>
>
>
> Jim, when creating the ESAPI encoding  has anyone thought about adding an
> optional configuration to avoid double encoding? I believe Microsoft’s
> AntiXSS library has this concept.
>
>
> Basically, when encoding if I find the existence of a potential escape
> character (e.g. &) then I traverse the next few characters to see if it
> matches a white list &lt; gt; &quot; &amp; , etc. and &#<digit><digit>;  -
> in those cases I avoid encoding those specific haracters. This allows us to
> safely wrap any tag library that might output HTML without worrying about
> double encoding.
>
>
> You could provide equivalent functionality to other codecs such as XML,
> HTMLAttributes, JavaScript, etc.
>
>
>
> Rohit Sethi
>
> Director, Professional Services
>
> Security Compass
>
> http://www.securitycompass.com
>
> Direct : 888-777-2211 ext. 102
>
> Mobile: 732.546.4473
>
> Twitter: rksethi
>
>
>
> **************************************************************************************************************************************************************
>
> The information in this email is confidential and may be legally privileged.
> Access to this email by anyone other than the intended addressee is
> unauthorized.  If you are not the intended recipient of this message, any
> review, disclosure, copying, distribution, retention, or any action taken or
> omitted to be taken in reliance on it is prohibited and may be unlawful. If
> you are not the intended recipient, please reply to or forward a copy of
> this message to the sender and delete the message, any attachments, and any
> copies thereof from your system.
>
> **************************************************************************************************************************************************************
>
>
>
>

-- 
Sent from my mobile device

Rohit Sethi
Security Compass
http://www.securitycompass.com
twitter: rksethi