Performing a commercial audit may strike some monks a little oddly, however. Would you and your client be willing to donate an hour's worth of your fees to the monastery for this purpose?

I don't have a problem with it either way, but it might make other people sleep a little more soundly at night. (Think of it as really cheap training for you and insurance for them.)

If your code passes muster here, I would be tempted to rule it secure from a CGI point of view. Obviously there's more to it than that, but simply ensuring your script runs well and without problems with taint-checking and warnings turned on, I feel a lot better about it.

If it doesn't, then you likely have problems.

Thanks for that nice tip, I'll give it a try.

carrolte

A fast answer to that:
If your client may object to the open sourcing of your CGI, request that one/more of the monks operate as a closed forum for ratifying the code. Perhaps you'd find some willing to do this..
Personally, I can't think of a better group of people to go over some Perl than the guys here, and even if it does take a donation to the monastery, at least you know you're getting good quality advice for the cash.

Malk.

If your client doesn't wish to release the source, you could always set up the system somewhere, and let us know where it is. This way we can bang on it and see if we can break it. Most of us have likely done similar systems and know possible pitfalls. If noone would see the source anyways, then we would be doing just the same as a black hat would. Maybe if someone finds a hole, you could donate X hours of pay to PerlMonks.

Cheers,
KM

Actually, I'd beg to differ.
A lot of talk goes the "Security by obscurity" route. I.e. Don't release source, don't let anyone know what you're doing.
Part of the job I do involves system security, and if there's one thing that's apparent, security through obscurity doesn't work.
If you close your source, and don't let anyone know what's inside it, then you will almost definately miss something (if the app is sufficiently sizable).
And there will be someone out there able to crack it.
However, a good code review by a grouip of experienced and good coders will bring a good many of these to light. And in the end, they have almost as much to lose as you do.
By giving advice, they're actually laying part of their reputation on the line, and reputation is pretty important to the open source community in general (well, far as I know so far.. :) )..
Anyhow, the anonymous troll like monk that posted before this kinda killed his own argument.
"Take nobody's advice but your own" is advice, which he's suggesting you don't take, so, should be ignored.
Advice is a good thing, as long as you remember it's just that. Advice. What you do with it is up to you..
My personal thoughts on things are "Get the bugs found before programs hit production level where someone else will..". Code reviews are the best way I know to do that..

Just my tuppence worth,

Malk

I agree with you pretty much on this, but consider this: Why give away hints? If you use the file extentsion .cgi, a would-be cracker (not a hacker) has no idea if you're using Perl, C, Ruby, COBOL, or whatever to do your CGI. You use .pl, and you've given away a pretty good hint you're running Perl.

Now, your code review has passed, everything is fine, and 3 months later someone discovers a latent problem in CGI.pm or Perl itself. Is someone more likely to try that new exploit against a site they see with .cgi scripts, or .pl scripts?

Security through obscurity is a bad policy to rely on to hide bad programming, but it's a good policy to help make it more difficult for someone to work against you.

After all, if you have a safe in your home, do you put up a sign saying 'safe is in basement'?

--Chris

e-mail jcwren