David E Jones wrote:
1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy
+1
2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... but I'm still thinking that through and am not sure if it will be a problem... it is kind of using bomb to swat a fly so collateral damage is likely
What about having an FTL decorator class for GenericValue that does escaping? That would be a simple modification to FreeMarkerWorker.java.
-Adrian
