[Esapi-user] ESAPI development process
jeff.williams at aspectsecurity.com
Sun Sep 5 22:04:42 EDT 2010
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
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
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
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.
More information about the Esapi-user