Выгодно ли переносить wp-config за пределы веб-корня?

135

Похоже, что одним из наиболее распространенных методов обеспечения безопасности в наши дни является перемещение на wp-config.phpодин каталог выше, чем корень документа vhost . Я никогда не нашел хорошего объяснения этому, но я предполагаю, что это сводит к минимуму риск того, что вредоносный или зараженный скрипт внутри рута прочитает пароль базы данных.

Но вы все равно должны разрешить WordPress доступ к нему, поэтому вам нужно расширить его, open_basedirчтобы включить каталог над корнем документа. Разве это не разрушает всю цель, а также потенциально подвергает злоумышленникам журналы сервера, резервные копии и т. Д.?

Или этот метод только пытается предотвратить ситуацию, при которой wp-config.phpлюбой http://example.com/wp-config.php, кто запрашивает , будет показан в виде простого текста , а не анализируется механизмом PHP? Это кажется очень редким явлением, и это не перевесит недостатки предоставления журналов / резервных копий / и т. Д. HTTP-запросам.

Может быть, можно переместить его за пределы корня документа в некоторых настройках хостинга, не раскрывая другие файлы, но не в других настройках?


Заключение. После долгих обсуждений по этому вопросу появились два ответа, которые, на мой взгляд, следует считать авторитетными. Аарон Адамс делает хороший аргумент в пользу переноса wp-config, и chrisguitarguy делает хороший аргумент против этого . Это два ответа, которые вы должны прочитать, если вы новичок в ветке и не хотите читать все целиком. Другие ответы либо излишни, либо неточны.

Ян Данн
источник
На самом деле нет необходимости включать ваш выбор ответов и отклонять все остальные ответы внутри вашего вопроса. Как вы можете видеть ниже, это то, для чего нужна система голосования stackexchange, чтобы голосовать за ответы, которые имеют смысл для людей, в то время как спрашивающие должны использовать механизм «принятого ответа» и ваши собственные голоса вверх / вниз.
Kzqai
6
Я не делаю этого для 99% вопросов, которые я задавал, но я подумал, что это уместно в данном конкретном случае. Есть 8 ответов на вопрос, некоторые из которых довольно длинны / сложны, а некоторые из них имеют много голосов, несмотря на то, что содержат неточную информацию или не добавляют ничего в разговор. Я думаю, что полуавторичное заключение полезно для людей, впервые читающих ветку. Как всегда, читатели могут составить собственное мнение; Я просто предлагаю свое мнение в качестве ОП.
Ян Данн
1
@Kzqai: «Система голосования stackexchange» является демократическим процессом, и участники часто 1) не понимают, что на самом деле просит или пытается решить ОП, и 2) не понимают обоснованность какого-либо конкретного ответа. После того, как ответы поступили и были поданы голоса, более чем полезно, чтобы ФП уточнил те ответы, которые предоставили помощь. В конце концов, OP - единственный, кто знает, и я хотел бы, чтобы больше OP сделали это. Да, люди «голосуют за ответы, которые имеют смысл для людей», но давайте позволим ОП сказать последнее слово относительно того, что имеет для него смысл.
Mac

Ответы:

127

Краткий ответ: да

Ответ на этот вопрос однозначно да , и сказать иначе совершенно безответственно .


Длинный ответ: пример из реальной жизни

Позвольте мне привести очень реальный пример с моего очень реального сервера, где перемещение wp-config.phpза пределы корневого веб-узла специально предотвращало захват его содержимого .

Баг:

Взгляните на это описание ошибки в Plesk (исправлено в 11.0.9 MU # 27):

Plesk сбрасывает переадресацию поддоменов после синхронизации подписки с планом хостинга (117199)

Звучит безобидно, верно?

Ну, вот что я сделал, чтобы вызвать эту ошибку:

  1. Настройте поддомен для перенаправления на другой URL (например, site.staging.server.comна site-staging.ssl.server.com).
  2. Изменен тарифный план подписки (например, конфигурация PHP).

Когда я сделал это, Plesk установил для субдомена значения по умолчанию: обслуживание содержимого ~/httpdocs/без активных интерпретаторов (например, PHP).

И я не заметил. Неделями.

Результат:

  • В wp-config.phpвеб-корне запрос на /wp-config.phpзагрузку файла конфигурации WordPress.
  • За wp-config.phpпределами веб-рута появляется запрос на /wp-config.phpскачивание совершенно безвредного файла. Настоящий wp-config.phpфайл не может быть загружен.

Таким образом, очевидно, что перемещение wp-config.phpза пределы корневого веб-узла имеет реальные преимущества в плане безопасности в реальном мире .


Как перейти wp-config.phpв любое место на вашем сервере

WordPress автоматически найдет один файл над вашей установкой WordPress для вашего wp-config.phpфайла, так что если вы его переместили, все готово!

Но что, если вы переместили его куда-нибудь еще? Легко. Создайте новый wp-config.phpв каталоге WordPress с помощью следующего кода:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Обязательно измените указанный выше путь к фактическому пути вашего перемещенного wp-config.phpфайла.)

Если вы столкнулись с проблемой open_basedir, просто добавьте новый путь к open_basedirдирективе в вашей конфигурации PHP:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

Это оно!


Разбирая аргументы в обратном

Каждый аргумент против wp-config.phpвыхода за пределы корня сети основывается на ложных предположениях.

Аргумент 1: если PHP отключен, он уже

Единственный способ, которым кто-то увидит, что содержимое [ wp-config.php] - это если они обойдут ваш сервер PHP-интерпретатором ... Если это произойдет, у вас уже есть проблемы: у них есть прямой доступ к вашему серверу.

ЛОЖЬ : сценарий, который я описал выше, является результатом неправильной конфигурации, а не вторжения.

Аргумент 2: Случайное отключение PHP является редким и, следовательно, незначительным

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

ЛОЖЬ : сценарий, который я описал выше, является результатом ошибки в общей части серверного программного обеспечения, влияющей на общую конфигурацию сервера. Это вряд ли «редко» (и, кроме того, безопасность означает беспокойство по поводу редкого сценария).

WTF : смена пароля после вторжения вряд ли поможет, если во время вторжения была обнаружена конфиденциальная информация. Действительно, мы все еще думаем, что WordPress используется только для случайных блогов, а злоумышленники заинтересованы только в порчи? Давайте позаботимся о том, чтобы защитить наш сервер, а не просто восстановить его после того, как кто-нибудь войдет.

Аргумент 3: Отказ в доступе wp-config.phpдостаточно хорош

Вы можете ограничить доступ к файлу через конфигурацию вашего виртуального хоста или .htaccess- эффективно ограничить внешний доступ к файлу таким же образом, как это делает перемещение за пределы корня документа.

FALSE : Представьте , что ваш сервер по умолчанию для виртуального хоста являются: нет PHP, нет .htaccess, allow from all(вряд ли необычное в производственной среде). Если ваша конфигурация каким-то образом сбрасывается во время обычной операции - например, при обновлении панели - все вернется в состояние по умолчанию, и вы будете выставлены.

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

WTF : Почему кто-то специально рекомендует меньшее количество уровней безопасности? Дорогие машины не просто имеют замки; у них также есть сигнализация, иммобилайзеры и GPS-трекеры. Если что-то стоит защищать, делай это правильно.

Аргумент 4: Несанкционированный доступ wp-config.phpне имеет большого значения

Информация о базе данных действительно единственная конфиденциальная информация в [ wp-config.php].

ЛОЖЬ : ключи аутентификации и соли могут быть использованы при любом количестве возможных атак.

WTF : Даже если учетные данные базы данных были единственными wp-config.php, вы должны быть напуганы злоумышленником, который заполучит их.

Аргумент 5: перемещение wp-config.phpвне веб-корня фактически делает сервер менее безопасным

Вам все еще нужно разрешить WordPress доступ [ wp-config.php], поэтому вам нужно развернуть, open_basedirчтобы включить каталог над корнем документа.

ЛОЖЬ : Предположим, wp-config.phpчто в httpdocs/, просто переместите его ../phpdocs/, и установите, open_basedirчтобы включить только httpdocs/и phpdocs/. Например:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Не забудьте всегда указывать /tmp/или свой tmp/каталог пользователя , если он у вас есть.)


Вывод: файлы конфигурации всегда должны всегда находиться вне корневого веб-каталога.

Если вы заботитесь о безопасности, вы выйдете wp-config.phpза пределы своего веб-корня.

Аарон Адамс
источник
1
Если у вас есть ошибка в Apache, Linux или мозг администратора, вы в любом случае тост. В вашем сценарии вы не можете объяснить, почему более вероятна неправильная конфигурация в корне веб-сайта, чем в любом другом месте на сервере. Возможно, неправильно настроенный apache может получить доступ к /../config.php так же легко, как /config.php
Марк Каплун
1
Вы не "тост в любом случае". Это очень вероятно , и даже доказуемо , что ошибка приведет к корневой веб сбрасывается в состояние по умолчанию, в этом случае вы не «тост» - ваш wp-config.phpостается безопасным. И это невероятно - настолько, насколько это практически невозможно - ошибка может привести к тому, что корень сети будет произвольно сброшен в тот каталог, в который вы поместили свой wp-config.php.
Аарон Адамс
1
@IanDunn На самом деле, легко перейти wp-config.phpв произвольное место. Я добавил указания к своему ответу; это просто включает в себя создание фиктивной wp-config.phpв каталоге WordPress, ссылающейся на местоположение реальной.
Аарон Адамс
3
Этот ответ точный. У моей хостинговой компании был сбой массива дисков. Когда все было сказано и сделано, они восстановили систему ЧАСТИЧНО. Оказывается, они использовали серию сценариев cPanel / WHM для восстановления файлов httpd.conf, которые делали это неправильно. К счастью, у меня уже был wp-config.php за пределами корня документа, но если бы у меня не было его содержимого, его можно было взять. Да, редко, но, как уже отмечалось, о редких случаях нужно беспокоиться. Кроме того, указание на то, что «простодушные люди будут потеряны», является плохим оправданием для МЕНЬШЕЙ безопасности.
Ланс Кливленд
1
Это хороший момент, Аарон. Я все еще немного скептически отношусь к причинам, которые я упомянул в этой и других ветках комментариев, но вы убедили меня, что в этом есть больше достоинств, чем я думал. По крайней мере, если все сделано правильно, я не думаю, что это повредит. У меня все еще есть проблема с тем фактом, что большинство людей, продвигающих его, кажется, не понимают причин этого, и способ, которым они учат этому, часто приводил к раскрытию каталога над httpdocs, но вы помогли решить эти проблемы в ваш ответ.
Ян Данн
40

Самое главное, что он wp-config.phpсодержит некоторую конфиденциальную информацию: имя пользователя / пароль вашей базы данных и т. Д.

Итак, идея: переместить его за пределы корня документа, и вам не о чем беспокоиться. Злоумышленник никогда не сможет получить доступ к этому файлу из внешнего источника.

Но вот в чем проблема: на wp-config.phpсамом деле ничего не выводится на экран. Он определяет только различные константы, которые используются в вашей установке WP. Таким образом, единственный способ увидеть содержимое этого файла - это обойти интерпретатор PHP вашего сервера - он может .phpотобразить файл как простой текст. Если это произойдет, у вас уже есть проблемы: у них есть прямой доступ к вашему серверу (и, возможно, права суперпользователя) и они могут делать все, что захотят.

Я собираюсь пойти дальше и сказать, что нет смысла выходить wp-configза пределы корня документа с точки зрения безопасности - по причинам, указанным выше, а именно:

  1. Вы можете ограничить доступ к файлу через конфигурацию вашего виртуального хоста или .htaccess - эффективно ограничивая внешний доступ к файлу так же, как если бы перемещение вне корня документа
  2. Вы можете обеспечить строгое разрешение доступа к файлу, wp-configчтобы предотвратить чтение файла любым пользователем без достаточных привилегий, даже если он получает (ограниченный) доступ к вашему серверу через SSH.
  3. Ваша конфиденциальная информация, настройки базы данных, используются только на одном сайте. Таким образом, даже если злоумышленник получит доступ к этой информации, единственным сайтом, на который он повлияет, будет установка WordPress, к которой wp-config.phpпринадлежит файл. Что еще более важно, у этого пользователя базы данных есть только права на чтение и запись в базу данных этой установки WP, и ничто иное - нет доступа для предоставления разрешений другим пользователям. То есть, другими словами, если злоумышленник получит доступ к вашей базе данных, это просто вопрос восстановления из резервной копии (см. Пункт 4) и изменения пользователя базы данных.
  4. Вы резервное копирование часто. Часто это относительный термин: если вы публикуете 20 статей каждый день, лучше делать резервные копии каждый день или каждые несколько дней. Если вы публикуете сообщения раз в неделю, то резервного копирования один раз в неделю вполне достаточно.
  5. Ваш сайт находится под контролем версий ( как этот ), что означает, что даже если злоумышленник получил доступ, вы можете легко обнаружить изменения кода и откатить их. Если у злоумышленника есть доступ wp-config, он, вероятно, перепутал что-то еще.
  6. Информация о базе данных - действительно единственная важная вещь wp-config, и, поскольку вы осторожны с ней (см. Пункты 3 и 4), это не так уж сложно. Соли и тому подобное можно менять в любое время. Единственное, что происходит, это то, что он делает недействительными зарегистрированные файлы cookie пользователей.

Мне кажется, что wp-configвыход из документа пахнет безопасностью из-за неясности - а это очень соломенный человек.

chrisguitarguy
источник
2
Да, это в значительной степени то, что я думал. Я рад знать, что я не единственный :) Я хотел бы оставить вопрос открытым на один или два дня, на случай, если у кого-то есть веский контраргумент, но пока это кажется правильным ответом меня.
Ян Данн
3
Незначительное исправление: нет никакого преимущества для безопасности при перемещении файла wp-config.php из корня документа. Существуют и другие преимущества, которые не связаны с безопасностью и применяются только к необычным установкам.
Отто
4
Просто чтобы развенчать возможный миф - разве это не возможно, что-то может пойти не так на стороне сервера - в каком случае код php выводится на экран?
Стивен Харрис
3
@IanDunn Но лучшие ответы рекомендуют полностью вывести ее из этой иерархии в отдельную, что решит вашу проблему с журналами и т. Д. Этот ответ не отвечает на ваш вопрос: «движется ... действительно полезно», он просто говорит другие меры безопасности полезны и пытаются убедить вас не беспокоиться о безопасности. Все думают, что их дом в безопасности, пока они не будут ограблены. После этого они делают лучшую работу. Некоторые люди никогда не будут ограблены, даже если их безопасность низкая, но это не значит, что это плохой совет.
AndrewC
4
Это хорошие моменты, но моя самая большая проблема в том, что это корректирующие аргументы, а не профилактические аргументы. Большинство из них говорят о том, что это не так уж и сложно, потому что А) вы предполагаете, что кто-то правильно обращался с пользователем БД, и Б) у вас есть резервные копии. Что происходит, когда вы используете что-то вроде woocommerce или храните конфиденциальную информацию в своей базе данных? Тогда ты облажался.
Goldentoa11
25

Я думаю, что Макс это хорошо осведомленный ответ, и это одна из сторон истории. WordPress Кодекс имеет больше советуют :

Кроме того, убедитесь, что только вы (и веб-сервер) можете прочитать этот файл (это обычно означает разрешение 400 или 440).

Если вы используете сервер с .htaccess, вы можете поместить его в этот файл (в самом верху), чтобы запретить доступ любому, кто его просматривает:

<files wp-config.php>
order allow,deny
deny from all
</files>

Обратите внимание, что установка разрешения 400 или 440 для wp-config.php может помешать плагинам записывать или изменять его. В качестве примера можно привести плагины для кэширования (W3 Total Cache, WP Super Cache и т. Д.). В этом случае я бы выбрал 600 (разрешение по умолчанию для файлов в /home/userкаталоге).

это я
источник
5
Макс это ответ. +1 к нему. Я просто пытаюсь продлить это.
its_me
1
Ахан Криш, ты попал в яблочко. Спасибо за добавление.
Макс Юдин
Так что если вы используете htaccess для отклонения HTTP-запросов к wp-config.php, разве это не приведет к тому же результату, что и перемещение его за пределы корня документа, но без предоставления журналов / резервных копий / и т. Д.?
Ян Данн
4
@IanDunn Зависит от того, что является корнем документа - (1) Если WordPress размещается в каталоге public_html, перемещение wp-config.phpвне каталога означает, что он будет находиться в public_htmlкаталоге. В этом случае вам придется использовать правила htaccess, чтобы запретить HTTP-запросы к wp-config.php. (2) Если WordPress установлен непосредственно в public_htmlкаталоге, на один уровень выше>> вы будете перемещать его в /home/userкаталог. В этом случае вы в полной безопасности, так как файл находится за пределами корня документа. Вы все еще можете установить права доступа к файлу 600 (или даже более строгие 440 или 400).
its_me
@IanDunn Как я уже сказал, это мое базовое понимание, и я не эксперт по безопасности. :)
its_me
17

Кто-то попросил нас войти, и я отвечу здесь.

Да, есть преимущества безопасности от изоляции вашего wp-config.php от корневого каталога вашего сайта.

1- Если ваш обработчик PHP будет сломан или изменен каким-либо образом, информация о вашей БД не будет раскрыта. И да, я видел это несколько раз на общих хостах во время обновления сервера. Да, сайт будет взломан в течение этого периода, но ваши пароли не будут повреждены.

2. Лучшие практики всегда рекомендуют изолировать файлы конфигурации от файлов данных. Да, это трудно сделать с помощью WordPress (или любого веб-приложения), но его перемещение немного изолирует.

3. Помните об уязвимости PHP-CGI, когда любой может передать? -S в файл и просмотреть исходный код. http://www.kb.cert.org/vuls/id/520827

В конце концов, это мелкие детали, но они помогают минимизировать риск. Особенно, если вы находитесь в общей среде, где любой может получить доступ к вашей базе данных (все, что им нужно - это пользователь / пароль).

Но не позволяйте небольшим отвлекающим факторам (преждевременной оптимизации) оказаться перед тем, что действительно необходимо для обеспечения безопасности сайта:

1- держать его всегда в курсе

2- Используйте надежные пароли

3- Ограничить доступ (через разрешения). У нас есть пост об этом здесь:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

Спасибо,

Sucuri
источник
Привет, ребята, спасибо за добавление ваших мыслей. Я думаю, что мы уже затрагиваем большинство из этих пунктов в других ответах и ​​их комментариях. 1) Да, это возможно, но редко; 2) Да, это имеет свои преимущества, но они минимальны; 3) Да, это возможно, но такая уязвимость вряд ли повторится, и защита от нее подобна игре в прятки или заставляет людей снимать обувь в аэропортах, потому что какой-то осел спрятал бомбу в своем ботинок один раз. Это реакционно и вряд ли принесет пользу в будущем.
Ян Данн
В различных дискуссиях вопрос был уточнен с "Есть ли какие-либо преимущества?" на "Хорошо, есть некоторые преимущества, но перевешивают ли они риски?" Основной риск, на который я ссылаюсь, это то, что вам нужно расширить область действия openbase_dir, чтобы позволить PHP получать доступ к сценариям вне корневого веб-каталога. Многие настройки хостинга, в том числе те, которые используют Plesk, а это очень много, хранят журналы, резервные копии, частные области FTP, которые должны быть изолированы от веб-корня, и т. Д. В каталоге над веб-корнем. Таким образом, предоставление PHP доступа к этому каталогу может быть серьезной уязвимостью.
Ян Данн
15

Определенно да.

Когда вы перемещаете wp-config.php за пределы общедоступного каталога, вы защищаете его от чтения с помощью браузера, когда злонамеренный (или случайно!) Обработчик php изменяется.

Считывание логина / пароля вашей БД возможно, если сервер практически не заражен по вине хромого администратора. Начислите штраф на администратора и получите более надежный и надежный сервер. Хотя это может быть дороже.

Макс Юдин
источник
4
Если у злоумышленника достаточно прав для изменения обработчика PHP, вы уже облажались. Случайные изменения очень редки в моем опыте, и в этом случае было бы легко изменить пароль. В свете этих вещей, вы все еще думаете, что риск раскрытия журналов / резервных копий / и т. Д. Из-за расширенной open_basedirобласти действия стоит ?
Ян Данн
1
У меня никогда не было -rwxдоступа к каталогам выше, чем public_htmlя никогда не был знаком с open_basedir. Мои журналы находятся в отдельном каталоге, поэтому резервные копии делают. Я думаю, что это то, что есть у всех общих хостов.
Макс Юдин
Хозяева сильно различаются; нет стандартной структуры каталогов. Plesk (одна из самых популярных панелей управления для общих хостов) помещает журналы в /var/www/vhosts/example.com/statistics/logs, а корнем документа является /var/www/vhosts/example.com/httpdocs. Перемещение wp-config.php в /var/www/vhosts/example.com/wp-config.php потребует предоставления сценариям доступа ко всему каталогу example.com.
Ян Данн
Просто из любопытства, где хранятся ваши журналы и резервные копии, если не в каталоге домена? Доступ к ним осуществляется через панель управления или что-то еще?
Ян Данн
1
Да, через панель управления.
Макс Юдин
8

Я просто хочу пояснить, ради аргумента, что перемещение вашего файла wp_config.php не обязательно означает, что вы должны переместить его только в родительский каталог. Допустим, у вас есть структура, подобная / root / html, где html содержит установку WP и весь ваш HTML-контент. Вместо того, чтобы перемещать wp_config.php в / root, вы можете переместить его в нечто вроде / root / secure ..., которое находится как вне каталога html, так и вне корневого каталога сервера. Конечно, вам нужно убедиться, что php может работать и в этой защищенной папке.

Поскольку WP не может быть настроен для поиска wp_config.php в папке одного уровня, например / root / secure, вы должны сделать дополнительный шаг. Я оставил файл wp_config.php в / root / html и вырезал важные части (логин базы данных, соль, префикс таблицы) и переместил их в отдельный файл с именем config.php. Затем вы добавляете команду PHP includeв ваш wp_config.php, например так:include('/home/content/path/to/root/secure/config.php');

Это по сути то, что я сделал в моей настройке. Теперь, основываясь на вышеупомянутом обсуждении, я все еще оцениваю, нужна ли это или даже хорошая идея. Но я просто хотел добавить, что приведенная выше конфигурация возможна. Он не отображает ваши резервные копии и другие корневые файлы, и пока защищенная папка не настроена с собственным общедоступным URL-адресом, она не просматривается.

Кроме того, вы можете ограничить доступ к защищенной папке, создав там файл .htaccess с помощью:

order deny,allow
deny from all
allow from 127.0.0.1
Майкл
источник
Привет, Майкл, спасибо, что поделился этим. Вы пробовали это в реальной среде, чтобы убедиться, что это работает? Я думаю , что open_basedirдиректива принимает все дерево , поэтому для того , чтобы получить доступ /root/secureс /root/html, вы должны установить open_basedirв /root.
Ян Данн
Чтобы ваша идея работала, я думаю, вам нужно настроить структуру каталогов, например /root/httpdocs/config/accessible, где httpdocsхранятся журналы, резервные копии и т. Д .; configдержит wp-config.phpи accessibleдержит WordPress и весь контент. Вам нужно изменить конфигурацию vhost и т. Д., Чтобы переназначить корень документа accessible. Я не вижу никакой выгоды по сравнению с отказом от HTTP-запросов к wp-config в настройках по умолчанию.
Ян Данн
1
Согласно php.net/manual/en/ini.core.php#ini.open-basedir : «В Windows разделите каталоги точкой с запятой. Во всех других системах разделите каталоги двоеточием. Как модуль Apache, Пути open_basedir из родительских каталогов теперь автоматически наследуются. " Таким образом, вы можете установить несколько каталогов, не нужно, чтобы они были в одном дереве.
Майкл
Я только что проверил это, и похоже, что ты прав. Я до сих пор не уверен, какое это имеет преимущество в безопасности по сравнению с простым отказом в доступе к файлу через Apache.
Ян Данн
@IanDunn хорошо ответил в ответе Аарона Адамса
AndrewC
4

Существует множество плохо написанных тем и плагинов, которые позволяют атакерам вводить код (вспомните проблему безопасности с Timthumb). Если я буду злоумышленником, зачем мне искать wp-config.php? Просто введите этот код:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Вы можете попытаться скрыть свой wp-config.php. Пока WordPress делает всю важную информацию доступной для всех, скрывать wp-config.php бесполезно.

Плохая часть в wp-config.php не в том, что он содержит конфиденциальные данные. Плохая часть заключается в определении конфиденциальных данных как глобальной доступной константы.

Обновить

Я хочу прояснить проблемы define()и почему плохая идея - определять конфиденциальные данные как глобальную константу.

Есть много способов атаковать сайт. Внедрение скрипта - это только один из способов атаковать сайт.

Предполагая, что на сервере есть уязвимость, позволяющая злоумышленнику получить доступ к дампу памяти. Атакующий найдет в дампе памяти все значения всех переменных. Если вы определяете глобальную доступную константу, она должна оставаться в памяти до тех пор, пока скрипт не завершится. Создавая переменную вместо константы, есть большая вероятность, что сборщик мусора перезапишет (или освободит) память после того, как переменная больше не нужна.

Лучший способ защитить конфиденциальные данные - удалить их сразу после их использования:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

После использования конфиденциальных данных присвоение nullперезапишет данные в памяти. Злоумышленник должен получить дамп памяти как раз в тот момент, когда $db_conсодержит конфиденциальные данные. И это очень короткое время в приведенном выше примере (если класс Database_Handler не сохраняет его копию).

Ralf912
источник
Этот ответ не касается непосредственно вопроса. Любой автор плагина может провести полевой день с WordPress, если они убедят вас установить свой код и имеют злонамеренные намерения. Это ничем не отличается от добровольной установки вируса в вашей системе. Этот аргумент не перемещать wp-config.php не имеет смысла. Это все равно что сказать, что преднамеренная установка автомобильной бомбы в машину делает бесполезной настройку автомобильной сигнализации. Технически верно, но WTF?!?
Ланс Кливленд
2
Нет, это не бессмысленно. Вопрос заключается в следующем: можно ли защитить учетную запись базы данных, скрыв wp-config.php. И ответ очевиден: нет. Это так же, как если бы вы спросили: «Могу ли я защитить свою машину от автомобильных бомб с помощью автомобильной сигнализации?». Других преимуществ от скрытия вашей wp-конфигурации как защиты доступа к базе данных или доступа по ftp нет. Оба находятся в глобальном масштабе. Я уверен, что у злоумышленников есть больше способов получить доступ к глобальным переменным без внедрения кода.
Ralf912
Я не вижу «могу ли я защитить учетную запись базы данных, скрывая wp-config.php» в исходном вопросе. Первоначальный вопрос был «имеет ли смысл перемещать wp-config.php». Ответ абсолютно да, ИМО. Это все равно что спросить, нужно ли запирать входную дверь, когда вы выходите. Сказка «кто-то может легко разбить окно и войти в любом случае, так зачем беспокоиться» не отвечает основополагающему пункту вопроса. ИМО задал вопрос: «Стоит ли прилагать дополнительные усилия для перемещения wp-config.php? Да. По крайней мере, это не пускает ленивых хакеров.
Ланс Кливленд
2
Одна из самых распространенных рекомендаций по безопасности ... Вы пропустили очень (очень, очень) важный момент: чем интересен злоумышленник? И это не то, как вы стилизовали свой wp-config.php. Злоумышленник заинтересован в значениях, которые вы определили в своем wp-config. Захватите ваш пример с передней дверью: Скрытие вашего wp-config аналогично тому, как если бы вы заперли входную дверь, но хранили все свое золото без защиты в саду. Все значения, определенные в wp-config, определены глобально . Таким образом, они все доступны за пределами wp-config. Даже если вы скрываете свой wp-config, значения все еще присутствуют.
Ralf912
1
Я думаю, что те, кто выступает за его перемещение, пытаются защитить от сценариев, в которых wp-config.php может отображаться в виде простого текста через HTTP-запрос, а не от сценариев, где он может подвергаться воздействию другого кода PHP, выполняющегося на хосте.
Ян Данн
-1

Помимо преимуществ безопасности, он также позволяет вам держать ваш экземпляр WordPress под контролем версий, сохраняя при этом основные файлы WordPress как субмодуль / внешний. Вот как Марк Джакит настроил свой проект WordPress-Skeleton. См. Https://github.com/markjaquith/WordPress-Skeleton#assumptions для получения подробной информации.

Emzo
источник
8
Он настроен в корне документа, а не за его пределами, поэтому он не имеет отношения к этому вопросу. Техника, о которой задан вопрос, указывает, что вы перемещаете wp-config.phpодин каталог над корнем документа vhost , а не один каталог над установочной папкой WordPress. Весь смысл в том, чтобы вытащить его из папки, которую можно прочитать по HTTP-запросам.
Ян Данн