Ok, this is my argument for filtering input:
1) I don't want bad code (javascript or other) making into my db in the
first place, ever.
2) You have to validate as input comes in anyways and THIS is where your
validation logic is housed:
- if field is Date, check it; 'username' then ^[a-zA-Z0-9]{5,20}$ ,
if allow HTML, filter for XSS
3) HTML code is a lot of characters and a DB can only hold so much, so I
want to filter/condense here anyways.
4) Of course for any nonHTML output fields, I can use <bean> tag to
output and encode anyways.
5) My XSS stuff is in one class, easy to maintain.
I guess I just don't see an argument for filtering it on the way out.
What if you miss something?
-Joe
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joseph,
Joseph McGranaghan wrote:
I [hear that worrying about XSS is not worth it] all the time, am I
missing something?
What if you want the user to be able to input all kinds of
markup to be redisplayed:
<div style="color:#ff000;">
<a href="http://somewhere.com";>somewhere</a>
</div>
At some point this makes it back into the page so the browser can render
it.
If this discussion is useless, I am severely misguided and probably
wasting time.
You have a special case when you /want/ to allow users to use HTML
markup. Leon was pointing out that spending a lot of time running all
input through an XSS-sanitizer is not worth it.
If you /are/ capturing text you will be using that /can/ contain HTML
markup, then cleaning it as it comes in is still a mistake. Let's say
you have a bug in your cleansing code. In that case, bad stuff gets into
your database where it's hard to root out and fix.
If you always run "normal" output through a '<' and '>' filter, and then
always run your "HTML" output through your XSS cleanser, then you're
always okay as long as your XSS cleaner is up-to-date. That is, if you
have to make a change to the XSS-cleaner, then all output benefits,
instead of having /some/ clean input and some not-so-clean input that
you will blindly output at a later time.
I agree with Leon: cleaning input is not usually a good idea. Cleaning
output is where the real money is -- from a security and maintainability
standpoint.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF+c979CaO5/Lv0PARAo/+AKCMJIAe42ulV4Wg1dSWwVBLgeAk2wCeNRKF
zaXOtvr4eW+dbpR3Va/5ktA=
=A+z6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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]
