Comments 33
Как — то руки сразу зачесались и сами в google полезли сайты на WordPress искать :)
Но мы же порядочные все люди :)
Но мы же порядочные все люди :)
0
Все гениальное просто.
Эх, нужно было подождать ещё пару месяцев =D
Эх, нужно было подождать ещё пару месяцев =D
0
Вы ещё напишите чем именно брутили пароль, и возможно толпа скрипт-киддисов пробежится по wordpress-сайтам)
+1
Мои блоги и так каждый день фиксируют по несколько тысяч подборов, так что вряди-ли что что-то изменится. habrahabr.ru/post/188932/
0
wpscan.org/
Если-скрипт кидди сможет корректно развернуть окружение для него :)
Если-скрипт кидди сможет корректно развернуть окружение для него :)
+1
защита от подобного брутфорса уровня хостинга: habrahabr.ru/post/190112/
А вообще, если вы получили доступ к шаблону, вы можете выполнять даже php в шаблонах. Ничего не мешает логировать POST на форме логина, например.
А вообще, если вы получили доступ к шаблону, вы можете выполнять даже php в шаблонах. Ничего не мешает логировать POST на форме логина, например.
0
1. Сбрутил редактора.
2. Проводим XSS(условно говоря) и получилаем шелл/права админа.
В чем «небезопасность» из коробки, честно говоря, я не понял. Другие движки не брутятся? Брутятся. На других движках нельзя провести подобную атаку? Да на многих можно, зависит от того, как распределяются права и на что.
Для того, что бы защитить свой сайт от подобного — есть куча решений.
Редактора того гуглосервиса еще и с работы пнут за словарный пароль.
Это не камень в ваш огород, просто непонятен заголовок
2. Проводим XSS(условно говоря) и получилаем шелл/права админа.
В чем «небезопасность» из коробки, честно говоря, я не понял. Другие движки не брутятся? Брутятся. На других движках нельзя провести подобную атаку? Да на многих можно, зависит от того, как распределяются права и на что.
Для того, что бы защитить свой сайт от подобного — есть куча решений.
Редактора того гуглосервиса еще и с работы пнут за словарный пароль.
Это не камень в ваш огород, просто непонятен заголовок
+10
Мое мнение, что не должно быть права исполнения js от редактора (только администраторам). В примере в статье показано, как редактор (возможно, законный) может заполучить RCE. Почему администратор должен этого опасаться? Почему оставлена такая возможность пользователю, на уровень ниже? Открытые вопросы.
-2
Опенсурс бесплатный движок. В чистом виде его юзают под бложики, обычно, для более крупных проектов меняют под свои нужды, это не так уж и сложно. Не вижу ничего плохого в js для редактора, если у редактора есть голова, хороший пасс или авторизация по каким-нибудь vk api. Для пользователей, да, он не нужен, но админ сам решает кому что и как, тем более в таких дорогих проектах :)
Я, например, никогда не надеюсь на движок, всегда урезаю все права до минимума, который позволит выполнять свои функции.
Разрабам можно только посоветовать сделать более широкую кастомизацию через админку.
Я, например, никогда не надеюсь на движок, всегда урезаю все права до минимума, который позволит выполнять свои функции.
Разрабам можно только посоветовать сделать более широкую кастомизацию через админку.
0
Вставка Javasript через редактор — это серьёзная дыра.
+5
+1. Глупо обвинять WordPress если человек сам не прав. Нужно понимать, что именно редактор это основная роль в WordPress, а роль администратора должна использоваться только для административных задач — работа с плагинами, темами и т.д. А редактор должен иметь права на вставку всяких js, иначе как же AdSense, баннерные сети, твиттер виджеты, подписки на рассылки и всё остальное?
Опять же, при желании можно одной строчкой отключить нефильтрованный HTML, чего я советую всем, кто сталкивается с многопользовательскими блогами и сайтами, и с работой с людьми, которым они не доверяют.
Опять же, при желании можно одной строчкой отключить нефильтрованный HTML, чего я советую всем, кто сталкивается с многопользовательскими блогами и сайтами, и с работой с людьми, которым они не доверяют.
+1
Здесь действительно разные взгляды на ситуацию, в статье рассматривается именно со стороны «безопасника».
Ваши доводы верны в плане функциональности и юзабилити, но мы же рассматриваем ситуацию с другой стороны (стороны безопасности). Когда даны определенные права человеку и он не должен иметь скрытой технической возможности их повысить (privilege escalation). Здесь же такая возможность имеется.
Другое дело, если бы он имел выполнить JS только на главной странице, и не имел доступа в админ панель.
Ваши доводы верны в плане функциональности и юзабилити, но мы же рассматриваем ситуацию с другой стороны (стороны безопасности). Когда даны определенные права человеку и он не должен иметь скрытой технической возможности их повысить (privilege escalation). Здесь же такая возможность имеется.
Другое дело, если бы он имел выполнить JS только на главной странице, и не имел доступа в админ панель.
0
Странно, мне это всегда казалось нормальным поведением.
Ты дал права на редактор человеку, если он безответственный (слабый пароль) или просто негодяй (внедрит код), это твои проблемы, а не редактора.
Если дать ключи незнакомцу и вас ограбят, разве это проблема слабого замка?
Ты дал права на редактор человеку, если он безответственный (слабый пароль) или просто негодяй (внедрит код), это твои проблемы, а не редактора.
Если дать ключи незнакомцу и вас ограбят, разве это проблема слабого замка?
+6
Если дать ключи знакомому от сарая/веранды — то это ваша проблема. Если через сарай/веранду попасть в дом очень легко — то, ИМХО, это проблема архитектуры дома.
0
Именно поэтому когда я даю доступ редактору (или сдаем сайт заказчику) — генерирую сложный пароль и сообщаю о важности его не менять или как минимум учесть сложность пароли при его изменении. Все-таки ответственность на главном админе будет всегда за весь ресурс.
Проблема: Неопытные админы и редакторы — получаем RCE с правами редактора. И еще о Google, стартапе и 1 миллиарде долларов
Проблема: Неопытные админы и редакторы — получаем RCE с правами редактора. И еще о Google, стартапе и 1 миллиарде долларов
+2
Нормальным поведением казалось, что пользователь может получить админские права?
0
Да, ведь если вы дали ему ключи от дома, он может зайти, взять ваше ружье и пристрелить вас.
0
Это же и исправить довольно легко, вешаешь esc_js на фильтр контента поста и все, вопрос в том почему это еще не сделано по умолчанию…
0
А еще можно подобрать пароль админа, и тогда прямой доступ к админке..
+1
Уязвимость тут не в WordPress, а здесь: «Администраторы блогов выдают права редакторов своим PR-службам…» — они бы им ещё сразу SSH давали. А если и давать права администратора или редактора посторонним лицам, то нужно просто отключить нефильтрованный HTML для всех, как это сделано на WordPress.com и во многих других сетях:
define( 'DISALLOW_UNFILTERED_HTML', true );
+1
Что это за «нефильтрованный HTML»?
0
В WordPress используется KSES для обработки содержимого записей, страниц, виджетов и прочее: codex.wordpress.org/Function_Reference/wp_kses
Это позволяет указывать какими именно тегами и аттрибутами HTML можно пользоваться, а какие должны вырезаться при сохранении контента — это и есть фильтрация HTML и для некоторых ролей (администратору и редактору по умолчанию) подобная фильтрация отключена, чтобы пользователи могли вставлять свои js снипеты, iframe'ы и прочее.
Директивой DISALLOW_UNFILTERED_HTML в файле конфигурации wp-config.php можно включить фильтрацию HTML для всех ролей.
Это позволяет указывать какими именно тегами и аттрибутами HTML можно пользоваться, а какие должны вырезаться при сохранении контента — это и есть фильтрация HTML и для некоторых ролей (администратору и редактору по умолчанию) подобная фильтрация отключена, чтобы пользователи могли вставлять свои js снипеты, iframe'ы и прочее.
Директивой DISALLOW_UNFILTERED_HTML в файле конфигурации wp-config.php можно включить фильтрацию HTML для всех ролей.
0
Sign up to leave a comment.
WordPress: небезопасен из коробки — получаем RCE с правами редактора. И еще о Google, стартапе и 1 миллиарде долларов