use Perl

• DBI and TaintIn (Score:2)

  by brian_d_foy (44)

  I'll add some stuff on DBI and its TaintIn setting for the next edition :)
  • Re: (Score:2)

    by petdance (2468)

    And TaintOut! As far as I'm concerned, anything coming from the database is tainted as well.

    --
    

    --
    xoa
  • Re: (Score:1)

    by Aristotle (5147)

    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.
    • Re: (Score:2)

      by petdance (2468)

      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.

      --
      

      --
      xoa
      • Re: (Score:1)

        by Aristotle (5147)

        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
        • Re: (Score:2)

          by petdance (2468)

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

          --
          

          --
          xoa
      • Re: (Score:2)

        by bart (450)

        So you're sure no data will ever be put into the database via another route than your app? Rrrright.
• One of my favorite topics. (Score:1)

  by jk2addict (4946)

  Damnit, now I'm going to have to by the book. :-)