Обзор уязвимостей
- Если WordPress скопирован на сервер, но ещё не установлен, злоумышленник может завершить установку, указав координаты своего собственного MySQL-сервера. Затем, имея полный контроль над сайтом и базой данных, он может вставить вредоносный код в шаблоны темы или в содержимое записей.
- Во время установки WordPress злоумышленник может ввести JavaScript-код в поля «Имя базы данных», «Сервер базы данных» и «Имя пользователя». После нажатия кнопки «Отправить» браузер выполнит этот код.
- Во время установки WordPress злоумышленник может опустить параметр «Имя базы данных» и попытаться методом полного перебора подобрать имя пользователя и пароль к MySQL-серверу.
Ответ разработчиков
Поскольку речь идёт о скрипте установки, разработчики пришли к выводу, что вероятность атаки с использованием данных уязвимостей слишком мала:
«В процессе установки мы стремимся обеспечить пользователям хороший опыт взаимодействия с продуктом. Вряд ли кто-то задастся целью установить WordPress и при этом не завершит установку в краткий срок. Промежуток времени, в течение которого можно воспользоваться подобного рода уязвимостями, очень мал».
Однако хостинг-провайдерам, предлагающим в своих тарифных планах установку WordPress (даже если клиент не будет его использовать), стоит позаботиться о том, чтобы скрипт установки не был доступен извне.
Что можно предпринять
Официального исправления не будет. Однако администраторы серверов могут предотвратить эти проблемы с помощью надёжных паролей для MySQL и грамотной настройки межсетевого экрана для веб-приложений. В ModSecurity уже добавлены правила для исправления этих проблем.
Спасибо, Сергей.
Значит что нужно предпринять (чисто теоретически):
1. Каким-то образом запретить коннекты ВП к удалённой базе (как это сделать — я хз)
2. Включить поверку значений полей ввода для предотвращения выполнения JS. (Хотя как яваскрипт может помочь получить какие-то данные — я не вполне понимаю)
3. Заблокировать брут (тоже пока слабо представляю).
Естественно, все эти телодвижения гораздо более трудоёмкей, чем установка ВП или даже просто временная подмена индексного файла 🙂
Еще раз большое спасибо.
ЗЫ. А это никак не чинится? 😉
Модератор
Yuri
(@yube)
Чисто теоретически нужно через .htaccess запрещать доступ для всех, кроме себя, до окончания установки движка, а то и до окончания его настройки. Или прописывать доступ к базе в wp-config.php ручками. Или не устраивать длительных перекуров между нулевым шагом установки и первым.
Чисто теоретически нужно через .htaccess
Позволю добавить, что не только теоретически 🙂
нужно через .htaccess запрещать доступ для всех, кроме себя, до окончания установки движка,
Тож вариант. Но далеко не для всех приемлем — только если ИП статика. (а динамические телекомовские диапазоны что прописывай, что нет — толку как бэ мало 😉 )
Модератор
Yuri
(@yube)
Но далеко не для всех приемлем — только если ИП статика.
Установка занимает пару минут. Вряд ли айпишник будет меняться с такой дикой скоростью.
Неграмотность юзеров, — вот лучший вариант для взломщиков. Остальное признаки паранойи.
Установка занимает пару минут. Вряд ли айпишник будет меняться с такой дикой скоростью.
Дык я ж как бэ не спорю. Я о том, что если устанавливать не ВП не сразу после его заливки (а через день-неделю-месяц-полгода), то не всем и доступ по ИП может помочь.
А если сразу после заливки, то.. Вероятность, что злоумышленник вычислит и успеет установить ВП в свою базу стремится к нулю. А даже если и успеет — ещё нужно успеть залить шелл через ВП (влезть в базу и\или залогиниться в аминку и там произвести кучу действий). Даже если это всё не вручную делается, а на автомате — это время.. ВП-админ за это время легко сможет бахнуть вп-конфиг. И вообще очистить хостинг от всех файлов для пущей безопасности 😉
Модератор
Yuri
(@yube)
Если одминчег не понимает, что творит, то тут уже ничего не поможет.
У встречавшихся мне хостинг-провайдеров подключения к удалённым MySQL-серверам запрещены. Т.е. база должна быть на том же хостинге, что также снижает вероятность взлома.
У встречавшихся мне хостинг-провайдеров подключения к удалённым MySQL-серверам запрещены.
Как правило запрещено удалённое подключение к БД хостера. А вот насчёт К удалённым (чужим)… По моему таких запретов нет (или они не часто встречаются)
Тут же ситуация, когда БД злоумышленника на др хостинге с разрешёнными удалёнными коннектами.
Запрещены на стороне PHP, а не MySQL. Т.е. если ввести адрес MySQL-сервера на другом хостинге, выдаётся ошибка:
Warning: mysql_connect() [function.mysql-connect]: Host '...' is not allowed to connect to this MySQL server in wp-includes/wp-db.php on line 1017
Запрещены на стороне PHP, а не MySQL.
ааа. понятно, сеньк 🙂
АПД.
Хотя.. мне кацца в данном случае как раз удалённый хост не разрешает к нему коннектиться.
ПХП-клиенты же существуют и они совсем не обязательно должны располагаться на том же хостинге… Так что запрет «на уровне ПХП» на подключение к удалённой базе — хостеру должен быть безразличен, а если он и есть — ИМХО перебдёж хостера 😉
Впрочем, если разбираться, то надо в каждом конкретном случае, а по сабжевой «проблеме» это опять же нецелесообразно ;).
