Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Secure Perl Coding Standards

by Your Mother (Canon)
on Apr 07, 2009 at 17:21 UTC ( #756086=note: print w/ replies, xml ) Need Help??


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
Re^2: Secure Perl Coding Standards
by MidLifeXis (Prior) on Apr 07, 2009 at 17:36 UTC

    <simpsons>

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

    </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

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.

      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.

Re^2: Secure Perl Coding Standards
by mr_mischief (Monsignor) on Apr 07, 2009 at 20:39 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://756086]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2014-08-30 11:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (293 votes), past polls