You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Laurie Harper <la...@holoweb.net> on 2008/10/07 18:27:28 UTC
Re: Using POSIX Regular Expressions for Internationalized Validation
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.
egetchell wrote:
> Greg,
>
> Thanks for the reply.
>
> The common approach for mitigating XSS is to provide a blacklist of XSS
> enabling characters, enables would include "<", ">", "%3f", etc. However,
> these filters are easily bypassed by clever encoding constructs, so the
> blacklist concept quickly fails and the site is open for attack.
>
> By inverting the solution and supplying only the allowed set of characters,
> the site remains secure no matter what clever encoding scheme someone dreams
> up.
>
> The OWASP group provides some pretty extensive documentation around this.
> Here is a direct link to some common validation strategies:
> http://www.owasp.org/index.php/Data_Validation#Data_Validation_Strategies
>
> Their document, as a whole, is a very intereseting read.
>
>
> Greg Lindholm wrote:
>> Sorry, I've never heard of whitelisting of allowable characters as being a
>> "normal" approach. <Remainder Removed>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Using POSIX Regular Expressions for Internationalized Validation
Posted by Jishnu Viswanath <ji...@tavant.com>.
Hi,
Any way you want to unescape, something you escaped, I don't
know but what ever you put in the text field is got from the getter
public String getFieldName(){
//TODO: Decode/Unescape here
return this.fieldName;
}
Regards,
Jishnu Viswanath
Software Engineer
*(+9180)41190300 - 222(Ext) ll * ( + 91 ) 9731209330ll
Tavant Technologies Inc.,
www.tavant.com
PEOPLE :: PASSION :: EXCELLENCE
-----Original Message-----
From: egetchell [mailto:eric.getchell@distributedlogic.com]
Sent: Wednesday, October 08, 2008 1:48 AM
To: user@struts.apache.org
Subject: Re: Using POSIX Regular Expressions for Internationalized
Validation
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-Internationali
zed-Validation-tp19844314p19866354.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Any comments or statements made in this email are not necessarily those of Tavant Technologies.
The information transmitted is intended only for the person or entity to which it is addressed and may
contain confidential and/or privileged material. If you have received this in error, please contact the
sender and delete the material from any computer. All e-mails sent from or to Tavant Technologies
may be subject to our monitoring procedures.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Using POSIX Regular Expressions for Internationalized
Validation
Posted by egetchell <er...@distributedlogic.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org