Как мои ранее незапятнанные данные могут снова испортиться? - PullRequest
2 голосов
/ 28 августа 2010

У меня есть небольшая загадка, которую я не совсем понимаю, причину.Я получаю «Небезопасную зависимость в unlink при работе с ключом -T» при попытке вызвать unlink из скрипта.Это не загадка, так как я понимаю, что это означает, что Perl говорит, что я пытаюсь использовать испорченные данные.Тайна в том, что эти данные ранее не были сохранены в другом скрипте, который без проблем сохранил их на диск.

Вот как это происходит ... Первый скрипт создает двоичное имя файла, используя следующее

# For the binary file upload
my $extensioncheck = '';

my $safe_filename_characters = "a-zA-Z0-9_.";
  if ( $item_photo )  
  { 
    # Allowable File Type Check
    my ( $name, $path, $extension ) = fileparse ( $item_photo, '\..*' );
    $extensioncheck = lc($extension);
    if (( $extensioncheck ne ".jpg" ) && ( $extensioncheck ne ".jpeg" ) &&
        ( $extensioncheck ne ".png" ) && ( $extensioncheck ne ".gif" ))
    {
      die "Your photo file is in a prohibited file format.";  
    }

    # Rename file to Ad ID for adphoto directory use and untaint
    $item_photo = join "", $adID, $extensioncheck;
    $item_photo =~ tr/ /_/;  
    $item_photo =~ s/[^$safe_filename_characters]//g;  
    if ( $item_photo =~ /^([$safe_filename_characters]+)$/ ) { $item_photo = $1; }
    else {  die "Filename contains invalid characters"; }  
    }

$ adID генерируется самим сценарием с использованием функции localtime (time), поэтому он не должен быть испорчен.$ item_photo переназначается с использованием $ adID и $ extensioncheck ПЕРЕД проверкой заражения, поэтому новый $ item_photo теперь не запятнан.Я знаю это, потому что сам $ item_photo не имеет проблем с последним отключением связи в скрипте.$ item_photo используется достаточно долго для создания трех других файлов изображений с помощью ImageMagick, прежде чем он будет брошен с помощью функции unlink.Три имени файла, созданные в результате обработки $ item_photo в ImageMagick, создаются просто так:

$largepicfilename  = $adID . "_large.jpg";
$adpagepicfilename = $adID . "_adpage.jpg";
$thumbnailfilename = $adID . "_thumbnail.jpg";

Пути добавляются к новым именам файлов для создания URL-адресов и определяются в верхней части скрипта, поэтомуони также не могут быть испорчены.URL-адреса для этих файлов создаются следующим образом.

my $adpageURL = join "", $adpages_dir_URL, $adID, '.html';
my $largepicURL  = join "", $adphotos_dir_URL, $largepicfilename;
my $adpagepicURL = join "", $adphotos_dir_URL, $adpagepicfilename;
my $thumbnailURL = join "", $adphotos_dir_URL, $thumbnailfilename;

Затем я записываю их в запись, зная, что все незапятнано.

Теперь перейдем к винтовой части.Во втором сценарии я зачитываю эти файлы, которые нужно удалить, используя функцию unlink, и именно здесь я получаю свой флаг «Зависимость от незащищенности».

# Read in the current Ad Records Database
open (ADRECORDS, $adrecords_db) || die("Unable to Read Ad Records Database");
flock(ADRECORDS, LOCK_SH);
seek (ADRECORDS, 0, SEEK_SET);
my @adrecords_data = <ADRECORDS>;
close(ADRECORDS);

# Find the Ad in the Ad Records Database
ADRECORD1:foreach $AdRecord(@adrecords_data)
{
  chomp($AdRecord);
  my($adID_In, $adpageURL_In, $largepicURL_In, $adpagepicURL_In, $thumbnailURL_In)=split(/\|/,$AdRecord);

  if ($flagadAdID ne $adID_In) { $AdRecordArrayNum++; next ADRECORD1 }
  else
  {
    #Delete the Ad Page and Ad Page Images
    unlink ("$adpageURL_In");
    unlink ("$largepicURL_In");
    unlink ("$adpagepicURL_In");
    unlink ("$thumbnailURL_In");
    last ADRECORD1;
  }
}

Я знаю, что могу просто снова их удалить, илидаже просто взорвать их, зная, что данные в безопасности, но это не главное.Я хочу понять, ПОЧЕМУ это происходит в первую очередь, поскольку я не понимаю, как эти ранее незапятнанные данные теперь воспринимаются как испорченные.Любая помощь в разъяснении того, где мне не хватает этой связи, была бы очень признательна, потому что я действительно хочу понять это, а не просто написать взлом, чтобы исправить это.

1 Ответ

4 голосов
/ 28 августа 2010

Сохранение данных в файл не сохраняет бит данных с данными. Это просто данные, поступающие из внешнего источника, поэтому, когда Perl читает их, они автоматически портятся. Во втором сценарии вам придется явно удалить данные.

В конце концов, некоторые другие вредоносные программы могли изменить данные в файле, прежде чем второй сценарий сможет их прочитать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...