Executing Scripts

I would like to allow users to execute scripts on my server.  I want to make it as safe as possible (yes i know i shouldn't allow it but..) .  The only possibility I can think of is regex'ing the file for certain functions  but this seems kind of hit or miss.  Is there anyway to stop any actions it would do on the system?  Besides opening and closing 2 certain files?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Can you ellaborate on exactly what you want to do snow, it is not very clear as to what you want to do.

php scripts can be executed if someone points to them via their browser I assume this is what you mean.
Snow-StormAuthor Commented:
I want to run a  user uploaded script and make sure it doesn't try to attack my server.
maybe you can try to use include or require functions
include ("test.php");
require ("test.php");
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

more of it,
if you dont want the php file to be seen by others, try use random number for file name. the file then store in data table,
each time call to that record, file name retrieve from database table. know what i means??
by using include and require, user will not see your file name.
<table border="1" height="100" width="100"><tr><td>
   $handle = fopen('test.php', 'a'); // try random the file name
   fwrite($handle, $myscript);
   require ('test.php');
<form method="post">
<textarea name="myscript"></textarea>
<input type="submit">

try this script
em.. i still not fell that is save for client to execute the php script
The answer should actually be,

Do not allow your clients/customer to upload scripts unless you know them personally, and even if you do know then you want to create an administration area whereby they have to login with a username and password in order to upload files.  

The other thing someone could create a script to delete your database if your not careful and I would personally lock everything down with passwords so that it makes them impossible to do this unless they spend about 100 years trying to break passwords.


#Put all the variables, includes and all other info required to to make sure you clien tis logged in.  

#Create a path where you want the files to be put to
$uploadpath = /home/user/phpscripts

  if(empty($_POST['usernamee']) || empty($_POST['script'])) {

echo "Please enter a user name and select a script to upload";

<form action="<? $PHP_SELF ?>" method="post" enctype="multipart/form-data" name="form1">
            <td>Ride <font face="Arial, Helvetica, sans-serif">name:</font></td>
            <td><input type="text" name="username"></td>
          <tr><td>Script:</td><td><input type="file" name="script"></td></tr>
            <td><input type="submit" name="Submit" value="Submit"></td>


//Upload the file to the uploadpath
if (!move_uploaded_file($_FILES['script']['tmp_name'], $uploadpath.basename($_FILES['script']['name']))) die("Could not Move uploaded file");
echo "Thank you your file has been upload, the administration of the site will have to create execution permissions on the file by doing "chmod 777 scriptname.php" from inside the directory of where it lies";



Notice the comment about chmod 777 scriptname.php   You can do these files one by one manually of simply specify the whole folder instead chmod 777 foldername

Read this on permissions of files under unix http://www.phpdebutant.com/articles/CHMOD-777.php

Anyway hope this helps you

Marcus BointonCommented:
Don't do that - there's no reason to assign execute permissions to a PHP file - you don't need it for apache to execute the script, and it opens up a big fat security hole if you do. After all, file extensions mean nothing on unix, so the file may contain something nasty like:

#! /bin/sh
rm -rf /var/www/html

And assigning execute permissions may allow the script to be run as a CGI. Nice. You may have other server settings that mitigate this hole, but it's not a good place to start.

Using 777 permissions on a folder is an entirely different matter, one which that article fails to cover. You should not need to use chmod at all to deal with this setup.

No-one's mentioned PHP's safe mode, which is the normal way to deal with this situation:


However, this is still only a limited range of security.
Snow-StormAuthor Commented:
I do have safe mode turned on, and I am considering reg-ex'ing the file for certain functions (like rm).  I heard somewhere there was a way to check every access/request/function sent to the server by the script to make sure isn't trying to attack anything.   I've got my upload page set up, and was planning on executing scripts via a exec(php -q /script/) command, is this not a good idea?
I'm not gonna argue with Squinky :)
Marcus BointonCommented:
Making a list of list of every possible function that could form part of an attack is next to impossible - how can you distinguish between a deliberate local DoS attack and a script that just happens to be legitimately CPU or network heavy? Pllus it's very easy to hide what commands are really doing, for example:

$imagedata = 'dW5saW5rKCJzb21ldml0YWxmaWxlLmh0bWwiKTs=';
header('Content-type: image/gif');
print eval(base64_decode($imagedata));

Which at first glance looks like it might be delivering an image, when in fact it's deleting files. Admittedly, eval would be pretty high on your list of banned functions, along with system, exec and friends. Safe mode has a list of allowed or banned functions that you can set.

A good tactic is to not allow users to see/write to anything outside their own directories (chroot them). That helps defend your local files quite a bit, however, it doesn't help you at all against local DoS (it's easy to saturate a local database server), attacks on remote sites, filling up /tmp, or introducing XSS attacks via the user's own scripts (their own scripts could get hacked too). But if you lock everything down too much, it starts to become useless. I guess it might be useful if there was a PHP extension that allowed you to throttle CPU usage per user.

It's not easy to do - I even did it to myself recently, managing to inadvertently write a script that submitted about 50,000 queries to MySQL and fill up /tmp at the same time!

Essentially, every ISP takes a risk when allowing scripting. I don't think you can really defend too well against someone determined to make your life difficult, though as an ISP, you can always kick them out.
Snow-StormAuthor Commented:
Hmm, couldn't I allow only a certain execution time, like 30 seconds? And void any changes their script tries to make?  How could I limit the amount of time and memory the script can use?

if i am right, the index.php on subfolder will not have access right to the main folder.
i think it will be safe right?
if is right, try save the script to file in subfolder, and then create a link to the file
<a href="www.domain.com/subfolder/user/index.php">RUN</a>
Marcus BointonCommented:
You can set timeouts in php.ini, and you can probably set mysql timeouts too. Voiding changes that a script does is pretty impossible - the overhead of tracking what it does would probably be worse than taking any damage!

SpidermanZ, there's no particular reason that you wouldn't be able to access stuff in a folder above the user's one unless it had been deliberately blocked e.g. this:


is the same place as www.domain.com/index.php.

This is what chroot (change root directory) is for - it would mean that although the users files are kept deep down in www.domain.com/subfolder/user/, they could be chrooted there, naming that it looks like their files are being served from /, which also denies them access to any higher directory levels.
Snow-StormAuthor Commented:
Alright I guess I'll try to chroot it, but if their script has ini_set they can override a timeout value I set can't they?
Marcus BointonCommented:
From the php docs http://www.php.net/manual/en/ref.info.php#ini.max-execution-time:

max_execution_time integer

This sets the maximum time in seconds a script is allowed to  run before it is terminated by the parser. This helps  prevent poorly written scripts from tying up the server. The  default setting is 30.

The maximum execution time is not affected by system calls,  stream operations etc. Please see the  set_time_limit() function for more  details.

You can not change this setting with ini_set() when  running in safe mode. The only workaround is to turn off safe mode or  by changing the time limit in the php.ini.

Your webserver can have other timeouts. E.g. Apache has  Timeout directive, IIS has CGI timeout function, both  default to 300 seconds. See the webserver documentation for meaning of it.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.