[thelist] Safe mode and escapeshellcmd

John Hicks johnlist at gulfbridge.net
Tue Apr 18 12:58:03 CDT 2006

Santilal Parbhu wrote:
> Hi Guys
> I read in a book somewhere that it is a good idea to use the
> escapeshellcmd() to clean user entered data.  This is supposed to reduce the
> chances of a hacker entering control characters along with user data.  This
> sounds like a good idea.  

There are several php functions for escaping data. Your choice depends 
on what you want to do with that data. escapeshellcmd() is specifically 
for user-entered data that is going to be executed at the command level 
using exec() system() etc.

You didn't specifically say what you are doing with the data after 
escaping it. Are you then executing it? With which function?

 > I have used the following code fragment to clean
> data.
> <?php
> function clean($input, $maxlength)
> {
> 	$input = substr($input, 0, $maxlength);
> 	$input = EscapeShellCmd($input);
> 	return ($input);
> 	}
> ?>
> This worked fine when I was testing my scripts with Apache running on my
> laptop.  However, once I uploaded to an ISP hosted server, I ran into
> problems.  They operate in safe mode, which also sounds sensible.  

 > But
> escapeshellcmd is disabled in  safe mode, or at least my ISP has disabled
> it.  

Note that,  when safe mode is enabled, escapeshellcmd() is run 
automatically for exec(), system(), passthru(), and popen().


So perhaps your ISP has disabled escapeshellcmd() to prevent it from 
being run twice on the same data.

 > It seems strange to me that both of these mechanisms (ie. operating in
> safe mode and escapeshellcmd) are aimed at reducing the risk of attack, but
> they don't appear to be compatible with each other.  Any comments?  Should I
> just forget about using the clean function?

You should always clean user-entered data. And it's best to do it 
immediately when it is entered as part of a validation process. You can 
be stricter at that point since you know what you are expecting.

A blanket clean() function is a little dangerous because it tempts you 
to generalize about your data requirements.

Many user-entered fields, for example, can be restricted to 
alphanumerics. Most can be restricted to alphanumerics, apostrophe 
(single quote), space, and perhaps parentheses. It gets hairier when 
html code is being accepted, hairier and riskier still with php code, 
and hairiest with system commands (although there is little difference 
between allowing the user to enter php and system commands.)

Hope that helps.


> Thanks.
> Santilal

More information about the thelist mailing list