DELETE bug. Content Vanishing???

[face3500]

I have several sites hosted with the same hosting company (blueho..) and they are all having this issue. Same code is used on sites NOT on that hosting do not have this issue.

When the DELETE scripts are published to the server, the content will vanish randomly, with no notice and no sort of predictable pattern. Will just be gone... and the hosting company cannot see why it's happening. If I remove the DELETE scripts from the server, this does not happen at all. All admin scripts are protected via user login password.

Can anyone look at the code and see what would be causing this? PLEASE HELP!! 😕

<?php  

  $id = $_GET['id']; 

  $sql = "SELECT * "; 
  $sql .= "FROM gallery "; 
  $sql .= "WHERE id='$id' "; 

 $result = mysql_query($sql); 
 $row = mysql_fetch_assoc($result);

 $img_sm = $row['img_sm']; 
 $img_lg = $row['img_lg'];



 if(is_file("../gallery/$img_sm")) { 
    unlink("../gallery/$img_sm"); 
 } 

 if(is_file("../gallery/$img_lg")) { 
    unlink("../gallery/$img_lg"); 
 } 


 $sql = "DELETE FROM gallery "; 
 $sql .= "WHERE id='$id' "; 

 if(mysql_query($sql)) { 
    header('Location: gallery_index.php'); 
 } 
 else { 
    die('<h1>Unable to remove image</h1>'); 
 } 

?> 

[DaveRandom]

I can't see anything wrong with code, it will do what you ask, when it is invoked. The problem must be that the script is being invoked by someone/something at random.

I would dump the contents of $_SERVER to a file at the beginning of every invoke, might help you figure out where it is being called from.

e.g. (at the top of the script)

ob_start();
print_r($_SERVER);
$_serverdump = ob_get_contents();
ob_end_clean();
file_put_contents(time().'.txt',$_serverdump);

[anakadote]

Another suggestion, you should also add "LIMIT 1" to the end of your SELECT and especially your DELETE queries (assuming you're only selecting and deleting one row, respectively).

[face3500]

thanks for the tip, will plug that in and see what it shows.

Anyone else have any ideas while I wait for the next "magical" deletion.

[face3500]

anakadote I added those in... good call there.

DaveRandom, I added the dump to the top of the script, and then went and ran a delete of a photo. I cannot find any text files that have been created as a result. Did I miss something??

<?php  

ob_start();
print_r($_SERVER);
$_serverdump = ob_get_contents();
ob_end_clean();
file_put_contents(time().'.txt',$_serverdump); 

  $id = $_GET['id']; 

  $sql = "SELECT * "; 
  $sql .= "FROM gallery "; 
  $sql .= "WHERE id='$id' "; 
  $sql .= "LIMIT 1 ";

.
.
.

[dewcansam]

face3500;10972655 wrote:

I cannot find any text files that have been created as a result. Did I miss something??

It is possible that the hosting company will not allow you to create files on the fly. I have run into that issue before. I had a site that wrote site access issues to a log. The hosting company actually changed their policy while the site was in service and i started missing all kinds of logs and info.

Check with them and see if you can create files on the server using PHP.

or run this:

<?php
$log_filename = "./contact_log_cls.csv";
$log_entry = "test file";
$fp = fopen($log_filename, 'a') or die("could not open $log_filename");
fwrite($fp, $log_entry);
fclose($fp);

WARNING !!! make sure you delete this as soon as you run the file test

[DaveRandom]

If you can't create files, create a new temporary table in your DB and insert the contents of $_serverdump into a varchar field instead.

Or, create a file that PHP can modify (via FTP or something), and append the data to it...

$file_i_can_modify = '/home/myfile.txt';
ob_start();
print_r($_SERVER);
$_serverdump = ob_get_contents();
ob_end_clean();
$fp = fopen($file_i_can_modify,'a');
fwrite($fp,"\n============\n".date('Y-m-d H:i:s')."\n============\n".$_serverdump);
fclose($fp);

[face3500]

Sorry for the delay with this post.. finally had the deletion occur, and it did generate a txt file for every single deletion of every single image. I am not sure how to determine what it all means though. Can you guys help?

one of the txt files below:

Array
(
    [DOCUMENT_ROOT] => /home5/marshaq1/public_html
    [GATEWAY_INTERFACE] => CGI/1.1
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5
    [HTTP_CONNECTION] => keep-alive
    [HTTP_HOST] => www.marshallgrills.com
    [HTTP_KEEP_ALIVE] => 30
    [HTTP_USER_AGENT] => Mozilla/5.0 (compatible; Purebot/1.1; +http://www.puritysearch.net/)
    [PATH] => /bin:/usr/bin
    [QUERY_STRING] => id=46
    [REDIRECT_STATUS] => 200
    [REMOTE_ADDR] => 91.205.96.19
    [REMOTE_PORT] => 45341
    [REQUEST_METHOD] => GET
    [REQUEST_URI] => /admin/gallery_remove.php?id=46
    [SCRIPT_FILENAME] => /home5/marshaq1/public_html/admin/gallery_remove.php
    [SCRIPT_NAME] => /admin/gallery_remove.php
    [SERVER_ADDR] => 66.147.242.187
    [SERVER_ADMIN] => [e-mail]
    [SERVER_NAME] => www.marshallgrills.com
    [SERVER_PORT] => 80
    [SERVER_PROTOCOL] => HTTP/1.1
    [SERVER_SIGNATURE] => <address>Apache Server at www.marshallgrills.com Port 80</address>

[SERVER_SOFTWARE] => Apache
[UNIQUE_ID] => TVaAgkKT8rsAAEAFP40AAAAc
[file_gzip] => /ramdisk/cpud/status
[PHP_SELF] => /admin/gallery_remove.php
[REQUEST_TIME] => 1297514627
[argv] => Array
    (
        [0] => id=46
    )

[argc] => 1
)

[face3500]

just a quick addition. I found via Google search that the purebot/1.1 is a long known "bad bot" and seems to be doing all the damage.

I have blocked a list of known IPs for this bot and also the "user agent" using htaccess.

Anything else I can do? No one seems to see where / how they are able to get to this admin script.

[bradgrafelman]

face3500 wrote:

No one seems to see where / how they are able to get to this admin script.

Er, why does that matter? Are you suggesting that the only security you have is 'security through obscurity' (e.g. you just hope that no one guesses the correct URL...) which, in my honest opinion, is no security at all?

[face3500]

bradgrafelman;10974451 wrote:

Er, why does that matter? Are you suggesting that the only security you have is 'security through obscurity' (e.g. you just hope that no one guesses the correct URL...) which, in my honest opinion, is no security at all?

no no, all of the admin pages password protected with PHP. That is why it's not apparent how they are actually able to access the script. my guess is code injection of some wort, but I am no hacker and no one else has been able to figure it out either.

if(!isset($_SESSION)) {
	session_start();
	session_regenerate_id();
}

session_start();
if($_SESSION['logged_in'] != true) {
	header('Location: login.php');
}

[bradgrafelman]

face3500 wrote:

no one else has been able to figure it out either.

Er... did you show any intermediate/seasoned PHP developers? :p

Your problem is here:

if($_SESSION['logged_in'] != true) {
	header('Location: login.php');
}

What that code does is sets a new HTTP header that is to be sent as part of the PHP script's reponse. That's it.

The rest of the script is going to execute just as it should. This is why you'll see many developers around here use an [man]exit[/man] statement after a header() redirect (e.g. using HTTP headers to abort the current request and redirect the user elsewhere instead).

[face3500]

Have done some reworking on the login scripts. I agree there should definitely be an exit; in there. I have added a few other measures as well (sanitizing and salt) so hopefully with these the issue will subside.

Thanks for your help guys.