[Esapi-user] ESAPI development process

Deepak Subramanian subudeepak at yahoo.com
Wed Sep 8 05:15:41 EDT 2010


Nice choice.. Will follow the same in Objective-C.

Best Regards,
Deepak Subramanian
ESAPI Objective-C



________________________________
From: Jim Manico <jim.manico at owasp.org>
To: Jeff Williams <jeff.williams at aspectsecurity.com>
Cc: "<esapi-user at lists.owasp.org>" <esapi-user at lists.owasp.org>
Sent: Wed, September 8, 2010 4:02:38 PM
Subject: Re: [Esapi-user] ESAPI development process

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
http://manico.net

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?
> 
>>>> ------>
_______________________________________________
Esapi-user mailing list
Esapi-user at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-user



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100908/e302c010/attachment.html 


More information about the Esapi-user mailing list