Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I'll add some stuff on DBI and its TaintIn setting for the next edition :)
    • And TaintOut! As far as I'm concerned, anything coming from the database is tainted as well.


    • Actually I find TaintIn barely useful. I use bind parameters for any user input being put into the database, so there’s no way to do damage there. But TaintOut is very important, because it helps XSS-proofing the code.

      • 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.



        • 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 TaintIn pretty pointless; only if I wanted to optionally

          • Lossy destructive modification is evil

            Who 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."



        • So you're sure no data will ever be put into the database via another route than your app? Rrrright.
  • Damnit, now I'm going to have to by the book. :-)