Безопасность файловой системы php
PHP это субъект системы безопасности, встроенной в большинство серверных систем, с учётом разрешений на доступ к файлам и на базе директорий. Это позволяет управлять тем, какие файлы можно читать в файловой системе. Нужно проявлять осторожность при чтении любых файлов, чтобы гарантировать безопасность при чтении любыми пользователями, имеющими доступ к данной файловой системе.
Поскольку PHP был разработан так, чтобы дать пользовательский доступ к файловой системе, можно создать PHP-скрипт, который позволит вам читать такие системные файлы как /etc/passwd, модифицировать внутрисетевые соединения, отправлять задания принтеру etc. Это, очевидно, подразумевает, что вы должны быть уверены, что файлы, которые вы читаете и записываете, являются соответствующими файлами.
Рассмотрим следующий скрипт, где пользователь указывает, что он хотел бы удалить файл в своей home-директории. Это предполагает ситуацию, когда web-интерфейс РНР регулярно используется для работы с файлами, как в случае, когда пользователь сервера Apache может удалять файлы в своих домашних директориях.
Пример 4-1. Плохая проверка переменных ведёт к .
Поскольку username отправляется из пользовательской формы методом post, можно отправлять username и файл, принадлежащие кому-либо ещё, и удалять файлы. В этом случае может понадобиться использование какой-нибудь иной формы аутентификации. Посмотрим, что произойдёт, если будут отправлены переменные «../etc/» и «passwd». Код тогда сможет эффективно читать:
Пример 4-2. . атака на файловую систему
Есть два средства, которые вы должны использовать для предотвращения такого поведения.
- Давать web-пользователю только ограниченный доступ к экзешнику PHP.
- Проверять все переменные, которые отправляются из формы.
Пример 4-3. Более безопасная проверка имени файла
Однако и здесь не без недостатков. Если ваша система аутентификации разрешает пользователям создавать свои собственные пользовательские login’ы и пользователь выберет логин «../etc/», система снова станет открытой. Исходя из этого, вам может понадобиться более специализированная проверка:
Пример 4-4. Ещё более безопасная проверка имени файла
В зависимости от вашей ОС, необходимо предусматривать использование разнообразных файлов, включая вхождения устройств (/dev/ или COM1), файлов конфигурации (/etc/ и .ini-файлы), хорошо известные области хранения данных (/home/, My Documents), etc.
Поэтому обычно легче реализовать такую политику, когда вы запрещаете всё, за исключением того, что явно разрешено.
|
Безопасность файловой системы
PHP является одним из важных моментов в вопросе безопасности сервера, поскольку PHP-скрипты могут манипулировать файлами и каталогами на диске. В связи с этим существуют конфигурационные настройки, указывающие, какие файлы могут быть доступны и какие операции с ними можно выполнять. Необходимо проявлять осторожность, поскольку любой из файлов, с полными правами чтения («world readable») может быть прочитан каждым, кто имеет доступ к файловой системе.
Поскольку в PHP изначально предполагался полноправный пользовательский доступ к файловой системе, можно написать PHP -скрипт, который позволит читать системные файлы, такие как /etc/passwd, управлять сетевыми соединениями, отправлять задания принтеру, и так далее. Как следствие, вы всегда должны быть уверены в том, что файлы, которые вы читаете или модифицируете, являются именно теми, которые вы подразумевали.
Рассмотрим следующий пример, в котором пользователь создал скрипт, удаляющий файл из его домашней директории. Предполагается ситуация, когда веб-интерфейс, написанный на PHP , регулярно используется для работы с файлами, и настройки безопасности позволяют удалять файлы в домашнем каталоге.
Пример #1 Недостаточная проверка внешних данных ведет к.
// Удаление файла из домашней директории пользователя
$username = $_POST [ ‘user_submitted_name’ ];
$userfile = $_POST [ ‘user_submitted_filename’ ];
$homedir = «/home/ $username » ;
unlink ( » $homedir / $userfile » );
Поскольку переменные вводятся в пользовательской форме, существует возможность удалить файлы, принадлежащие кому-либо другому, введя соответствующие значения. В этом случае может понадобиться авторизация. Посмотрим, что произойдет, если будут отправлены значения «../etc/» и «passwd». Скрипт выполнит следующие действия:
Пример #2 . атаке на файловую систему
// Удаление любого файла, доступного из PHP-скрипта.
// В случае, если PHP работает с правами пользователя root:
$username = $_POST [ ‘user_submitted_name’ ]; // «../etc»
$userfile = $_POST [ ‘user_submitted_filename’ ]; // «passwd»
$homedir = «/home/ $username » ; // «/home/../etc»
unlink ( » $homedir / $userfile » ); // «/home/../etc/passwd»
- Ограничить доступ пользователя, с правами которого работает веб-сервер с PHP .
- Проверять все данные, вводимые пользователем.
Пример #3 Более безопасная проверка имени файла
// Удаление любого файла, к которому имеет доступ пользователь,
// под которым запущен PHP.
$username = $_SERVER [ ‘REMOTE_USER’ ]; // использование авторизации
$userfile = basename ( $_POST [ ‘user_submitted_filename’ ]);
$homedir = «/home/ $username » ;
$filepath = » $homedir / $userfile » ;
if ( file_exists ( $filepath ) && unlink ( $filepath )) $logstring = » $filepath удален\n» ;
> else $logstring = «Не удалось удалить $filepath \n» ;
>
$fp = fopen ( «/home/logging/filedelete.log» , «a» );
fwrite ( $fp , $logstring );
fclose ( $fp );
echo htmlentities ( $logstring , ENT_QUOTES );
Однако и такая проверка не учитывает все возможные ситуации. Если система авторизации позволяет пользователям выбирать произвольные логины, взломщик может создать учетную запись вида «../etc/» и система опять окажется уязвимой. Исходя из этого, вам может понадобиться более строгая проверка:
Пример #4 Более строгая проверка имени файла
$username = $_SERVER [ ‘REMOTE_USER’ ]; // использование авторизации
$userfile = $_POST [ ‘user_submitted_filename’ ];
$homedir = «/home/ $username » ;
$filepath = » $homedir / $userfile » ;
if (! ctype_alnum ( $username ) || ! preg_match ( ‘/^(?:[a-z0-9_-]|\.(?!\.))+$/iD’ , $userfile )) die( «Неправильное имя пользователя или файл» );
>
В зависимости от используемой вами операционной системы необходимо предусматривать возможность атаки на разнообразные файлы, включая системные файлы устройств (/dev/ или COM1), конфигурационные файлы (например /etc/ или файлы с расширением .ini), хорошо известные области хранения данных (/home/, My Documents), и так далее. Исходя из этого, как правило, легче реализовать такую политику безопасности, в которой запрещено все, исключая то, что явно разрешено.
Безопасность файловой системы
PHP является одним из важных моментов в вопросе безопасности сервера, поскольку PHP-скрипты могут манипулировать файлами и каталогами на диске. В связи с этим существуют конфигурационные настройки, указывающие, какие файлы могут быть доступны и какие операции с ними можно выполнять. Необходимо проявлять осторожность, поскольку любой из файлов, с полными правами чтения («world readable») может быть прочитан каждым, кто имеет доступ к файловой системе.
Поскольку в PHP изначально предполагался полноправный пользовательский доступ к файловой системе, можно написать PHP -скрипт, который позволит читать системные файлы, такие как /etc/passwd, управлять сетевыми соединениями, отправлять задания принтеру, и так далее. Как следствие, вы всегда должны быть уверены в том, что файлы, которые вы читаете или модифицируете, являются именно теми, которые вы подразумевали.
Рассмотрим следующий пример, в котором пользователь создал скрипт, удаляющий файл из его домашней директории. Предполагается ситуация, когда веб-интерфейс, написанный на PHP , регулярно используется для работы с файлами, и настройки безопасности позволяют удалять файлы в домашнем каталоге.
Пример #1 Недостаточная проверка внешних данных ведет к.
// Удаление файла из домашней директории пользователя
$username = $_POST [ ‘user_submitted_name’ ];
$userfile = $_POST [ ‘user_submitted_filename’ ];
$homedir = «/home/ $username » ;
unlink ( » $homedir / $userfile » );
Поскольку переменные вводятся в пользовательской форме, существует возможность удалить файлы, принадлежащие кому-либо другому, введя соответствующие значения. В этом случае может понадобиться авторизация. Посмотрим, что произойдет, если будут отправлены значения «../etc/» и «passwd». Скрипт выполнит следующие действия:
Пример #2 . атаке на файловую систему
// Удаление любого файла, доступного из PHP-скрипта.
// В случае, если PHP работает с правами пользователя root:
$username = $_POST [ ‘user_submitted_name’ ]; // «../etc»
$userfile = $_POST [ ‘user_submitted_filename’ ]; // «passwd»
$homedir = «/home/ $username » ; // «/home/../etc»
unlink ( » $homedir / $userfile » ); // «/home/../etc/passwd»
- Ограничить доступ пользователя, с правами которого работает веб-сервер с PHP .
- Проверять все данные, вводимые пользователем.
Пример #3 Более безопасная проверка имени файла
// Удаление любого файла, к которому имеет доступ пользователь,
// под которым запущен PHP.
$username = $_SERVER [ ‘REMOTE_USER’ ]; // использование авторизации
$userfile = basename ( $_POST [ ‘user_submitted_filename’ ]);
$homedir = «/home/ $username » ;
$filepath = » $homedir / $userfile » ;
if ( file_exists ( $filepath ) && unlink ( $filepath )) $logstring = » $filepath удален\n» ;
> else $logstring = «Не удалось удалить $filepath \n» ;
>
$fp = fopen ( «/home/logging/filedelete.log» , «a» );
fwrite ( $fp , $logstring );
fclose ( $fp );
echo htmlentities ( $logstring , ENT_QUOTES );
Однако и такая проверка не учитывает все возможные ситуации. Если система авторизации позволяет пользователям выбирать произвольные логины, взломщик может создать учетную запись вида «../etc/» и система опять окажется уязвимой. Исходя из этого, вам может понадобиться более строгая проверка:
Пример #4 Более строгая проверка имени файла
$username = $_SERVER [ ‘REMOTE_USER’ ]; // использование авторизации
$userfile = $_POST [ ‘user_submitted_filename’ ];
$homedir = «/home/ $username » ;
$filepath = » $homedir / $userfile » ;
if (! ctype_alnum ( $username ) || ! preg_match ( ‘/^(?:[a-z0-9_-]|\.(?!\.))+$/iD’ , $userfile )) die( «Неправильное имя пользователя или файл» );
>
В зависимости от используемой вами операционной системы необходимо предусматривать возможность атаки на разнообразные файлы, включая системные файлы устройств (/dev/ или COM1), конфигурационные файлы (например /etc/ или файлы с расширением .ini), хорошо известные области хранения данных (/home/, My Documents), и так далее. Исходя из этого, как правило, легче реализовать такую политику безопасности, в которой запрещено все, исключая то, что явно разрешено.