Мне не нравится хранить ключи криптографического ключа и информацию о доступе к DB в документе documentroro, поэтому я использовал файлы SetEnv и php.ini Apache в conf.d, чтобы отделить их от кодовой базы. Большой вопрос: какой из них лучше? Внутренние переменные среды под файлами SetEnv SITEKEY 'oinkoink!' ( SetEnv SITEKEY 'oinkoink!' ) Или внутри файлов conf.d / xxx.ini ( db_pass="oink?" )? Может быть, что-то еще?
PROS n CONS:
SetEnv:
+ Хранится вне DOCUMENT_ROOT
+ Доступ только к данному объекту
-Visible with PHPINFO () – Хакеру нужен прямой доступ / загрузка эксплойта в файлы
get_cfg_var:
+ Хранится вне DOCUMENT_ROOT
+ Не отображается с помощью PHPINFO ()
– (ОЧЕНЬ ПЛОХО) Все включенные переменные ini включены, поэтому каждый vhost может запрашивать их через (ini_get_all), поэтому не может использоваться в общей среде vhost
Пока * .ini и SetEnv находятся за пределами корня веб-сайта (корень документа), это не имеет значения в любом случае. Просто выберите то, что вы предпочитаете. Мне нравится SetEnv, но это действительно личное предпочтение. Для меня имеет смысл использовать SetEnv, поскольку переменные помещаются в _SERVER . С .ini я думаю, что имеет смысл оставить его для настроек инициализации, характерных для того, как работает код.
Не хранить под корнем документа является хорошей идеей для предотвращения доступа к возможно защищенным данным.
Обратите внимание, что phpinfo() будет перечислять любые установленные переменные сервера, поэтому будьте очень осторожны.
Наконец, если вы включаете файлы, убедитесь, что вы не разрешаете бесплатное ../../ установленное пользователем, или у них будет доступ к потенциально защищенным файлам (даже включая /etc/passwd !).
Я думаю, что ваш главный вопрос: «Насколько безопасен». Ну, это, вероятно, настолько же безопасно, как и вы, без серьезных головных болей. PHP-код имеет доступ к этим переменным, поэтому, если вы распечатываете их, они легко видны, поэтому это зависит от того, насколько безопасна ваша база кода. Возможно, можно использовать LDAP с MySQL, но это звучит как огромная боль.
Общепринятой практикой является использование непубличных файлов магазина за пределами document_root. Типичный макет может быть следующим:
.../myProject .../myProject/documentRoot .../myProject/documentRoot/.... .../myProject/nonPublicFiles .../myProject/nonPublicFiles/...
Храните свой материал PHP в документеRoot и всех непубличных материалах в файлах nonPublicFiles . documentRoot будет Apache document_root из vHost. Поскольку nonPublicFiles находится снаружи, Apache не отвечает на запрос.
Восстановление защиты, SetEnv или * .ini имеют тенденцию быть эквивалентными: если кто-то получает права на выполнение произвольного PHP-кода, оба способа предоставляют разумную информацию этому коду.
Я бы предпочел метод SetEnv и * .ini , так как Apache не будет раскрывать эти данные самостоятельно. Требуется сценарий.
Misconfiguration может раскрывать содержимое nonPublicFiles даже без скрипта.
Если вы собираетесь использовать nonPublicFiles , подготовьте upfront скрипт, который проверяет, все ли настроено нормально и пересылает электронное письмо, если оно обнаруживает проблемы. Вероятно, назовите его с помощью CRON.
Я предпочитаю хранить их в непубличных папках, к которым можно получить доступ только через apache или за пределами document_root.