> -----Original Message-----
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 11, 2004 10:21 AM
> To: Struts Users Mailing List
> Subject: Re: Struts security/validation
> 
> 
> On Wed, 11 Aug 2004 14:45:05 +0100, James Adams 
> <[EMAIL PROTECTED]> wrote:
> > Hello all,
> > 
> > I'm in the process of trying to secure my struts 
> application against "Cross site scripting", "SQL injection" 
> style attacks.
> > 
> > One of the things I'm doing to prevent this is trying to 
> restrict special characters (;.<>(){}...etc) getting beyond 
> the validator.
> > 
> 
> Just thinking out loud for a moment ...
> 
> Cross site scripting attacks don't happen when sensitive characters
> are inside an *input* field.  The problem comes if you *output* the
> data without filtering for them.  That's why the Struts <bean:write>
> tag, for example, filters "<", ">", "&", and ";" for you unless you
> explicitly tell it not to, so if you are diligent about how you copy
> your database data to output pages, you can safely accept these kinds
> of character in input.
> 
> I notice that Kishore Senji (one of the other respondents in this
> thread) is using Google's Gmail, just as I am at the moment.  Since
> this is a web application, it's a good thing that Googe isn't
> disallowing the magic characters on input into a textarea, or else we
> would not be able to participate in this conversation :-).
> 
> Is filtering input really the appropriate strategy for dealing with
> this problem?  If successful it will certainly help, but the approach
> strikes me as overly restrictive for most application needs.

It can be appropriate, you might eventually need to turn off that filtering.  It may 
be possible to legitametley allow such characters.  The immediate example I can think 
of is content management.  You could jump through hoops ( ex. Wiki's) to not use html 
to mark up the input.... but why?
If you do it on input, you definitiely need more then just grepping on characters, you 
need to look at what the content is.  Looking for a <javascript  tag is good.  Maybe 
running the input through a javascript parser is even better.  Lots of ways to do it.  
The best reason for doing it on input, is SQL injection and Cross Site Scripting 
attacks are bad data.  Bad data should not make into the datbase.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to