So I've been looking to make an online calendar that uses mySQL to store/update data. I've looked around quite a bit online and all the free "canned" scripts (like from CGI-resources.com, one from Matt Kruse (surprise!)) are really insecure. It's like the programmers completely don't care about tainting and security. I think I'm starting to see a pattern.

My idea was to take a script and modify it to use mySQL, but they are all so far gone with security that I might as well write one altogether.

I'm relatively new to perl, and wondering if this is true of all canned scripts? I don't really want to reinvent the wheel, but then I'm not going to put important data at risk either. I think I'm basically stuck writing my own, maybe grabbing useful subroutines out of some of the free scripts.

Are there any "more secure" perl script collections out there? Maybe something moderated by a perl hacker who knows what to look for?

Is this an idea that could be implemented in the Monastery? Obviously, there would be many caveats attached, like "these scripts are deemed MORE secure, but not perfect." I think this would be an excellent learning tool, at least for me, to see better ways to implement secure scripts.

Just a few thoughts. . .

  • Comment on A rumination on finding secure scripts, versus rolling-your-own

Replies are listed 'Best First'.
(jcwren) Re: A rumination on finding secure scripts, versus rolling-your-own
by jcwren (Prior) on Mar 29, 2001 at 22:54 UTC

    In my personal opinion, the heart of the problem is this: People want to learn CGI (or DBI) programming, so they select a task (calendar, remote POP3 mail reader, CD collection, whatever) that they need done, that (presumabily) isn't out of the skill range of a beginner, and go to it.

    They learn enough to make it work, they've "learned" CGI/DBI, it meets their needs, so it's done. Many don't *realize* that there is a security issue. I honestly don't believe that it's a matter of "Oh, I'll just ignore it" in the majority of the cases. It's a simple lack of education. OK, so they've written this script, and like most people who've written software, they're a little proud of it. They set out with a goal in mind, they've achieved it, and they know there are other people out there have similiar needs. So it's made public, propogates through the web, newsgroups, MSA, whatever.

    The people *truly* in the know have either moved on and written their own improved ones, or they don't have time/bandwidth to try to educate this person. Now, a lot of times, the people who've written the much better software know that it could be improved, so they're not ready to let everyone see it, and it just gets run on their private machines. In a few cases, maybe it goes opensource/shareware/commercial. In an exceedingly small number of cases, it actually gets used as an example in a book, on a website, or somewhere public. But because the signal-to-noise ratio is so bad, it gets overlooked by all but a very few.

    It seems to be that almost *all* education on the net is the "You'll figure this out yourself, because no one is going to hold your hand.". Sure, there are tutorials, but you have to find them, and you have to know the quality (nothing like a cargo cult educational system, eh?). There is no instructor-teacher relationships (well, you can pay money for that), nor the old apprectice education system type. The people with the knowledge have bills to pay to, so they're working to do what they need to do, and don't have much time to educate the masses in their spare time.

    Even here, with the *excellent* quality of people we have, the skill sets, and the drive, we don't have a tutorials section for CGI (or even a checklist) that shows you how to do a step-by-step security audit. I'd love something like that personally. But I can tell you this: I don't have the background to write one. I know taint, I know a few things about DBI, but I would feel very unfortable trying to say to someone "If you do all this, your script will be secure.". Because I *don't know* all the potential security holes. I pick up a few things here and there, and if I'm lucky, I even remember them.

    So what's the solution? There probably isn't one. There are too many people writing scripts that aren't secure, because they don't know better. Because they use MSA as a reference. Because there is no comprehensive security reference that allows you to do a step-by-step check. Perhaps there are some nifty utilities that allow common "attacks" to be run against a URL. That would be kind cool for someone to write, if such a utility doesn't exist.

    What *can* you do? When you see an insecure script, take the time to mail the author. Don't be condescending, but make them aware of the risk the script is at. If people ask you how to write a CGI script, tell them about security first. Tell them where *not* to go, which can be as power a tool as tell them where they should go.

    I was trying to think of a good real-world analogy you could use with people that would have lots of good examples, but I really can't think of one at the moment.

    --Chris

    e-mail jcwren

      I think you make really good points here, not the least because most of what you say has been running through my mind too

      There is one thing I can contribute, there *are* tools out there that allow common attacks to be run against URLs, Nessus, Saint being two that I've used..

      Is it comprehensive ? no.. does it make your script safer ? no, not really.. it just checks for common attacks, it can't be an exhaustive check, for obvious reasons..

      Other than that, paranoia is always a virtue when writing a CGI app ;o). I've found that one out the hard way..

      finally, a question: I still don't understand why/if taint mode is necessary when a parameter value is used internally.. for example, if you're not using input into system(), exec() or similar nasties, what is the worst that could happen ?

      always on the lookout for ways to make my scripts more secure... :o)
      tinman

        As perlsec points out, internal data can be tainted without danger. However before it gets near the shell, it is important that it be validated. The entire point of taint mode is to guarantee that you don't forget to do that - ever.
Re: A rumination on finding secure scripts, versus rolling-your-own
by merlyn (Sage) on Mar 29, 2001 at 22:18 UTC
    Many people find that my columns are a valuable resource for reusable code and ideas. And I'd hope that I've not done something stupid around security. {grin}

    -- Randal L. Schwartz, Perl hacker

Re: A rumination on finding secure scripts, versus rolling-your-own
by Desdinova (Friar) on Mar 30, 2001 at 10:25 UTC
    A thought i would like to add is that if you do write your own and it is more secure then post it somewhere. I think the best thing that those of us who know how to write secure scripts can do is to lead by example

    I don't think this would require a new section as we already have the Code Catacombs Section. Most of the scripts i have seen there are rather well written and when something slips through the cracks the commenters are quick to point out the error

    Finnally you bring a really good piint that too any people learn the hard way. Never assume that code is secure unless soemone with a good amount of knowledge says so. this includes code you write.
Re: A rumination on finding secure scripts, versus rolling-your-own
by cLive ;-) (Prior) on Mar 30, 2001 at 13:04 UTC
    I've spent the last two years building cgi scripts and have made many security mistakes along the way :)

    I remember there being a CGI security FAQ, I think by Selena Sol, but can't remember.

    How about working out criteria for rating a script's security level, and then create a 'Perl Monks security Meditation' for the overall security.

    Things to look at would be whether they are safe from:

    • manipulation of Query String and POST data (Level 1: 'may you live in interesting times')
    • HTTP header spoofing - ie fake HTTP_REFERER, cookies etc (Level 2: 'may you come to the attention of those in power')
    • data read/write access by other users on server (Level 3: 'sleep soundly, for you have peace in your heart')
    • IP spoofing (Level 4: 'secure zen master')
    Eg, if a script parses input data well, but relies on a valid HTTP_REFERER as a check, it would get a 'level one' rating. The infamous formmail can be used to relay e-mail if you fake/omit the HTTP_REFERER, but parses input data OK, so it would get a 'level one' rating.

    I'm sure there are other criteria, but that's my .02

    cLive ;-)

      I'm sure the CGI Security FAQ can't be by Selena Sol. As I recall, his scripts were amongst the worst.

      --
      <http://www.dave.org.uk>

      "Perl makes the fun jobs fun
      and the boring jobs bearable" - me

        Fair enough but, on looking, the FAQ was written by Lincoln Stein and is here but, in his defence, Lincoln does recommend this in the FAQ :)

        In his words... "More recently, Selena Sol has published an excellent article on the risks of installing pre-built CGI scripts, with much helpful advice on configuring and customizing these scripts to increase their security. "

        I agree.

        Because a couple good hearted but under-developed Perl programmers have made some rather insecure scripts available to the world we now have zillions of formmail.pl programs around the net.

        If PM does do anything about illustrating transmogrification of standard insecure scripts into better scripts (from the security point of view anyway) formmail.pl or other such ubiquitious scripts with known exploits could be good candidates as patients.

        This way it might be possible to see some of the secure scripts filter out into the world replacing the swiss-cheese versions.

        I admire the good heartedness of the guys that released these commonly used scripts. But I wouldn't want my website on a server hosting any of these.

        Claude