Утечка безопасности chmod 777 в каталоге журналов?

Я размещаю свой сайт на общем сервере, поэтому мои возможности ограничены. Например, у меня нет доступа к функции exec.

Моя проблема в том, что моей очень простой addLog PHP-функции нужны права для записи в лог-файлы. В другом сообщении я читал, что пользователь PHP обычно ассимилируется как «другие» в традиционной схеме разрешений UNIX «владелец-группа-другие».

Однако, поскольку я построил свою собственную структуру www, я подумал о том, чтобы установить права доступа для моего каталога ./log на 777, чтобы сценарий мог писать в необходимые журналы.

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

  • Существует ли угроза безопасности при установке прав доступа к каталогу журналов 777?
    В этой папке нет ничего, кроме журналов.
  • Нужны ли для этого каталога права на чтение и выполнение?
    Мне действительно нужно только записывать (добавлять) в журналы.

logging php permissions chmod
person Sebas    schedule 19.05.2012    source источник
comment
Это зависит от того, как настроен этот виртуальный хостинг.   -  person zerkms    schedule 19.05.2012
comment
это может быть очень плохой идеей, например, если папка log доступна через Интернет и позволяет выполнять сценарии   -  person wroniasty    schedule 19.05.2012
comment
@wroniasty: 777 в каталоге не имеет ничего общего с it allows executing scripts. Также - 777 не дает никаких дополнительных привилегий при доступе к нему через http   -  person zerkms    schedule 19.05.2012
comment
@zerkms, не могли бы вы подробно рассказать, как настройка виртуального хостинга повлияет на мое решение, пожалуйста?   -  person Sebas    schedule 19.05.2012
comment
@Sebas: это зависит от того, что могут сделать другие пользователи хостинга. И я не уверен, что кто-то может догадаться наверняка для вашего конкретного случая (мы даже не знаем, какой хостинг вы используете)   -  person zerkms    schedule 19.05.2012
comment
Как вы думаете, какая информация будет актуальной? Хост - unix, но для остальной части задействованной технологии, я думаю, мне придется исследовать   -  person Sebas    schedule 19.05.2012
comment
@zerkms 777 позволяет всем (включая пользователя веб-сервера) писать в каталог, открывая возможность загрузки и выполнения скрипта на стороне сервера.   -  person wroniasty    schedule 19.05.2012
comment
@zerkms, так как это связано с: 777 doens't give any additional privileges when you access it through http?   -  person wroniasty    schedule 19.05.2012
comment
@wroniasty: это относится к: это может быть очень плохой идеей, например, если папка журнала доступна через Интернет и позволяет выполнять сценарии. 777 - плохая идея в любом случае, вне зависимости от того, доступен он извне или нет   -  person zerkms    schedule 19.05.2012
comment
@zerkms, является ли 703 более строгим в отношении выполнения вредоносных скриптов? это на самом деле одна из моих проблем с самого начала.   -  person Sebas    schedule 19.05.2012
comment
@zerkms, я полностью с вами согласен, выполнение скриптов - это просто пример того зла, которое приходит с 777.   -  person wroniasty    schedule 19.05.2012
comment
@Sebas - 703 IS более ограничительный, но IMO все еще недостаточно ограничительный.   -  person wroniasty    schedule 19.05.2012

Ответы (1)


arrow_upward
2
arrow_downward

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

Если PHP пишет журнал, теоретически он также должен иметь возможность читать журнал. Суть в том, что владельцем файла становится тот же пользователь, который будет писать в файл. Затем используйте соответствующие разрешения.

Конечно, если вы не беспокоитесь о безопасности своего сайта и нет подключений к БД, это действительно не имеет значения.

На самом деле зависит от общей среды. Я видел плохо настроенный виртуальный хостинг, где пользователи могут проходить по FTP и просматривать другие файлы/папки. 777 — не лучшая идея для виртуального хостинга. (Лучше быть в безопасности, чем потом сожалеть)

person Adam Culp    schedule 19.05.2012
comment
Это ужасно неправильный ответ. Разрешения файловой системы не имеют большого отношения к доступности через http - person zerkms; 19.05.2012
comment
Да, вы правы, но на виртуальном хостинге он может быть ШИРОКИМ открытым для других пользователей на коробке. - person Adam Culp; 19.05.2012
comment
он открыт, и что? И КАК это связано с БД?!? - person zerkms; 19.05.2012
comment
Если сообщения об ошибках регистрируются, они могут содержать строки подключения к БД или операторы SQL, запускаемые сценариями. - person Adam Culp; 19.05.2012
comment
и как 777 относится к нему? Допустим, я только что сделал один из своих каталогов 777 на tvfedor.ru (это мой проект для развлечения). Итак, что вы можете сделать? Что могут дать вам знания о том, что некоторые из каталогов - это 777? - person zerkms; 19.05.2012
comment
На самом деле зависит от общей среды. Я видел плохо настроенный виртуальный хостинг, где пользователи могут проходить по FTP и просматривать другие файлы/папки. 777 — не лучшая идея для виртуального хостинга. (Лучше быть в безопасности, чем потом сожалеть) - person Adam Culp; 19.05.2012
comment
Просмотрите свои журналы, проверьте учетные данные БД, подключитесь к БД, удалите все свои записи... в худшем случае. Или просмотрите ошибки своего приложения — идеальный источник для проверки различных попыток взлома и просмотра ответов. Журналы разработки НИКОГДА не должны публиковаться. - person Tomasz Struczyński; 19.05.2012
comment
@Adam Culp: вам лучше приложить свои последние мысли к ответу - они имеют больше смысла, чем текущая версия ответа. Потому что 777 и открытая для индексации - это просто разные не связанные между собой вещи - person zerkms; 19.05.2012
comment
@Tomasz, что, если я не даю разрешения на чтение и не храню учетные данные БД? - person Sebas; 19.05.2012
comment
Я не уверен, что вы сможете писать, не читая. (Я действительно не знаю, но какая польза от журнала, который вы не можете прочитать.) Я предполагаю, что наиболее конфиденциальной информацией будут учетные данные БД, в зависимости от того, какие файлы вы храните, но помните, что даже структура БД может быть как опасны, как полномочия в правильных руках. - person Adam Culp; 19.05.2012
comment
Я скачиваю логи и смотрю их на своем ПК; Я только что попробовал права 703, и это работает, я думаю, это лучше, чем 777 ... - person Sebas; 19.05.2012