+9180)41190300 - 222(Ext) ll * ( + 91 ) 9731209330ll
Tavant Technologies Inc.,
www.tavant.com
PEOPLE :: PASSION :: EXCELLENCE
-Original Message-
From: egetchell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 1:48 AM
To: user@struts.apache.org
Subject: Re: Using POSIX Re
Everything is clear now. I had misunderstood the previous posts as
suggestions to physically alter the user’s input via HTML
escaping/unescaping at the boundary layer of Struts.
I totally agree with this XSS mitigation approach and have added the
escape=”true” attribute to all our property tag
From: egetchell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 11:56 AM
> The one thing I noticed is that this escaped
> data is not translated back to the character
> set when fed into an input field.
Perhaps this is an over simplification, but could you just persist the raw,
une
I did determine why POSIX regular expressions did not seem to be working.
The server-side Java-based validations work correctly, it was the
client-side JavaScript implementation that was failing when constructing the
regular expression. From my brief investigation into this, it would seem
that t
ant.com
PEOPLE :: PASSION :: EXCELLENCE
-Original Message-
From: egetchell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2008 8:02 PM
To: user@struts.apache.org
Subject: Re: Using POSIX Regular Expressions for Internationalized
Validation
Greg,
Thanks for the reply.
The comm
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 approa
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-
I can see that approach may work for certain restrictive fields like their
postal code example but as you are finding it's pretty unworkable in
multi-language unicode applications. I've always had to deal with input
fields for notes, comments, descriptions etc. where there are no
restrictions and
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 o
Sorry, I've never heard of whitelisting of allowable characters as being a
"normal" approach.
I've developed many multi-language web applications, some with Struts (1 &
2) and some without.
Typically you have to watch for 2 things; 1) when re-displaying anything a
user has entered you need to en
10 matches
Mail list logo
