Jump to content

php file upload directory permissions


embsupafly

Recommended Posts

Hi,

We have PHP running as nobody on the server and have scripts that let users upload pictures to a directory. The directory is located inside the DOC ROOT, is owned by nobody and has permissions of 777 so the upload will work without complaining about permissions.

In the past (this has happened twice) we have lost all of the images in the directory, they seem to have "vanished". What I am wondering is, could someone have gotten in their and deleted them maliciously because of the permissions, or is there possibly a bug in the code somewhere?

Are there other ways to let php run as nobody and allow the folders to have other permissions?
Link to comment
Share on other sites

[!--quoteo(post=368587:date=Apr 25 2006, 07:18 PM:name=Brandi)--][div class=\'quotetop\']QUOTE(Brandi @ Apr 25 2006, 07:18 PM) [snapback]368587[/snapback][/div][div class=\'quotemain\'][!--quotec--]
absolutly! with permissions 777 that means anyone can get in the folder. i've seen scripts on here that allow you to run a hosting site, maybe check that out?
[/quote]

How do they get in?
Link to comment
Share on other sites

[!--quoteo(post=368588:date=Apr 25 2006, 07:23 PM:name=embsupafly)--][div class=\'quotetop\']QUOTE(embsupafly @ Apr 25 2006, 07:23 PM) [snapback]368588[/snapback][/div][div class=\'quotemain\'][!--quotec--]
How do they get in?
[/quote]
Anyone with a real answer?
Link to comment
Share on other sites

I know how chmod works, but I am asking about php upload directories as far as what permissions are best... Do you have to have 777 on the directory to allow php scripts running as nobody be able to upload an image/file? Are there more secure permissions that can be set that won't break the upload process?
Link to comment
Share on other sites

I'm not too hot on these myself but I do know that you can have chmod permissions set on a folder or a file.

I suggest having the folder set to 755 at all times. When a user uploads set the folder to 777 and once uploaded, set the folder to 755 again and set the file to 755.

There might be an easier way of doing it but as I said, I'm not too hot on this myself and this is how I'd give it a go...
Link to comment
Share on other sites

Chmod'ing the directory after the upload from 777 to 755 is a good idea, but it is not very feasable because the users don't have access to chmod the files and would have to call us all of the time to chmod them. Is there a way to do it with a script to where when they login, the directory gets chmod'd to 777 and when they logout, it gets chmod'd back to 755? I am sure there is a better way. Also if nobody owns the directory and it is 755, nobody will still have write permissions...isn't that a problem? Can't someone easily exploit nobody and get their permission levels?
Link to comment
Share on other sites

the user 'nobody' by default has no shell permissions at all, as it has no login shell specified in /etc/passwd, check this out.
If you webserver is running with 'nobody' and all file stuff is done using your webserver (php), then you can rest assured that 755 or even 775 would be secure enough, that is ofcourse, relying on the fact that your script itsself is secure, which is the most common security breach.
Link to comment
Share on other sites

[!--quoteo(post=369023:date=Apr 26 2006, 11:52 PM:name=embsupafly)--][div class=\'quotetop\']QUOTE(embsupafly @ Apr 26 2006, 11:52 PM) [snapback]369023[/snapback][/div][div class=\'quotemain\'][!--quotec--]
So ... since all of the files in the upload directory have disappeared twice, would it be because the directory was set to 777 or because there is a problem with the script?
[/quote]
My guess would be the script.
Does your script have in-built functionality to move or delete files that exist?
Link to comment
Share on other sites

[!--quoteo(post=369025:date=Apr 26 2006, 09:54 PM:name=Koen Calliauw)--][div class=\'quotetop\']QUOTE(Koen Calliauw @ Apr 26 2006, 09:54 PM) [snapback]369025[/snapback][/div][div class=\'quotemain\'][!--quotec--]
My guess would be the script.
Does your script have in-built functionality to move or delete files that exist?
[/quote]

Yes there are functions to delete the files....

What it is is a car for sale (database holds the data) and pictures stored in the filesystem.

The users can delete a car, which removes it from the database and also removes the directory.

Deleting cars works flawlessly, but I am wondering if there is a glitch if they do something wrong, like click the "submit" or "delete" button twice, or if there are two people logged in at the same time, both trying to delete the same car???
Link to comment
Share on other sites

Here is the delete script: I think I already see some problems if the delete script is not called from an intended url:

[code]
<?
$db_name = "***";
$table_name = "cars";
$connection = @mysql_connect("localhost", "***", "***")
or die(mysql_error());
$db = @mysql_select_db($db_name, $connection) or die(mysql_error());
$sql = "SELECT * FROM $table_name WHERE vehicle_id = '$_POST[vehicle_id]'";

$result = @mysql_query($sql,$connection) or die(mysql_error());
while ($row = mysql_fetch_array($result)) {
$vehicle_id = $row['vehicle_id'];
$vehicle_make = $row['vehicle_make'];
$vehicle_model = $row['vehicle_model'];
$vehicle_style = $row['vehicle_style'];
$vehicle_description = $row['vehicle_description'];
$vehicle_price = $row['vehicle_price'];
$vehicle_image_a = $row['vehicle_image_a'];
$vehicle_image_b = $row['vehicle_image_b'];
$vehicle_image_c = $row['vehicle_image_c'];
$vehicle_image_d = $row['vehicle_image_d'];
$vehicle_image_e = $row['vehicle_image_e'];
$vehicle_image_f = $row['vehicle_image_f'];
$popup_vehicle_a = $row['popup_vehicle_a'];
$popup_vehicle_b = $row['popup_vehicle_b'];
$popup_vehicle_c = $row['popup_vehicle_c'];
$popup_vehicle_d = $row['popup_vehicle_d'];
$popup_vehicle_e = $row['popup_vehicle_e'];
$popup_vehicle_f = $row['popup_vehicle_f'];

$vehicle_year = $row['vehicle_year'];
}

$dbfield = $popup_vehicle_a;

//new stuff to delete directory of images

$the_url = $dbfield;
$pieces = explode("%20", $the_url);
$state = $pieces[0];
$piece = explode("/", $state);
$uniquedir = $piece[4];
$dirname = "/home/***/www/phpcars/$uniquedir";
$files = "/home/***/www/phpcars/$uniquedir/";

// define function that will recursively enter directory and remove files in order for rmdir() function to
// work. rmdir() can not remove a directory unless it is empty, that is what this purge() function does
function purge($dir)

  {

  $handle = opendir($dir);

  while (false !== ($file = readdir($handle)))

  {

  if ($file != "." && $file != "..")

  {

  if (is_dir($dir.$file))

  {

  purge ($dir.$file."/");

  rmdir($dir.$file);

  }

  else

  {

  unlink($dir.$file);

  }

  }

  }

  closedir($handle);

  }
// end of define purge()

//call purge() function and then rmdir()
purge($files);  
rmdir($dirname);

//remove database entry
$sql = "DELETE FROM $table_name WHERE vehicle_id = '$_POST[vehicle_id]'";
$result = @mysql_query($sql,$connection) or die(mysql_error());


?>

<html>
<head>
<title>Vehicle has Been Deleted</title>
</head>

<body>
<h2>Vehicle Deleted</h2>

<p> <? echo " The <strong><u><font color=\"blue\">$_POST[vehicle_year] $_POST[vehicle_make] $_POST[vehicle_model] $_POST[vehicle_style]</font></u></strong> being offered at $$_POST[vehicle_price]"; ?> has been deleted from the Database and Website.</p>
<p>The directory: <strong><font color="red">/home/***/www/phpcars/<? echo "$uniquedir" ?> </font></strong> and it's contents have been removed from the server.</p>
<table width="84%"  border="0" cellspacing="1" cellpadding="1">
  <tr>
    <th scope="col"><a href="pick_to_delete.php">Delete Another Vehicle</a> </th>
    <th scope="col"><a href="insert_form.php">Add A New Vehicle</a></th>
    <th scope="col"><a href="show_records.php">Show All Vehicles</a> </th>
    <th scope="col"><a href="index.php">Go back to Main Menu </a></th>
  </tr>
</table>
</body>
</html>[/code]
Link to comment
Share on other sites

Exactly, I think that will be the problem, suppose googlebot hits your site, It'll not know what url to enter, just call the file without params, if that happens, no vars get set, so no $uniquedir gets set, ... boom.

Check the dirs you want to delete, check that they are at least 1 or 2 chars long (use strlen or something), check if the directory exists and make sure you put in an extra check that it does not delete some unintended dir for some weird reason.
Like this, this script was bound to have this kind of behaviour at some point.

Koen
Link to comment
Share on other sites

[!--quoteo(post=369055:date=Apr 26 2006, 10:45 PM:name=Koen Calliauw)--][div class=\'quotetop\']QUOTE(Koen Calliauw @ Apr 26 2006, 10:45 PM) [snapback]369055[/snapback][/div][div class=\'quotemain\'][!--quotec--]
Exactly, I think that will be the problem, suppose googlebot hits your site, It'll not know what url to enter, just call the file without params, if that happens, no vars get set, so no $uniquedir gets set, ... boom.

Check the dirs you want to delete, check that they are at least 1 or 2 chars long (use strlen or something), check if the directory exists and make sure you put in an extra check that it does not delete some unintended dir for some weird reason.
Like this, this script was bound to have this kind of behaviour at some point.

Koen
[/quote]

Well, the entire directory is password protected, so it must be done by someone logging in right?
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.