Re: Secure Perl Coding Standards

in reply to Secure Perl Coding Standards

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!

Comment on Re: Secure Perl Coding Standards

Replies are listed 'Best First'.
Re^2: Secure Perl Coding Standards by mr_mischief (Monsignor) on Apr 07, 2009 at 20:39 UTC
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. Is it Secure? is a good general discussion from 2002 on formulating and following good security guidelines and some references to particular ones. Paranoid about web application security is a discussion of how to know if an application (a web app in this case) is secure. Security techniques every programmer should know is Juerd's attempt at starting a secure coding tips guide, going so far as to directly ask for further advice from other monks in the replies. tinita asks Is your web application really secure? ("CSRF") How can I secure MySQL & CGI? asks about securing a CGI application's database login info Cookie based authentication: Is it secure? is a discussion about the security issues of cookies as a web authentication mechanism Guide to Building Secure Web Applications and Web Services leads to wonderful resources like the top ten classes of web vulnerabilities as of 2007 and a list of guideline documents for all sorts of security issues from the SANS Institute. Essential CGI Security Practices is cjf's handiwork. In Stay aware of security tilly starts a good discussion about security and vigilance. pjf and jarich have courseware about programming securely in Perl at http://perltraining.com.au/courses/perlsec.html which I found through Perl Training Australia's Security notes released. I'd contact one of those monks for licensing questions, as it says available for personal use. In Ideas Wanted for Perl::Critic Security Policies jthalhammer starts a discussion about what Perl::Critic could do to automatically assess some security issues. Security Standards is grep's announcement to PM that an accomplished IBM security auditor has released some secure programming and testing guidelines, complete with links to them. Ovid brings us a (OT) Security Rant, although I'm not sure how "OT" it is. tilly advises us to always Stay aware of security. merlyn bemoans security issues and several people reply with good references about security in web site design, or lack thereof where he (merlyn) reminds us that secure and non-functional is better than insecure and functional. talexb organizes some testing of placeholders for preventing SQL injections at Preventing SQL injection attacks: Placeholders are enough for MySQL, Postgresql and SQLite. Speaking of SQL injection, I mention SQL placeholders as a preventative for code injection in a flawed RDMS in Yet another reason to use DBI placeholders. At UTF8 related proof of concept exploit released at T-DOSE Juerd informed the monks of a class of bug in some Perl code that uses Unicode support slightly wrong in a way that will sometimes work but also allow an exploit under certain versions of perl. The tutorial Using Temporary Files in Perl mentions some of the security implications surrounding temporary files which are common to any language. Preventing XSS talks about cross-site scripting, which is another language agnostic security issue. Finally, one of the most comprehensive nodes and associated followup threads on coding standards ever to grace PM is On Coding Standards and Code Reviews by eyepopslikeamosquito which covers all sorts of guidelines for writing code including some security issues. It also gives a nice bibliography of other guideline and policy documents from other organizations regarding coding for security, robustness, and maintainability. In My coding guidelines Abigail-II isn't as verbose as eyepopslikeamosquito, but the guidelines are a good study in maintainability even if one may disagree with certain individual points. 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/;	[reply]
Re^2: Secure Perl Coding Standards by Herkum (Parson) on Apr 07, 2009 at 17:42 UTC
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.	[reply]
Re^3: Secure Perl Coding Standards by Your Mother (Archbishop) on Apr 07, 2009 at 17:48 UTC
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.	[reply]
Re^2: Secure Perl Coding Standards by MidLifeXis (Monsignor) on Apr 07, 2009 at 17:36 UTC
<simpsons> `foreach my $infraction (@infractions) { warn "$infraction, that's a paddlin'.\n"; }` [download] </simpsons> --MidLifeXis The tomes, scrolls etc are dusty because they reside in a dusty old house, not because they're unused. --hangon in this post	[reply] [d/l]

In Section Meditations