Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

(OT) Security Rant

by Ovid (Cardinal)
on Dec 05, 2001 at 02:56 UTC ( #129470=perlmeditation: print w/ replies, xml ) Need Help??

The Problem

Without pointing out specific threads, I have noticed that some of the threads on this site offer questionable security advice. In fact, one recent node specifically alluded to the fact that it was offering insecure advice in order to implement an easy to use solution. This is bad. Deliberately introducing any weakness in security compromises the security of the entire system even if you know that it doesn't.

You Don't Know All of the Problems

Security can be terribly complicated and just because you've added all of the latest patches, kept up-to-date on your virus updates and have a rock solid firewall doesn't mean that some clever hacker won't find a new loophole tomorrow. Even if there are no loopholes in the system architecture, social engineering is still a common exploit. ("Hello, this is Joe at the help desk. I need your password to test foo."). In fact, the larger your system or organization, the more significant these concerns become.

Case in point: on a recent software project, I had users logging in over a secure connection and a session ID is returned to them and sent back via a cookie. Since I set it up so the cookie can only be returned via a secure connection, I really don't need session IDs, right? I can just have the user store their password in a cookie and return that. It's easier to implement.

Of course, that's the wrong attitude to take. A few months after this system was up and running, we needed to port it to a new server. Someone forgot to install a new SSL certificate and I was (ugh) ordered to change the program to return the cookies regardless of whether or not the connection was secure. If I hadn't used session IDs, the cookie would always be sending the password. Since I did use session IDs, this password is not sent. Of course, the initial login still had the password sent over an unencrypted connection, but at least if someone starts sniffing the connection after the initial logon, they won't see a password.

So, we use session IDs. These don't remain static for a session! I issue a new ID every connection to lower the likelyhood of someone hijacking the session by submitting an old ID. This still isn't perfect, but defense in depth is the key here. Naturally, this all broke down by losing the SSL certificate, but it's better than nothing.

Multiple Paths for Failure

Another example is a story a friend (lemming) related to me about being asked to do QA on a product that had 17 binary switches. He was asked to test all possible combinations. That doesn't seem to hard until you realize that there are 217 (131072) states. Assuming he could test one state a minute, it would take three months to test every state! And that's assuming that all tests pass (or if they fail, that we ignore this during the testing). With 131072 paths of potential failure, we can easily see how security could get complicated. Of course, if you have a product with only 17 binary states, that's probably not a big product.

Now, if you add into this equation the problem of bringing on maintenance programmers not familiar with your security features, possible security concerns in your firewall, servers, databases, etc, you quickly begin to get an idea of the scope of the problem. You can't prove a system secure.

Security by Obscurity

Generally, people view security by obscurity (SbO) as a bad idea. Not necessarily. SbO is great if it's an additional security measure. Do you really want to hand people the names of the tables in your database? Do you want to hand them the field names of those tables? If you have perfect security, it shouldn't matter. Unfortunately, since you can't prove your system secure, it does matter. I have shown more than one person how I can destroy their database with a well-crafted URL. Of course, that means that I need to have a reasonable guess as to their table names (amongst other things).

One of the more interesting problems with security by obscurity relates to usernames. I can scan through many corporate Web sites and pick up user names just by reading the email addresses. If I see a standard on how those are being implemented, I now can extrapolate more user names. Since many people have the same user name on their email as they do for other systems, this can be useful. Often, getting a list of user names can be half the battle of cracking a system. Your email shouldn't be giving away that information, either.

Why Would Anyone Crack Me?

Because they can.

Maybe you don't think that this matters, but what if they crack your box and use this to launch attacks on other boxes? Sooner or later, some large corporation suffering from a distributed denial of service attack is going to consider suing admins of poorly protected boxes for damages. If that suit isn't tossed out of court, can you afford to lose that suit? Heck, can you afford to win that suit? That could easily be a Pyrrhic victory.

What if they crack your box and get your passwords from it? No matter, you and all of your users would never think about reusing your passwords, would you? Of course you do. Now, the cracker has a list of user names and passwords. Enough digging around and the cracker is going to find some use for them.


Sometimes we offer bad security advice. Sometimes we make poor security choices. If you see this, take steps to remedy it. How often do those "Crack My Box" contests walk away with no winners? Not very often. But let's face it, those are boxes where every effort has been made to ensure their safety. If you don't make every effort, you're vulnerable. If you're not a security expert (and I'm not), don't take short-cuts. If you are a security expert, then you're already not taking short cuts.


Update:: footpad turned me on to Stay aware of security, by tilly, which I think is another good thing to read.

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on (OT) Security Rant
(ichimunki) Re: Security Rant
by ichimunki (Priest) on Dec 05, 2001 at 03:45 UTC
    I have a bone to pick here. This "rant" is not Off-Topic (OT) as stated in the title. It is a mantra more important than use strict!

    Perl is probably (and I'm completely guessing here, but I like to think it's an educated guess) the 2nd most likely programming language to be involved in a potential security incident (C being the first, since so many services are written in that-- and I'm trying not to think about Outlook right now). Not because the language Perl itself is weak or rife with holes, but because it is commonly used in situations where there is world-wide exposure for the resulting executable-- CGI scripts on the web. And web programming is deceptively simple seeming. Add a print "content-type: html/text\n\n" to your script and suddenly it's a CGI script.

    But the paradigm shift from writing scripts for a trusted client in a secure environment (that is, the user probably doesn't want to trash their own box, so while we might verify their input makes sense we probably won't check it for interesting hacks related to piping dangerous commands to the shell) to writing scripts for a hostile environment is almost never covered well in "Quick Easy Perl Web Mastery" books, because that wouldn't be, well, quick or easy to master.

    As long as you have the energy, please never feel it's off-topic or inappropriate to bring up security issues. :)

      i agree wholeheartedly (especially about it not being off-topic); we've all seen how perfectly capable Perl is as a programming language - and that itself has a few caveats, if a user doesn't know what they're doing when they make their favorite script suid root. While I know this is a very basic example, it still stands that some of us (IMHO all of us) could benefit from more talk of ways to keep Perl scripts and applications secure. As far as I've seen, Perl/Apache (be it mod_perl or vanilla CGI) is the most common CGI language/server combination on the web (well, according to apache - they've got a figure of around 56% floating on their website)

      and users would do well to remember what happens when Quick and Easy programs don't stay quick and easy. Sometimes, they'll actually be used by other people, and built upon... maybe even be the basis of more widely used applications. Eventually, with poor design, and a little rum involved, they sometimes grow to be a web-based SNAFU [tm] of incredible size.
      (where i work, when we integrate our software with other companies e-commerce solutions, it's frightening how often I see 'unpatched' / formmail.cgi in their cgi-bins!)

      in a nutshell, i feel pretty darn lucky to be able to code in something that keeps track of it's own memory, doesn't require me to do type definitions, and gives me simple, intelligent ways to handle text; Perl is great if you're lazy. but it won't keep you from falling on your face if you don't watch where you put your feet.
      in a smaller nutshell, use strict;, use warnings;, use the  -T switch, and watch your step. (:

Re: (OT) Security Rant
by IlyaM (Parson) on Dec 05, 2001 at 03:48 UTC
    Just to return it on topic :)

    Here a link on my favorite article about possible security holes in Perl CGI scripts which do not filter properly input data (particulary filenames).

    Ilya Martynov (

Re: (OT) Security Rant
by hakkr (Chaplain) on Dec 05, 2001 at 15:33 UTC
    Script kiddies certainly like Perl scripts. Spammers also love cgi based Email forms. Perl can be a powerful force for the dark side.
Re: (OT) Security Rant
by PixelRat (Sexton) on Dec 05, 2001 at 17:34 UTC
    The fun part of the Crack-my-box-and-win-lots-of-money contests is that often company X just released product Y and then decided to put a contest online. Since Y hasnīt been available before itīs pretty hard to know how the program works. The solution is just to sit back and wait for Y to be available for the public and work with it. This is when the real contest begins ...

      yes, that's when exploits Z,A,B,C, and D come out, along with CERT advisory E and denial of backdoors in their software (usually referred to as 'F-U'). it's my opinion that the concept is a good one - how better to find security holes in software than hold a contest, and reward the guy (or gal!) who manages to find one (or more)? so maybe if we rant about this flaw in enough places, enough times, something will be done... but i doubt it. ):

      i've said this before (in a joking manner), but seriously i think we really do need a semi-universally accepted FAQ or RFC on security in applications and their enviroment. maybe it wouldn't be the end-all Quick Fix that we'd like to have, but it'd give beginning software developers a common place to look for advice in these matters. as Ovid explained, you can't really be certain that something is completely be secure (well, i know i can't), but you most certainly can do your best and take every measure to ensure that it's as secure as you can possibly get it. this is comparable to locking your door, even though you know someone can break a window - or take a sledgehammer to a wall for that matter (:

      note: if anyone does have a faq or rfc etc like i mentioned above, please send it to the email address shown by this code (this'll get those spam collectors! (: ): perl -e 'print pack("H*", "73747266727940343133303334393732"), "\x0a";' - thanks!

elbie: Security Rant
by elbie (Deacon) on Dec 05, 2001 at 18:22 UTC
    Great article, but was there a reason that you chose not to make use of the <READMORE> tag?


Re: (OT) Security Rant
by dmmiller2k (Chaplain) on Dec 05, 2001 at 19:50 UTC
    ... In fact, one recent node specifically alluded to the fact that it was offering insecure advice in order to implement an easy to use solution. This is bad. ...

    Thanks, Ovid, for your grace in not specifically identifying my post (Run arbitrary UNIX commands on webserver without telnet), but as the erstwhile author, I cannot elude responsibility (or shall we say irresponsibility). Having, for the most part, lurked on PM for months prior to posting the node to which you allude, I was overjoyed to finally have something I felt worthy of contributing.

    In my own defense, it all started (innocently enough) when, in answer to a largely unrelated question, given the opportunity to respond with my own solution (Re: Re: Modules that get along with use lib) to the problem of not having shell access to an ISP web account, I allowed my ego to get the better of me and thought of posting it in Craft. Then (unfortunately), while typing it in there, I had the amazing brain flash of an impulse to try to "improve" upon the original idea and to add a text entry field.

    Boy! Should I have ever thought THAT one through! I even tried defending the practice (several times!) further down in the thread. What an idiot!

    Truth is, I've never actually used the form-based script on a site, instead using clones of the hard-coded command version I had used as my response.

    Lately, I've taken merlyn's advice to heart and switched to this (Re: Run arbitrary UNIX commands on webserver without telnet), eliminating even the Perl interpreter startup delay. I don't even leave them executable anymore when not in use; I chmod -x them before ending the FTP connection.

    To bring this ramble home, I wholeheartedly embrace your theme of promoting security awareness; if it's at all possible to do so, I recant.


    You can give a man a fish and feed him for a day ...
    Or, you can teach him to fish and feed him for a lifetime
Devil's (BSD) Advocate
by Rex(Wrecks) (Curate) on Dec 07, 2001 at 23:03 UTC
    First let me state that I do agree with most of this post and with most of the comments so far and that this is a great rule of thumb.

    However I would like to point a few things out as I write a ton of incredibly insecure code almost daily and get away with it:
  • Point #1 - Not all of us write code for production environments or even multi-user machines
  • Point #2 - Writing secure code takes a lot of extra time, and I'm not saying it's not well spent, just another point
  • Point #3 - In some cases security is not neccisary, at all!
  • Point #4 - Giving "Good" security advice is nearly impossible these days, as there is someone who will disagree with whatever protocol/algorithm/tool/solution you recomend.
  • Point #5 - Security in code usually requires overhead of some sort.

    Now I want to take the points I made and explain why I made them. I write code to test a suite of Network devices, ALL of this code is run on steril networks, and none of it needs to be secure, all I need to do is get the job done as fast as I can!

    Please don't get me wrong, I have made security (specifically network security) my life's work and I am dedicated to making the Net and all of it's tributaries more secure, but there is a time and place for everything, and sometimes the advice I need does not require security. Sometimes I just need the quick and dirty way to do it.

    I would however like to advocate Disclaimers for ANY code/advice you know to be even the slightest bit vulnerable! Just because You or I may not require the security in that situation doesn't mean that fair warning should not be posted.

    The other point I would like to make is that many of the folks asking for advice here need to know HOW to do it in the first place and will worry about the security after proof of concept stage. Many posters already have a security model in place and are dealing with many of the concerns brought up, and just need some logic help.

    I beleive some of the source of this post were the several posts about filenames and uploads using, and I agree that people should be VERY security aware when handing out advice for those situations, and should remember that they may be educating newbies to not only Perl, but also Programming in general, and installing good security practices at that stage of learning is critical.

    I will probably get chewed on for this POV, but I am willing to sacrifice those XP :)

    "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!
      Practicing Good Habits is always a good idea. Shortcuts are always bad. I understand what you are saying and it is entirely a matter of opinion, but I just don't think it is a good idea to condone or rationalize knowingly marking your code insecure.


      BTW It will give you a + for challenging the system. :)
        Valid point, and to clarify...I don't knowingly make my code insecure. I try to practice Good Habits. My point was that I don't spend the extra time and effort to truly bullet proof my code simply due to it's use. Most of my code would only take a few modifications to make bullet proof, the problem is that the modifications in question take a lot of time, both to develop and to test. And since security is almost always a time trade (IE: any encryption can be broken, but will the data be obsolete by the time it is broken?) I usually focus more on stability than security for my situation. Again, for me that is a good trade.

        I would also like to reiterate that I DO agree with the original post, and my reply was NOT meant to advocate sloppiness! It was meant as the "time and place for everything" side of this equation.

        And yes that means the original post got a ++ from me, because it was well thought out and presented, and more importantly...RIGHT!

        "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://129470]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2014-08-01 06:00 GMT
Find Nodes?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:

    Results (256 votes), past polls