Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'll add some stuff on DBI and its TaintIn setting for the next edition :)
    • 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.

        --

        --
        xoa

        • 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 reject input outright would it help me at all.

          • 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