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

use Perl Log In

Log In

[ Create a new account ]

petdance (2468)

petdance
  andy@petdance.com
http://www.perlbuzz.com/
AOL IM: petdance (Add Buddy, Send Message)
Yahoo! ID: petdance (Add User, Send Message)
Jabber: petdance@gmail.com
I'm Andy Lester, and I like to test stuff. I also write for the Perl Journal, and do tech edits on books. Sometimes I write code, too.

Journal of petdance (2468)

Friday August 10, 2007
10:00 AM

Perl security done right

[ #34073 ]
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.

List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Perl security done right 8 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
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.
      --

      --
      xoa

    • 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

          • 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

        • 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. :-)
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.