[Esapi-user] Strange results with validator.getValidInput and SafeString

Jim Manico jim.manico at owasp.org
Wed Jan 13 21:54:21 EST 2010

> The good news is we only need to use a very small subset right now - 
> canonicalize, encodeForHtml, encodeForHtmlAttribute, and getValidInput.
Excellent! These are VERY stable in the 1.4 branch. The most so.

> But it threw me for a loop when I started throwing some real world
> data against
> getValidInput . I haven't yet rigorously tested the others, although
> canonicalize
> seems especially strong.

This only breaks, to my knowledge, when you are trying to canonize rich
input (user driven html) - and for that use case, you should use OWASP
AntiSamy - or the ESAPI HTML validation functions, which use AntiSamy
under the hood.

> It should also be an option for me to extend my own validator
> interface to "fix"
> what I find, since that isn't "changing the open source code". But my
> managers will be ... unhappy that that is needed.

You should be able to drop in your own ESAPI.properties file and define
and/or override any of the default ESAPI.properties - including adding
new validator regex definitions. This lets you extend the validator
without changing code.

I'll make sure the property files are completely outside of the jar in
ESAPI 1.4.2 which I release this week.

Jim Manico
OWASP Podcast Host/Producer

More information about the Esapi-user mailing list