http://qs321.pair.com?node_id=756144


in reply to Re: Secure Perl Coding Standards
in thread Secure Perl Coding Standards

You make some very good points. The finer details of secure coding practice mean nothing if they are not followed. The most secure application code in the world can be a security nightmare when the application is configured incorrectly.

Treating all data that comes from outside the program as suspect or even downright hostile is one of the most important rules for security if not the most important. It's one that often gets forgotten when programming or configuring an application, though.

Any coding guidelines that help with robustness or maintainability help with security, too. If something's not robust and crashes when it's not a target of an attack, someone can crash it on purpose as well. They may even be able to crash it in a predictable enough way to exploit it. If code's not maintainable, then fixing security issues once they are found will take longer. Being security conscious is a good coding practice, but good coding practices in general help with security, too.

I realized since my post above that since PerlMonks is a great source for discussion of all things Perl, I probably should have included some node references. I did a little searching around the Monastery for other security discussions, and some of the topics you mentioned came up. As usual, the threads are generally more valuable taken together than any single node from a thread by itself.

In the vein of good general practices being good for security, Perl Best Practices and Perl::Critic are definitely worth a look.

As you say, though, the simple security issues that often aren't paid any attention should be addressed first. Get the low-hanging fruit that is most likely to allow the easiest route to exploitation, then move up the tree.

Update 2009-04-8: Thanks to ambrus for spotting a grammatical error. s/(secure and non-functional) (than insecure and functional)/$1 is better $2/;