-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe,
Joseph McGranaghan wrote: > Ok, this is my argument for filtering input: (Note that I'm sure we can argue all day over whether input vs. output filtering is better; I'd prefer to state my opinion and get on with it). > 1) I don't want bad code (javascript or other) making into my db in the > first place, ever. You can't prevent this unless you are sure your cleansing algorithm is correct. If you are confident in your cleansing algorithm and you feel better about input filtering, go ahead and do it. I'm certainly not going to stop you. > 5) My XSS stuff is in one class, easy to maintain. This should be a given. > I guess I just don't see an argument for filtering it on the way out. > What if you miss something? What if you miss something on the way out? If you miss something on tht way out, you could easily have missed it on the way in. This is not a valid question. I assert that it's easier (in real practice) to modify an output cleanser than an input cleanser, since you have to go back and re-clean all your old data. That's pretty much it. App servers scale horizontally; if you can't afford the CPU cycles to clean on output with your current deployment, then buy more app servers. DB servers are trickier, and when you need to re-clean a great deal of data in your database, the CPU cycle cost is much more. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+rMH9CaO5/Lv0PARAhWLAJ9aDghyvFWKVr5p4mcbQbOd/PuEUwCgsSQ3 jmPC/HuMcViG7RITSB3oP8g= =hQF0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
