You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by James Adams <ja...@gamepub.com> on 2004/08/11 15:45:05 UTC
Struts security/validation
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.
At the moment I'm using the validator plugin, within my validation.xml I use the "mask" validator with the regular expression;
.....
<var-name>mask</var-name>
<var-value>^[^;"'\.\^\$\*\+\?\{\}\[\]\\\|\(\)]+$</var-value>
.....
1. Does anyone know the syntax for also preventing < > & within the regular expression bearing in mind its declared in XML?
Or is there some kind of default validator that does this?
2. Some of my action functions also take input in the url as a GET which does not go through the Validator, this is then used to access a DB, these also need to be secured. Obviously I can do this within each individual Action class, but where would be the best single place I could stop characters like < > ; & ever getting as far as the Action classes?
Any other suggestions would be much appreciated, as I couldn't find very much related to securing struts applications
many thanks in advance
regards
James
Re: Struts security/validation
Posted by Kishore Senji <ks...@gmail.com>.
On Wed, 11 Aug 2004 14:45:05 +0100, James Adams <ja...@gamepub.com> 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.
>
> At the moment I'm using the validator plugin, within my validation.xml I use the "mask" validator with the regular expression;
>
> ......
> <var-name>mask</var-name>
>
> <var-value>^[^;"'\.\^\$\*\+\?\{\}\[\]\\\|\(\)]+$</var-value>
>
> ......
>
> 1. Does anyone know the syntax for also preventing < > & within the regular expression bearing in mind its declared in XML?
In your regexp, you can specify "<" & ">" entities as "<" and
">" respectively.
>
> Or is there some kind of default validator that does this?
>
> 2. Some of my action functions also take input in the url as a GET which does not go through the Validator, this is then used to access a DB, these also need to be secured. Obviously I can do this within each individual Action class, but where would be the best single place I could stop characters like < > ; & ever getting as far as the Action classes?
>
1) You can use a strategy similar to the one described in the below url
http://wiki.apache.org/struts/StrutsCatalogBaseAction
OR
2) You can also define a custom RequestProcessor and override
processPreprocess(HttpServletRequest request, HttpServletResponse
response).
> Any other suggestions would be much appreciated, as I couldn't find very much related to securing struts applications
>
> many thanks in advance
>
> regards
>
> James
>
>
Kishore Senji.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts security/validation
Posted by Brett Connor <br...@spamcop.net>.
Craig McClanahan wrote:
>On Wed, 11 Aug 2004 10:32:04 -0700, Wiebe de Jong <wi...@shaw.ca> wrote:
>
>
>>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 hope you never have a customer named O'Reilly :-).
>
>
>
>>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 '.
>>
>>
>
>If I'm doing the SQL myself, I always use prepared statements:
>
>
Absolutely. PreparedStatement is always the way to go, depending on the
database you'll get a couple of performance gains also.
> String streetAddress = "..."; // String may have "\" and "'" characters in it
> PreparedStatement stmt = conn.prepareStatement
> ("UPDATE CUSTOMER SET STREET_ADDRESS=? WHERE CUSTID=?");
> stmt.setString(1, streetAddress);
> stmt.setInt(2, custId);
> stmt.executeUpdate();
>
>and let the JDBC driver take care of getting the sensitive characters
>escaped as needed.
>
>
In fact the drivers should not (again implementation specific) need to
do any escaping, the statement and data are seperate entities. The
statement will still contain ? (or equivalent) in the rdbms.
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
extending the html:select tag
Posted by Wiebe de Jong <wi...@shaw.ca>.
I am having trouble extending the struts html:select tag, and I hope
somebody can help me.
Naill's example at http://www.niallp.pwp.blueyonder.co.uk/#errortag shows
how to extend the text tag. I used it to extend the password tag with no
problem.
However, when I use the same method to extend the select tag, I get a
runtime error. It seems to die even before the constructor is called.
So, how do you debug tags and does anyone have a solution to make this work?
Wiebe de Jong
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Struts security/validation
Posted by Wiebe de Jong <wi...@shaw.ca>.
Craig, both you and Jim suggested that I make use of prepared statements. I
implemented my SQL using strings because it is easier to tweak during the
development phase.
Now that the project is in maintenance, moving to prepared statements is a
good idea. Probably help a bit in performance as well.
As for the XML/SOAP calls, using the serializer to create the character
entities would be good.
Thanks
Wiebe de Jong
-----Original Message-----
From: Craig McClanahan [mailto:craigmcc@gmail.com]
Sent: Wednesday, August 11, 2004 10:50 AM
To: Struts Users Mailing List
Subject: Re: Struts security/validation
On Wed, 11 Aug 2004 10:32:04 -0700, Wiebe de Jong <wi...@shaw.ca> wrote:
> 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 hope you never have a customer named O'Reilly :-).
> 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 '.
If I'm doing the SQL myself, I always use prepared statements:
String streetAddress = "..."; // String may have "\" and "'" characters in
it
PreparedStatement stmt = conn.prepareStatement
("UPDATE CUSTOMER SET STREET_ADDRESS=? WHERE CUSTID=?");
stmt.setString(1, streetAddress);
stmt.setInt(2, custId);
stmt.executeUpdate();
and let the JDBC driver take care of getting the sensitive characters
escaped as needed.
(Of course, if you're using a persistence tier abstraction like EJB or
JDO or JDBC RowSets or Hibernate or iBatis et. al., you don't need to
worry about any of this -- it all happens automatically for you.)
> For XML destined text, I disallow <, >, &, \, and ".
For XML, I use one of several strategies depending on the detailed
situation:
* Recognize that XML allows either " or ' as attribute delimiters,
so if a string includes one kind, just use the other.
* Write or use an XML serializer that translates "&" to "&"
and so on for me.
* If the XML I am writing is actually markup on a page, use
JSF components ... JSF includes APIs that do all the escaping
for you.
>
> Wiebe de Jong
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts security/validation
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 11 Aug 2004 10:32:04 -0700, Wiebe de Jong <wi...@shaw.ca> wrote:
> 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 hope you never have a customer named O'Reilly :-).
> 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 '.
If I'm doing the SQL myself, I always use prepared statements:
String streetAddress = "..."; // String may have "\" and "'" characters in it
PreparedStatement stmt = conn.prepareStatement
("UPDATE CUSTOMER SET STREET_ADDRESS=? WHERE CUSTID=?");
stmt.setString(1, streetAddress);
stmt.setInt(2, custId);
stmt.executeUpdate();
and let the JDBC driver take care of getting the sensitive characters
escaped as needed.
(Of course, if you're using a persistence tier abstraction like EJB or
JDO or JDBC RowSets or Hibernate or iBatis et. al., you don't need to
worry about any of this -- it all happens automatically for you.)
> For XML destined text, I disallow <, >, &, \, and ".
For XML, I use one of several strategies depending on the detailed situation:
* Recognize that XML allows either " or ' as attribute delimiters,
so if a string includes one kind, just use the other.
* Write or use an XML serializer that translates "&" to "&"
and so on for me.
* If the XML I am writing is actually markup on a page, use
JSF components ... JSF includes APIs that do all the escaping
for you.
>
> Wiebe de Jong
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Struts security/validation
Posted by Wiebe de Jong <wi...@shaw.ca>.
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:craigmcc@gmail.com]
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 <ja...@gamepub.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts security/validation
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 11 Aug 2004 14:45:05 +0100, James Adams <ja...@gamepub.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org