-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter,
Peter Stavrinides wrote:
| What is the best approach to mitigate malicious code injection into
| HTML form components?
That depends on what you are trying to protect against. There are
several "malicious" messages that could be sent through HTTP request
parameters.
1. Names/values that are too long for some poorly-managed buffer in the
~ server software. This is not an issue for Tomcat because Java does
~ not allow executable data, so no buffer-overrun errors (unless the
~ JIT is /really/ broken).
2. HTML/javascript in values that eventually get displayed on web pages.
~ This is your basic XSS vulnerability. The best defense against this
~ is to properly escape all outgoing data. The problem with proactively
~ "protecting" yourself on the front end is that you start
~ HTML-escaping data that goes into your database, log files,
~ email messages, etc. unnecessarily.
3. SQL injection attacks. If you use PreparedStatement for all your
~ database calls and you use ps.setXXX() for any data coming into
~ your server, then you can rest easy. If you do a lot of
~ "SELECT " + request.getParameter("foo") in your query-building,
~ it's time to fix all that code.
| I know that IIS has a security option to limit what can be posted to
| the server, does Tomcat have something similar?
No.
| I am looking for a
| global solution of some sort, as I have too many active forms to
| secure individually, is this possible with a filter or valve, or a
| configuration setting?
You'll have to roll anything like this yourself. If you want to protect
against XSS, you'll need to escape '<' and certain other characters to
protect output. If you want to protect against SQL injections... well,
good luck. There are so many ways to do that it's not even funny.
Is this request just coming from general paranoia (which is okay... they
really are out to get you), or is your application known to have some
vulnerability? I'm asking because security isn't really about turning on
the "secure" feature of your software. It's a pervasive, layered, and
(unfortunately) difficult beast.
Your best bet is to use best practices in both your application and your
server configuration and then audit, audit, audit. If you ever find a
product that says "set this flag and you are safe", you should probably
run away from it, because you are more likely to be giving yourself a
false sense of security more than anything else.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkg3FnEACgkQ9CaO5/Lv0PB00ACeLx7ERFS2b2BSLLPQ7YHMIR1C
kVMAn1JXbLi9CQ+Z+w/NXhqH3B7kBvwa
=fU0S
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
