[Esapi-user] ESAPI development process

Patrick Higgins patrick.allen.higgins at gmail.com
Wed Sep 8 17:38:31 EDT 2010

I agree that the space character is a bad choice for replacement--I
thought of the attribute attack as soon as I saw it but then forgot
about it. :-(

I can  work on a patch for this on the 2.0 and 1.4 branches as soon as
I finish up a small project here at work in the next day or two.


On Sun, Sep 5, 2010 at 5:58 PM, Ed Schaller <schallee at darkmist.net> wrote:
>> 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?
> Version: GnuPG v1.4.10 (GNU/Linux)
> Vf4AoIeR3C5/GNXz8ZIrmDdxAEutQP4f
> =bQXN

More information about the Esapi-user mailing list