[Esapi-user] ESAPI development process

Jim Manico jim.manico at owasp.org
Wed Sep 8 04:02:38 EDT 2010

I agree with Jeff. Encoders should never throw exceptions; they are so UI heavy and we don't want JSPs and the like to throw exceptions (nor do we want extensive exception handling requirements in UI code).

+1 for making this a config issue.

-Jim Manico

On Sep 5, 2010, at 7:04 PM, "Jeff Williams" <jeff.williams at aspectsecurity.com> wrote:

> That's a dang good point. I think always throwing an exception is
> technically the right thing to do, but will cause a lot of applications
> to break and maybe scare people off using ESAPI - which is exactly what
> we don't want to do.
> I'd support an *option* for exception throwing, like
> Encoder.setIllegalCharacterMode( THROW | REPLACE );  I'd make replace
> the default.
> Maybe another to set the replacement character.
> Encoder.setReplaceCharacter(\uFFFD)?  We'd have to decide the semantics
> of Encoder.setReplaceCharacter(null).  I think it's a good idea to have
> \uFFED as the default. +1
> --Jeff
> -----Original Message-----
> From: Ed Schaller [mailto:schallee at darkmist.net] 
> Sent: Sunday, September 05, 2010 7:59 PM
> To: Jim Manico
> Cc: Jeff Williams; 'Patrick Higgins'; esapi-user at lists.owasp.org
> Subject: Re: [Esapi-user] ESAPI development process
>> Bottom Line: The 2.0 rc6/7 encoder is *much* more robust. We need to 
>> back-port the 2.0 encoder to 1.4. Any takers? :)
> Sorry for being dormant for so long. It's been busy...
> I looked seriously at syncing these up previously when I was working on
> the encoders and didn't for a couple of reasons. The difference between
> encoding was one of the main ones.
> The problem specifically here is what to do with characters which are
> invalid for the output. The ones discussed for html are prime examples
> and so is \u0000 for CSS. My preference would be having an exception
> thrown for this instead of just a replacement. If a replacement is to be
> used then I'd prefer something standard and obvious like \ufffd.
> Currently the replacement in the HTML encoder is especially troubling
> because it is a space which is specifically enumerated as a potential
> attack in html attributes in
> http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention
> _Cheat_Sheet
> rule number 2 (yes attributes should be quoted but esapi should protect
> against those who forget).
> In general I think a policy needs to be decided for whether it should be
> an exception or a replacement. If a replacement, which replacement
> should be used needs to be clear.
> Thoughts?
>>>> ------>

More information about the Esapi-user mailing list