That’s an interesting approach you guys are proposing. I did a quick proof of concept where I coded an Interceptor that uses the Apache Commons StringEscapeUtils.escapeHtml function to update all incoming parameter values. This seems to implement what you guys suggested.
What is your approach for then displaying this data? For example, in my proof of concept, when I escape Japanese Shift-JIS input, the escaped values are persisted to the database, and rendered to the browser in the escaped format. Do you unescape the prior to persisting it data (as it did pass validation), or do you have special logic in the actions that will unescape all properties prior to the JSP page rendering the data? Eric Laurie Harper wrote: > > The validation strategy you cite is well and good when the you *have* 'a > set of tightly constrained known good values.' It's not useful in the > general case. > > Your concerns with respect to XSS should only present a problem if you > need to render untrusted HTML (such as is often the case with web-base > email applications, for example). Unless you need to preserve > user-submitted HTML, though, the correct answer is, as Greg said, to > HTML-escape all user supplied data (or at least, all user supplied data > you haven't previously sanitized via strategies such as you referenced). > > If you do that, the browser will never see anything harmful in a context > it will treat as anything other than text (i.e. it will never try to > interpret such data as markup) and therefore you wont be vulnerable. > > L. > > -- View this message in context: http://www.nabble.com/Using-POSIX-Regular-Expressions-for-Internationalized-Validation-tp19844314p19866354.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
