[Esapi-user] ESAPI development process
schallee at darkmist.net
Fri Sep 10 17:41:41 EDT 2010
> My instinct says that this is the role of validation, not encoding. Could you describe your encoding exception use case one more time?
K, first there are two separate issues here: configuration of codec
parameters and the replacement of or throwing exceptions for invalid
data to encode. I'll address the latter here and the former in a
The latter problem is what to do when the user passes data to a codec
that cannot be encoded in any manner. Examples of this include null
bytes in CSS and the HTML characters mentioned earlier.
In general, this should never happen to the codec. The only way that
this could happen that I can think of is:
1. user data being reflected that has not been validated (your case)
2. developer mistakenly sending binary data or the like
Although neither of these should ever happen, the codecs still need to
handle such in a secure manner. The two options proposed have been:
1. replace invalid input with a replacement
2. throw an exception
I favor the latter as invalid data signals an invalid state which
shouldn't be ignored. Both of the two reasons I listed above for
this happening are invalid states that are indicative of other
problems. Unvalidated, or insufficiently validated data should not be
going through the encoder and may mean a probe or attack. The second
case of a developer mistake causing invalid data is a bug should be
logged and fixed as it may be causing other issues as well.
Although I have a rather strong preference here I can see the need
arising for doing replacements instead of throwing exceptions. I would,
for example, much rather see outbound data being encoded with replacements
than not being encoded at all. I can also see situations where it is
impractical to fix the code calling the codec.
So, seeing both ways as needful leads me to think a configuration option
is needed. As both methods of handling invalid input may be desired in
the same application/container (different developers, old and new code,
etc) I'd rather not see the configuration of the behavior at the JVM or
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
Url : https://lists.owasp.org/pipermail/esapi-user/attachments/20100910/cadb2fdc/attachment.bin
More information about the Esapi-user