Форум АНТИЧАТ - Безопастность в Php

Безопасность файловой системы

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

Поскольку в PHP изначально предполагался полноправный пользовательский доступ к файловой системе, можно написать скрипт, который позволит читать системные файлы, такие как /etc/passwd, управлять сетевыми соединениями, отправлять задания принтеру, и так далее. Как следствие вы всегда должны быть уверены в том, что файлы, которые вы читаете или модифицируете, соответствуют вашим намерениям.

Рассмотрим следующий пример, в коротом пользователь создал скрипт, удаляющий файл из его домашней директории. Предполагается ситуация, когда веб-интерфейс, написанный на PHP, регулярно используется для работы с файлами, и настройки безопасности позволяют удалять файлы в домашнем каталоге.
1.Недостаточная проверка внешних данных

PHP код:


		
			
 <?php

// Удаление файла из домашней директории пользователя

$username = $_POST['user_submitted_name'];

$homedir = "/home/$username";

$file_to_delete = "$userfile";

unlink ("$homedir/$userfile");

echo "$file_to_delete has been deleted!";

?>

Поскольку переменные вводятся в пользовательской форме, существует возможность удалить файлы, принадлежащие кому-либо другому, введя соответствующие значения. В этом случае может понадобиться авторизация. Посмотрим, что произойдет, если будут отправлены значения "../etc/" и "passwd". Скрипт выполнит следующие действия:
2)Атака на файловую систему

PHP код:


		
			
 <?php

// Удаление любого файла, доступного из PHP-скрипта.

// В случае, если PHP работает с правами пользователя root:

$username = "../etc/";

$homedir = "/home/../etc/";

$file_to_delete = "passwd";

unlink ("/home/../etc/passwd");

echo "/home/../etc/passwd has been deleted!";

?>

Вот улучшеный вариант кода:
3. Более безопасная проверка имени файла

PHP код:


		
			
 <?php

// Удаление любого файла, доступного из PHP-скрипта.

$username = $_SERVER['REMOTE_USER']; // использование авторизации



$homedir = "/home/$username";



$file_to_delete = basename("$userfile"); // усечение пути

unlink ($homedir/$file_to_delete);



$fp = fopen("/home/logging/filedelete.log","+a"); //логируем удаление

$logstring = "$username $homedir $file_to_delete";

fwrite ($fp, $logstring);

fclose($fp);



echo "$file_to_delete has been deleted!";

?>

Однако и такая проверка не учитывает все возможные ситуации. Если система авторизации позволяет пользователям выбирать произвольные логины, взломщик может создать учетную запись вида "../etc/" и система опять окажется уязвимой. Исходя из этого, вам может понадобиться более строгая проверка:

4. Более строгая проверка имени файла

PHP код:


		
			
 <?php

$username = $_SERVER['REMOTE_USER']; // использование авторизации

$homedir = "/home/$username";



if (!ereg('^[^./][^/]*$', $userfile))

     die('bad filename'); //завершение работы



if (!ereg('^[^./][^/]*$', $username))

     die('bad username'); //завершение работы

//etc...

?>

Использование глобальных переменных (register_globals)
В случае, если значение параметра register_globals ON, перед выполнением вашего кода будут инициализированы различные переменные, например, переменные, переданные при отправке формы. Также, учитывая тот факт, что PHP не требует инициализации переменных, написать потенциально опасный код очень легко. Это было очень спорным решением, но общество разработчиков PHP решило изменить значение по умолчанию этой директивы на OFF. В противном случае при написании кода разработчики не могли бы с уверенностью сказать, откуда пришла та или иная переменная и насколько она достоверна. До такого нововведения переменные, определяемые разработчиком внутри скрипта, и передаваемые пользователем внешние данные могли перемешиваться. Приведем простой пример злоупотребления конфигурационной опцией register_globals:

1.Пример опасного кода с register_globals = on

PHP код:


		
			
 <?php

// устанавливаем переменную $authorized = true только для пользователей, прошедших авторизацию

if (authenticated_user()) {

    $authorized = true;

}



// Поскольку в случае неудачи при проверке авторизации переменная $authorized 

// не установлена, она может быть установлена автоматически, благодаря register_globals,

// например, при GET запросе GET auth.php?authorized=1.

// Таким образом, пройти эту проверку можно без авторизации

if ($authorized) {

    include "/highly/sensitive/data.php";

}

?>

В случае register_globals = on логика работы скрипта может быть нарушена. В случае, если установленное значение off, переменная $authorized не может быть установлена из внешних данных запроса, и скрипт будет работать корректно. Но все же инициализация переменных - один из признаков хорошего тона в программировании. Например, в приведенном выше участке кода мы могли поместить $authorized = false в качестве первой строки. Такой код работал бы как со значением on, так и off опции register_globals, и подразумевая, что по умолчанию пользователь не проходил авторизацию.

Приведем еще один пример, использующий сессии. В случае, если register_globals = on, мы можем использовать переменную $username в приведенном ниже примере, но тогда у нас не будет уверенности в достоверности ее значения (к примеру, она могла быть передана в GET-запросе).
2. Пример использования сессий со значением register_globals on или off

PHP код:


		
			
 <?php

// Мы не знаем, откуда получена переменная $username, но точно знаем, что

// переменная $_SESSION хранит в себе данные сессии

if (isset($_SESSION['username'])) {



    echo "Hello <b>{$_SESSION['username']}</b>";



} else {



    echo "Hello <b>Guest</b><br />";

    echo "Would you like to login?";



}

?>

Также существует возможность реализации оперативного реагирования в случае попытки подмены переменных. Так как во время разработки приложения мы знаем ожидаемое значение переменной, а также знаем ее достоверное значение, мы можем их сопоставить. Это не защитит код от подмены переменных, но усложнит перебор возможных вариантов. Если вы не хотите знать, как именно были получены внешние данные, используйте переменную $_REQUEST, которая состоит из данных GET и POST запросов, а также данных COOKIE. Также, информацию об этом можно найти в подразделе внешние данные в PHP.
3. Обнаружение попытки подмены переменных

PHP код:


		
			
 <?php

if (isset($_COOKIE['MAGIC_COOKIE'])) {



    // MAGIC_COOKIE получена из достоверного источника.

    // Для полной уверенности необходимо проверить ее значение.



} elseif (isset($_GET['MAGIC_COOKIE']) || isset($_POST['MAGIC_COOKIE'])) {



   mail("admin@example.com", "Обнаружена попытка взлома", $_SERVER['REMOTE_ADDR']);

   echo "Обнаружено нарушение безопасности, администратор уведомлен.";

   exit;



} else {



   // MAGIC_COOKIE в данных запроса не присутствует

}

?>

Данные, введенные пользователем
Наиболее опасные дыры во многих PHP-скриптах возникают не столько из-за самого языка, сколько из-за кода, написанного без учета соответствующих требований безопасности. Как следствие, вы всегда должны выделять время на исследование разрабатываемого участка кода, чтобы оценить потенциальную угрозу от ввода переменной с нестандартным значением.
1. Потенциально опасное использование переменных

PHP код:


		
			
 <?php

// удалить файлы из домашней директории пользователя...

// а может, еще что нибудь?

unlink ($evil_var);



// записать в лог-файл выполняемое действие... 

// может быть, даже /etc/passwd?

fwrite ($fp, $evil_var);



// выполнение тривиальных действий... или rm -rf *?

system ($evil_var);

exec ($evil_var);



?>

Вы должны тщательно проверять ваш код и быть абсолютно уверены в том, что все данные, передаваемые веб-браузером, проверяются надлежащим образом. Попробуйте ответить для себя на следующие вопросы:

*

Будет ли данный скрипт воздействовать исключительно на предполагаемые данные?
*

Правильно ли будут обработаны некорректные или нестандартные данные?
* Возможно ли использование скрипта не предусмотренным способом?
* Возможно ли его использование в сочетании с другими скриптами в негативных целях?
* Будет ли каждая транзакция корректно логирована (протоколирована)?

Ответив на эти вопросы во время написания скрипта, а не после, вы, возможно, предотвратите последующую доработку скрипта в целях повышения его безопасности. Начиная разработку с этих вопросов, вы не гарантируете полную безопасность вашей системы, но сможете значительно повысить её.

Вы также можете предусмотреть отключение таких конфигурационных опций, как register_globals, magic_quotes и некоторых других, которые могут приводить к сомнениям относительно происхождения или значения получаемых переменных. Использование при написании кода режима error_reporting(E_ALL) может помочь, предупреждая вас об использовании переменных до инициализации или проверки (что предотвратит работу с данными, отличныи от ожидаемых).

"Волшебные Кавычки" (magic quotes)
"Волшебные Кавычки" (Magic Quotes) - это процесс, который позволяет автоматически экранировать входные данные PHP скрипта. Данный принцип позволяет экранировать внешние данные, приходящие в PHP скрипт во время его выполнения.

Когда "Волшебные Кавычки" включены (активизированы), все ' (одиночные кавычки), " (двойные кавычки), \ (левый слэш) и NULL знаки автоматически экранируются левыми слэшами (\). Данный принцип аналогичен действию функции addslashes().

Существуют три директивы "Волшебных Кавычек":

#magic_quotes_gpc

Затрагивает данные запросов HTTP (GET, POST, и COOKIE). Не может быть установлена в процессе работы PHP скрипта и установлена в on по умолчанию.

#magic_quotes_runtime

Если данная директива включена (on), большинство функций, которые возвращают данные из внешнего источника, включая базы данных и текстовые файлы, будут экранировать данные левыми слэшами (\). Может быть установлена во время выполнения PHP скрипта. По умолчанию директива установлена в off.

Смотрите описание функций set_magic_quotes_runtime() и get_magic_quotes_runtime().

#magic_quotes_sybase

Если данная директива включена (on), одиночные кавычки экранируются двойными кавычками, вместо левых слэшей (\). Причем если данная директива установлена в on, это полностью отменяет установку директивы magic_quotes_gpc. Включение (on) обеих директив будет означать, что будут экранироваться только одиночные кавычки двойными кавычками ("). Двойные кавычки ("), левые слэши (\) и NULL останутся нетронутыми.

Зачем использовать "Волшебные Кавычки"?

1. Это полезно для начинающих программистов PHP

"Волшебные кавычки" были добавлены в PHP, чтобы помочь начинающим программистам языка PHP избегать фатальных последствий для безопасности системы при ошибках в коде написанных PHP скриптов, причем автоматически, без участия самого программиста. Хотя риск SQL инъекций при этом остается возможным, степень такого риска сводится к минимуму.

2. Это довольно удобно

Для того, чтобы вставлять данные в базу данных, "Волшебные Кавычки" можно не добавлять функцией addslashes() на всех Get, Post, и Cookie запросах, а делать это автоматически.

Почему не нужно использовать "Волшебные Кавычки"?

1. Мобильность

Включение экранирования и его выключение влияет на вашу мобильность. Используйте функцию get_magic_quotes_gpc() для проверки активной установки конфигурации "Волшебных Кавычек".

2. Производительность

Поскольку не каждая часть экранируемых данных используется в базах данных, существует потеря производительности PHP, поскольку обработка данных на предмет необходимости "экранирования" влечет за собой некоторую дополнительную нагрузку на систему. При необходимости произвести "экранирование" данных вы можете просто обращаться к соответствующим функциям (таким как addslashes()) и не пребегать к автоматическому экранированию "Волшебными Кавычками".

Вообще, при установке рекоммендуемых значений директив в файле конфигурации php.ini, автоматическое использование "Волшебних Кавычек" отключено, именно по соображениям производительности.

3. Неудобство

Поскольку не все данные нуждаются в экранировании, часто раздражет видеть "Волшебные Кавычки" там, где их не должно быть.Например, используя скрипт посылки электронной почту из формы, и видя связку \' в полученном сообщении электронной почты. А для устанения данной неприятности вам нужно будет часто прибегать к использованию функции stripslashes(), что, согласитесь, не очень удобно.

Про безопасный режим(safe_mode) можно прочитать здесь
Про защиту баз данных(sql-inj) можно прочитать в статьях на этом форуме =\

php.su