Ну, вы можете заглянуть в /etc/group
, чтобы увидеть, к каким группам _www
принадлежит:
$ grep _www /etc/group
_www:*:70:_devicemgr,_teamsserver
На правильно настроенном сервере весь смысл работы веб-сервера в качестве выделенного пользователя состоит в том, чтобы ограничить привилегии этого пользователя в другом месте. Однако код веб-приложения, который обращается к файловой системе, способен читать вне DocumentRoot сервера.
Следовательно, любой файл, не принадлежащий _www
, но для которого он имеет разрешения на чтение и выполняет в родительском каталоге файла, теоретически может быть прочитан _www
, если код приложения не защищает от этого при чтении файловой системы. , Аналогично, файлы в файловой системе, которые могут быть записаны другим образом, могут быть изменены веб-сервером, если код приложения обеспечивает к ним доступ.
Такие проблемы можно использовать, когда приложение использует пользовательский ввод для генерации пути к файлу для чтения или записи, но не может защитить от ввода, например: ../../../../../../../../../
, который, когда возможно, связан с NULL-байтовым вводом может создавать имена файлов в приложении, такие как
/www/application/phptemplates/../../../../../../../../../../etc/passwd
Конечно, в современной системе /etc/passwd
на самом деле не хранит пароли, но может раскрыть локальных пользователей и другую ценную информацию потенциальному злоумышленнику.