I had a similar problem, which I discovered when one of my users tried to enter a street address containing an apostrophe. Since I use apostrophes to delineate my text strings in my SQL statements, this caused a database error. I fixed it by not allowing apostrophes to be entered into any of the test fields.
I admit this is overly restrictive, but I don't know how to get the apostrophe into my database otherwise. How would you do it Craig? For SQL destined test, I disallow \ and '. For XML destined text, I disallow <, >, &, \, and ". Wiebe de Jong -----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. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
