Как стать автором
Обновить

Комментарии 33

Все гениальное просто.
Эх, нужно было подождать ещё пару месяцев =D
Вы ещё напишите чем именно брутили пароль, и возможно толпа скрипт-киддисов пробежится по wordpress-сайтам)
Мои блоги и так каждый день фиксируют по несколько тысяч подборов, так что вряди-ли что что-то изменится. habrahabr.ru/post/188932/
Опа, на мои оказывается тоже. Надо что-то делать))
Когда эта история началась мне заботливый хостер прислал рекомендацию запаролить wp-login.php =)
Я сам себе хостер, сервачок стоит на шкафу :)
Надо плагин найти, который ограничивает попытки логина. Пока времени нет этим заняться.
wpscan.org/
Если-скрипт кидди сможет корректно развернуть окружение для него :)
защита от подобного брутфорса уровня хостинга: habrahabr.ru/post/190112/

А вообще, если вы получили доступ к шаблону, вы можете выполнять даже php в шаблонах. Ничего не мешает логировать POST на форме логина, например.
В статье как раз рассматривается пример внедрения PHP кода в шабон.
Я понимаю. Я просто к тому, что не только в WP такое возможно.
1. Сбрутил редактора.
2. Проводим XSS(условно говоря) и получилаем шелл/права админа.
В чем «небезопасность» из коробки, честно говоря, я не понял. Другие движки не брутятся? Брутятся. На других движках нельзя провести подобную атаку? Да на многих можно, зависит от того, как распределяются права и на что.
Для того, что бы защитить свой сайт от подобного — есть куча решений.
Редактора того гуглосервиса еще и с работы пнут за словарный пароль.
Это не камень в ваш огород, просто непонятен заголовок
Мое мнение, что не должно быть права исполнения js от редактора (только администраторам). В примере в статье показано, как редактор (возможно, законный) может заполучить RCE. Почему администратор должен этого опасаться? Почему оставлена такая возможность пользователю, на уровень ниже? Открытые вопросы.
Опенсурс бесплатный движок. В чистом виде его юзают под бложики, обычно, для более крупных проектов меняют под свои нужды, это не так уж и сложно. Не вижу ничего плохого в js для редактора, если у редактора есть голова, хороший пасс или авторизация по каким-нибудь vk api. Для пользователей, да, он не нужен, но админ сам решает кому что и как, тем более в таких дорогих проектах :)
Я, например, никогда не надеюсь на движок, всегда урезаю все права до минимума, который позволит выполнять свои функции.
Разрабам можно только посоветовать сделать более широкую кастомизацию через админку.
Вставка Javasript через редактор — это серьёзная дыра.
+1. Глупо обвинять WordPress если человек сам не прав. Нужно понимать, что именно редактор это основная роль в WordPress, а роль администратора должна использоваться только для административных задач — работа с плагинами, темами и т.д. А редактор должен иметь права на вставку всяких js, иначе как же AdSense, баннерные сети, твиттер виджеты, подписки на рассылки и всё остальное?

Опять же, при желании можно одной строчкой отключить нефильтрованный HTML, чего я советую всем, кто сталкивается с многопользовательскими блогами и сайтами, и с работой с людьми, которым они не доверяют.
Здесь действительно разные взгляды на ситуацию, в статье рассматривается именно со стороны «безопасника».

Ваши доводы верны в плане функциональности и юзабилити, но мы же рассматриваем ситуацию с другой стороны (стороны безопасности). Когда даны определенные права человеку и он не должен иметь скрытой технической возможности их повысить (privilege escalation). Здесь же такая возможность имеется.

Другое дело, если бы он имел выполнить JS только на главной странице, и не имел доступа в админ панель.
Странно, мне это всегда казалось нормальным поведением.
Ты дал права на редактор человеку, если он безответственный (слабый пароль) или просто негодяй (внедрит код), это твои проблемы, а не редактора.
Если дать ключи незнакомцу и вас ограбят, разве это проблема слабого замка?
Если дать ключи знакомому от сарая/веранды — то это ваша проблема. Если через сарай/веранду попасть в дом очень легко — то, ИМХО, это проблема архитектуры дома.
Проблема архитектуры, это когда у вас балкон свисает до земли и в дом легко пролезть через него, а когда через гараж можно зайти в дом, давать ключи от гаража нужно только доверенному лицу. imho.
Именно поэтому когда я даю доступ редактору (или сдаем сайт заказчику) — генерирую сложный пароль и сообщаю о важности его не менять или как минимум учесть сложность пароли при его изменении. Все-таки ответственность на главном админе будет всегда за весь ресурс.

Проблема: Неопытные админы и редакторы — получаем RCE с правами редактора. И еще о Google, стартапе и 1 миллиарде долларов
Нормальным поведением казалось, что пользователь может получить админские права?
Да, ведь если вы дали ему ключи от дома, он может зайти, взять ваше ружье и пристрелить вас.
Вот только ружье хранится как положено в сейфе и закрыто на отдельный замок. Если ключ от дома позволяет открыть этот замок, то что-то не то с безопасностью.

Вообще как-то считал, что возможность эскалации привилегий одна из серьезнейших уязвимостей.
Но согласитесь и вы, если дать ключи от дома горничной, она может украсть ваши вещи и позвать сообщников со своими ружьями, чтобы прикончить вас.
Это же и исправить довольно легко, вешаешь esc_js на фильтр контента поста и все, вопрос в том почему это еще не сделано по умолчанию…
esc_js вешать не надо, достаточно отключить нефильтрованный HTML как я писал ниже. По умолчанию это не сделано, поскольку редакторы в своих статьях часто используют js код для баннеров, соц. кнопок, новостных рассылок, форм, опросов и для многого другого.
А еще можно подобрать пароль админа, и тогда прямой доступ к админке..
Уязвимость тут не в WordPress, а здесь: «Администраторы блогов выдают права редакторов своим PR-службам…» — они бы им ещё сразу SSH давали. А если и давать права администратора или редактора посторонним лицам, то нужно просто отключить нефильтрованный HTML для всех, как это сделано на WordPress.com и во многих других сетях:

define( 'DISALLOW_UNFILTERED_HTML', true );
Что это за «нефильтрованный HTML»?
В WordPress используется KSES для обработки содержимого записей, страниц, виджетов и прочее: codex.wordpress.org/Function_Reference/wp_kses

Это позволяет указывать какими именно тегами и аттрибутами HTML можно пользоваться, а какие должны вырезаться при сохранении контента — это и есть фильтрация HTML и для некоторых ролей (администратору и редактору по умолчанию) подобная фильтрация отключена, чтобы пользователи могли вставлять свои js снипеты, iframe'ы и прочее.

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

Публикации