[Esapi-user] ESAPI development process

Ed Schaller schallee at darkmist.net
Sun Sep 5 19:58:49 EDT 2010


> 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?

>>>------>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.owasp.org/pipermail/esapi-user/attachments/20100905/1513008c/attachment.bin 


More information about the Esapi-user mailing list