I just read the security chapter in Mastering Perl. It should be required reading for anyone who does any Perl programming for the web. brian's discussion of tainting is the best I've seen yet. I only wish he'd mentioned tainting and DBI.
Re:DBI and TaintIn
petdance on 2007-08-10T18:36:37
And TaintOut! As far as I'm concerned, anything coming from the database is tainted as well.Re:DBI and TaintIn
Aristotle on 2007-08-11T02:15:22
Actually I find
TaintInbarely useful. I use bind parameters for any user input being put into the database, so there’s no way to do damage there. ButTaintOutis very important, because it helps XSS-proofing the code.Re:DBI and TaintIn
petdance on 2007-08-11T03:17:05
so there’s no way to do damage there.It's an issue of philosophy, not practicality. You shouldn't be putting anything tainted into a database, where it becomes untainted. It's a big reminder.
Re:DBI and TaintIn
Aristotle on 2007-08-11T03:41:10
It’s an issue of philosophy alright. In my case, I prefer to preserve pristine copies of all user input. Lossy destructive modification is evil: it destroys all possibility to investigate the original data in the future, or re-munge it if your algorithms happen to change.
So if I get as far as committing the data to storage, then it’ll be unmodified, meaning I’ll have to scrub/disarm/convert it when I pull it out. This stance makes
TaintInpretty pointless; only if I wanted to optionally reject input outright would it help me at all.Re:DBI and TaintIn
petdance on 2007-08-11T04:13:19
Lossy destructive modification is evilWho said "lossy destructive"? I'm just suggesting using taint mode as a seat belt to remind you "hey, you haven't validated this data field before you slam it into the database."
Re:DBI and TaintIn
bart on 2007-08-12T17:05:34
So you're sure no data will ever be put into the database via another route than your app? Rrrright.
