Ideas Wanted for Perl::Critic Security Policies

I've been thinking about creating some security-related policies for Perl::Critic. But other than taint checking, I'm not really familiar with Perl's security holes and features. What are some "best practices" for ensuring that Perl programs are safe from hackers?

-Jeff

Comment on Ideas Wanted for Perl::Critic Security Policies

Replies are listed 'Best First'.
Re: Ideas Wanted for Perl::Critic Security Policies by radiantmatrix (Parson) on Jun 30, 2006 at 19:03 UTC
Using the 3-parameter form of open would be a good practice to check for. It would be good to warn about system or exec calls that pass arguments inside the first parameter (i.e. `system("$command $arg1 $arg2")` instead of `system($command, $arg1, $arg2)`). If practical, warning about DBI statements that use inline variables where prototypes are better (i.e. `$dbh->prepare("update table set my_val = $somevalue")` instead of `$dbh->prepare("update table set my_val = ?")`). I'm guessing that would be a challenge, but it sure would be nifty. Yes, proper untainting would probably solve these issues, but I've seen too many coders untaint such things extremely poorly. <–radiant.matrix–> A collection of thoughts and links from the minds of geeks The Code that can be seen is not the true Code I haven't found a problem yet that can't be solved by a well-placed trebuchet	[reply] [d/l] [select]
Re^2: Ideas Wanted for Perl::Critic Security Policies by davidrw (Prior) on Jul 01, 2006 at 00:40 UTC
Using the 3-parameter form of open would be a good practice to check for. There's a InputOutput::ProhibitTwoArgOpen in the Perl::Critic distro already.. The DBI one would be a 'challenge' :) .. not sure how it'd be possible to distinguish between `$dbh->prepare("update table set my_val = $somevalue")` (NOT OK) and `$dbh->prepare("update $TABLENAME set my_val = ?")` (OK) without actually parsing the sql .. plus there's the circumvention of `$sql = "update table set my_val = $somevalue"; $sth=$dbh->prepare($sql);` as well (or can you back-trace that w/PPI?).. I took a crack at the system/exec one (see RFC: Perl-Critic policy: ProhibitInlineSystemArgs), though i think there's problems catching all of those, too.. e.g. `system( join(" ", $cmd, @args) )`	[reply] [d/l] [select]
Re: Ideas Wanted for Perl::Critic Security Policies by eyepopslikeamosquito (Archbishop) on Jun 30, 2006 at 21:28 UTC
You should be able to glean many security tips and tricks from: pjf's excellent perl security course notes, Perl Training Australia's Security notes released Juerd's Security techniques every programmer should know	[reply]
Re: Ideas Wanted for Perl::Critic Security Policies by Joost (Canon) on Jun 30, 2006 at 23:37 UTC
OWASP has a very interesting guide about web security which IMO should be required reading for anyone doing serious web development. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re: Ideas Wanted for Perl::Critic Security Policies by petdance (Parson) on Jul 03, 2006 at 06:45 UTC
Taint mode, baby. xoxo, Andy	[reply]

Back to Meditations