[OWASP-ESAPI] Encoder feedback
jim at manico.net
Wed Jul 9 01:59:18 EDT 2008
> Agree. Jim Manico just suggested this today. Are you guys talking
off the list or something?
Not at all Jeff, it's just collective Java voices calling out for more
These functions really bother me. It's leads down to a path of
nonsensical API's like
http://www.codemagi.com/api/com/codemagi/util/DbUtils.html (I authored
this a while ago.) There is almost never a need to ever use
java.util.Statement (unless one was building a Java SQL program like
DbVisulaizer) and I wish Sun would deprecate or remove the Statement
class from the language. Like you said, and like the code says "This
method is not recommended. The use (of) PreparedStatement is the normal
and preferred approach."
I know this sounds a little crazy, but would you consider permanently
deprecating this method (or the vendor-specific version of these
methods) to make a stronger point?
> Hi Ivan,
> Thanks for the excellent comments! We're in the process of revamping the
> Encoder a bit so your timing is excellent.
> Besides the extensions you proposed, what do you think of the API itself,
> independent of the reference implementation? Will developers be able to use
> it effectively?
>> implies it will convert my data into a form that can be safely passed
>> encodes data using HTML entities. I was expecting my data to be
> That's definitely a problem! Stefano di Paolo pointed this out just
> yesterday. I believe the following rules are right, right?
> Encode characters > 7f with \uhhhh
> Encode special characters <= 7f with \xhh
> Otherwise don't encode character
>> 2. For cases where nested encoding is required, are you expecting
>> users to manually chain method invocations, or is the plan to provide
>> then encode for HTML attribute).
> My inclination is to provide a convenience method for things like this. I'm
> assuming your example is for an event handler like onBlur. So I think we
>> 3. I don't understand this business of detecting double encodings:
>> firstly because that should not be a concern of an encoding library
>> and, secondly, because what you consider doubly encoded is entirely
>> legitimate: what is a developer supposed to do when his program gets
>> "&nbsp;" in input, but you respond with an exception when asked to
>> encode for HTML? How is ESAPI going to handle CMS applications?
> First, I think canonicalization definitely belongs in an encoding library.
> Second, I don't think that your example *is* legitimate. Or maybe it's just
> a bad idea. Either way, I think what "&nbsp;" means is " " and
> that's what the application should validate. As long as we continue to
> tolerate double encoding and multiple-encoding schemes we will never be able
> to detect or prevent buried attacks.
>> Maybe I just don't understand what the method is doing? For example,
>> when I pass "&" to it, I get "&" back. I was expecting to get
> Do you have a use case for why you would want "&amp;"? The vast majority
> of applications do not need this. Of course, there are a few applications,
> like HTML tutorials, that need this kind of thing. In that case, you don't
> want the canonicalized version, so I think we need to add a way to
> *validate* the canonical version but *use* the raw version.
>> 4. I think encodeForCSS should be added.
> Totally agree. Got a good reference for CSS encoding?
>> 5. encodeForSQL looks dangerous in principle: different SQL dialects
>> use different meta-characters so it's not possible to handle all
>> dialects with only one function. Something like encodeForMySQL would
>> be better.
> Agree. Jim Manico just suggested this today. Are you guys talking off the
> list or something?
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
Jim Manico, Senior Application Security Engineer
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)
Securing your applications at the source
Management, Developers, Security Professionals ...
... can only result in one thing. BETTER SECURITY.
Sept 22nd-25th 2008
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-ESAPI