Security checklist for CGI scripts

[jelevin]

Is there anyplace that I could find general advice for security of CGI scripts installed at FutureQuest?

[Terra]

Hmmm, I'm not quite sure how to respond to this one...

For starters, you will want to read about the suEXEC mechanism we use at:
http://www.apache.org/docs/suexec.html

Second, data directories can be set to 700 for maximum security so that only the user has access to it...  There is no longer a need for setting them to 777...

Third, make sure your executable scripts are uploaded in ASCII format, and that they are chmoded to 755 or they will not be allowed to execute...

This should get you started with CGI on the FQuest server...

--
Terra
--Unraveling the enigma--
FutureQuest

[Justin]

While some people seem to find the suEXEC mechanism to be limiting, I personally love it to death. It makes more sense than any other setup - it's your script, therefore it runs as you. It can do anything you can do - which is great for security.

Just to add a recomendation, a good idea would be to keep data files out of the www root. Now that domain lockdown is in effect server-wide, you can do this and safely know that nobody can access your data files.

Of course if they are kept in your cgi-bin, Apache will try to execute it as a script, so you can keep them in there as well - even with the strict permissions on the cgi-bin, thanks to suEXEC, your script can still write to files within the cgi-bin. To me it only makes sense that a script should run as the user who owns it.

Now this also makes it easier to shoot yourself in the foot... as your cgi scripts can delete anything that you can delete - which is why I only run trusted scripts or scripts that I have gone through and tested well - that's probably the best security.

I'm also in the habbit of using use strict; and adding a -Tw to the shebang line of all of my scripts from now on - it's not difficult. I've been declaring all of my variables in Basic, so I'm used to it - and it helps to catch errors very easily, especially when the error is a case issue with a variable name, etc...

------------------
Justin Nelson
FutureQuest Support

[jenili]

Check this one out for a good, brief introduction.
http://www.csclub.uwaterloo.ca/u/mlvanbie/cgisec/

And the W3C's security FAQ is still a good one.
http://www.w3.org/Security/faq/
Read especially sections 6 and 7, and you'll probably find sections 3 and 5 helpful as well.

Free advice from this corner: The two biggest problems you may run into are failing to anticipate and trap malicious input, and setting permissions that are too, uh, permissive.

Certain useful tools like sendmail are notorious for leaving gaping holes when given tainted input, and running perl in taint mode (-T) doesn't mean you're automatically covered -- I've seen programmers use taint mode "for added security" and then get around the taint complaints by extracting the whole string from itself, with any potential malicious input intact. Duh, why bother?

suExec, while a godsend to hostmasters, can actually be more problematic for CGI programmers. Why? Because your CGIs run as you, with your permissions, so anything you can overwrite in your space (read: your entire space) can be overwritten by an exploited CGI. On FQ, I will often chmod my files (not directories) to 444 (or 600 if they're CGI-generated data) and my apps to 500 when I've put them into production -- b/c then an errant CGI would have to allow the user to change file permissions as well as overwrite them (not that I plan to write exploitable CGIs, but I freely admit to rampant paranoia at times). A chmod 500 script will run on FQ, although it will generate a mod_mime_magic error in your log.

Oops, I've switched into "verbose mode"! Sorry. Those two FAQs ought to give you the background you're after, or at least a verrry good start on it.
------------------

jeni

[Terra]

A chmod 500 script will run on FQ, although it will generate a mod_mime_magic error in your log.

I could have sworn that I pulled the plug on that module in all of the Apache server, due to the problem that Jenili has stated...  Those errors are very annoying, and mod_mime_magic offers little benefit over a proper maintained server MIME file...

I will sweep all of the Apaches once again, and make sure no upgrade residue remains...

--
Terra
--To mime, or not to mime can never be a spoken question--
FutureQuest

[jenili]

Probably my bad, Terra; I haven't looked at my error log in quite a while. Either way, a real relief to hear that those errors are gone or soon to be!

--Mime! All mime!--
jeni