 | PHP это субъект системы безопасности, встроенной в
большинство серверных систем, с учётом разрешений на доступ к файлам и на базе
директорий. Это позволяет управлять тем, какие файлы можно читать в файловой системе.
Нужно проявлять осторожность при чтении любых файлов, чтобы гарантировать безопасность
при чтении любыми пользователями, имеющими доступ к данной файловой системе. Поскольку
PHP был разработан так, чтобы дать пользовательский доступ к файловой системе,
можно создать PHP-скрипт, который позволит вам читать такие системные файлы как
/etc/passwd, модифицировать внутрисетевые соединения, отправлять задания принтеру
etc. Это, очевидно, подразумевает, что вы должны быть уверены, что файлы, которые
вы читаете и записываете, являются соответствующими файлами. Рассмотрим
следующий скрипт, где пользователь указывает, что он хотел бы удалить файл в своей
home-директории. Это предполагает ситуацию, когда web-интерфейс РНР регулярно
используется для работы с файлами, как в случае, когда пользователь сервера Apache
может удалять файлы в своих домашних директориях.
Пример 4-1. Плохая проверка переменных ведёт к ...<?php
// удалить файлы из домашней директории пользователя $username = $_POST['user_submitted_name'];
$homedir = "/home/$username"; $file_to_delete = "$userfile"; unlink ($homedir/$userfile);
echo "$file_to_delete has been deleted!"; ?> |
|
Поскольку
username отправляется из пользовательской формы методом post, можно отправлять
username и файл, принадлежащие кому-либо ещё, и удалять файлы. В этом случае может
понадобиться использование какой-нибудь иной формы аутентификации. Посмотрим,
что произойдёт, если будут отправлены переменные "../etc/" и "passwd". Код тогда
сможет эффективно читать:
Пример 4-2. ... атака на файловую систему
<?php // Удалить файл с жёсткого диске, доступ к которому имеет пользователь
РНР. // Если РНР имеет root-доступ: $username = "../etc/"; $homedir = "/home/../etc/";
$file_to_delete = "passwd"; unlink ("/home/../etc/passwd"); echo "/home/../etc/passwd
has been deleted!"; ?> |
|
Есть два
средства, которые вы должны использовать для предотвращения такого поведения.
Давать web-пользователю только ограниченный доступ к экзешнику PHP. Проверять
все переменные, которые отправляются из формы.
Вот улучшенный скрипт:
Пример 4-3. Более безопасная проверка имени файла
<?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");
//log удаление $logstring = "$username $homedir $file_to_delete"; fputs ($fp,
$logstring); fclose($fp); echo "$file_to_delete has been deleted!"; ?> | |
Однако
и здесь не без недостатков. Если ваша система аутентификации разрешает пользователям
создавать свои собственные пользовательские login'ы и пользователь выберет логин
"../etc/", система снова станет открытой. Исходя из этого, вам может понадобиться
более специализированная проверка:
Пример 4-4. Ещё более безопасная проверка имени файла
<?php $username = $_SERVER['REMOTE_USER']; // использование механизма
аутентификации $homedir = "/home/$username"; if (!ereg('^[^./][^/]*$', $userfile))
die('bad filename'); //закончить, не продолжать if (!ereg('^[^./][^/]*$', $username))
die('bad username'); //закончить, не продолжать //etc... ?> | |
В
зависимости от вашей ОС, необходимо предусматривать использование разнообразных
файлов, включая вхождения устройств (/dev/ или COM1), файлов конфигурации (/etc/
и .ini-файлы), хорошо известные области хранения данных (/home/, My Documents),
etc.
Поэтому обычно легче реализовать такую политику, когда вы запрещаете
всё, за исключением того, что явно разрешено. | |