Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Secure Perl Coding Standards

by Binford (Sexton)
on Apr 07, 2009 at 15:47 UTC ( [id://756058] : perlmeditation . print w/replies, xml ) Need Help??

Hello Monks, I am in the process of working on a HUGE Application Security initiative where I work. Big part of this is secure coding standards for all languages we use in house. CERT provides an excellent standard for C, Java, C++ but nothing on shell languages. CERT Secure Coding Standards.

Fortify provided a taxonomy on PHP and some other languages, and I have translated those that are applicable to Perl and Ruby into our standards wiki but was wondering if you Wise monks knew of other places with Perl specifics? (And Ruby, bash, etc but Perl would be a great find). Obviously, I have already written up use of taint mode, strict mode, etc. but additional knowledge if, for example, some CPAN modules for input validation etc type information would be very useful.

Thanks in advance!

Replies are listed 'Best First'.
Re: Secure Perl Coding Standards
by mr_mischief (Monsignor) on Apr 07, 2009 at 16:52 UTC
    One place to look is in the standard Perl documentation. See perlsec especially, which is all Perl security info. Also look at perltaint. There is security info in the open, system, and exec portions of perlfunc and more in perlopentut. Some of the info in perltrap is security related.

    Entire books have been written on the idea of secured programming which might help you formulate your standard. Secure Coding: Principles and Practices is one such book on the topic of writing secure code. Writing Secure Code, Second Edition is another, and some sample material from that is available at this MS Press page for the book (which even includes some Perl info in the examples). Security Forest has books on secure coding rated, including the two above.

    brian d foy has online a sample from his book Mastering Perl that deals with security. I'd recommend buying the book if you find it helpful. Other Perl books make some reference to security, too.

    There's a tutorial about security of Perl applications at

    Secure web programming is mentioned at You might not be doing web programming, but don't forget your application domain has its own security issues no matter the language. Make sure you have standards in place for the application domains, too.

    Read up on vulnerabilities and consider how to avoid them. Knowing what you're securing against is one of the best ways to formulate how you're going to secure something.

    Above all, remember that untested security is likely very little security at all. Most security errors slip through from a lack of black-box testing of the code at its boundaries. Write tests to check boundary conditions and even completely invalid inputs that are unlikely to occur. Any interface to the user is an interface to a fuzzing tool.

Re: Secure Perl Coding Standards
by Your Mother (Archbishop) on Apr 07, 2009 at 17:21 UTC

    mr_mischief's excellent advice aside a for a moment, I provide a bit of cold water. Fire anyone who sends user provided data directly anywhere. No taint or input validation? Fired! No placeholders for DB interaction? Fired! Also fire anyone who surfaces user data in world readable ways. Username in the cookie? Fired! Accepting GET for login forms? Fired! Cached user settings page? Fired! Let's not stop there. Someone setup a DB without a root password? Fired! Someone used the same password on all the secure entry points and it's 3 years old? Fired!

    We spend a lot of time talking about difficult, non-trivial security exploits. The last two or three places I worked had holes you could drive a truck through. One place sent cookie content directly to SQL which meant a maliciously crafted cookie could delete the entire production DB.

    I'm being facetious about firing everyone but I argue that the way to address this sort of problem is not more process, it's more serious consequences for not knowing how to do your job. It's a professional and cultural issue, not one caused by a lack of information. It sounds like you might be getting a handle on the cultural aspect. Good luck and keep it up!

      it's more serious consequences for not knowing how to do your job

      That is the heart of the problem, the people who tend to be in charge are the least able to evaluate other peoples skills. I have had one manager who knew how to program. He was up to a** in alligators trying to get his bosses to line up a more stable development environment. So he ended up not being able to do that much.

      All the rest of the managers, they did not want to get involved with anything involving processes, they mostly wanted to mediate between departments and individuals. They did not themselves people who involved themselves directly with work and therefore had not ability to evaluate whom was doing what. Why do think so many companies suck at development? They put non-technical people in charge of the technical side of the business and it sucks.

      Until you get managers who view themselves as part of the work process it is very hard to implement a standard on how work should be done.

        I totally agree. I tried to work a little about that in but I didn't have a good example. Some of the most awful security holes I've seen were known but persisted because of an unwillingness to pay the development costs required to fix them.


      foreach my $infraction (@infractions) { warn "$infraction, that's a paddlin'.\n"; }



      The tomes, scrolls etc are dusty because they reside in a dusty old house, not because they're unused. --hangon in this post