in reply to A rumination on finding secure scripts, versus rolling-your-own

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
  • Comment on (jcwren) Re: A rumination on finding secure scripts, versus rolling-your-own

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

    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.