Евгений Борисов

В Joomla так же есть CSRF. И для сплоита под CVE-2016-8869 + CVE-2016-8870 это не стало проблемой.

Начинает подбешивать твоя упертость в своей правоте. Кури скрипт с двумя различными техниками брута строки fD3_
Результат работы ошеломляет

Full string: fD3_ => 1622943
By char: fD3_ => 155

И прекрати уже наконец людей вводить в заблуждения. Попахивает моветоном

Ты путаешь божий дар с яичницей. Полный перебор пароля для некоего хеша и полный посимвольный перебор строки.
$str = '123';
md5($str) = 202cb962ac59075b964b07152d234b70
Т.е. чтобы подобрать пароль 123, тебе нужно перебрать все возможные комбинации символов и букв. Поскольку тебе нужно целиком строчку подбирать, а не посимвольно.

С префиксом ситуация другая. Тебе нужно перебирать не всю строку сразу, а по отдельности каждый символ. Слепая SQL-injection на этом и основана, что берется 2 запроса к сайту. Которые приводят к разному выводу. Таким образом, берем некий символ из набора. И подставляем его в запрос. Если запрос отвечает 1 выводом. То символ выбран не верно. Если отвечает вторым выводом — то символ выборан верно и мы берем пробуем подобрать следующий символ неизвестной строки.
Таким образом, тут длина строки и разные регистры лишь ненамного увеличивают время перебора.

Раз уж ты любишь формулы и наглядые примеры, то дано:
Набор символов: 1234567890
Перебор хеша пароля из 3 символов: 3^10 = 59049 комбинаций
Посимвольный перебор строки из 3 символов: 10*3 = 30

Чуешь разницу? Если бы от твоего префикса генерировался некий хеш, то да. Для брута это бы существенно усложнило задачу. В твоем же случае sdfWE234s_wefSDf_ (цифры + буквы +буквы в верхнем регистре + символ _) = 63 символа. Это максимум 1071 запрос к серверу. Как думаешь, 1071 запрос может сервер обработать за 30 секунд? А если запросы еще слать параллельно, а не последовательно?

Жень, скажи честно — вот на modx.pro сейчас есть теоретическая возможность взлома через подобные лазейки?

Теоретически — да.

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

Ниже ответил как я работаю.

А Евгению Борисову вряд ли интересно этим заниматься.

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

Поэтому в Revo я проверяю только самопис. А его в большинстве случаев ооочень мало. Поэтому чтобы из-за копеек не брать на себя ответственность я стараюсь обходить аудит revo стороной. Боле того, есть псевдозаказчики, которые хотят получить в отчете по аудиту все. Начиная от способов устранения, до способов взлома. В конечном счете начинают сами своим клиентам предлагать доп.услугу — аудит безопасности сайтов modx revo.

Поэтому мониторю и исправляю уязвимости только на тех проектах, которые находятся у меня в полной поддержке. Т.е. не разово платят за аудит, а ежемесячно, чтобы я мониторил состояние. Фиксил баги и оперативно удалял вирусы если вдруг они залезли, например, через ФТП. А эту услугу заказывают уже конечные клиенты, а не посредники. И то, только те, которые понимают что заказывают.
В общем если есть вопросы — обращайтесь через почту на modx@agel-nash.ru

Мне это не интересно.

Или это все та же песня о том, что разработчики (дополнений) сами не фильтруют входные данные и открывают дыры XSS/SQL?

XSS
Да. Тут XSS делится на 2 вида. XSS для внедрения JS кода. И XSS для внедрения MODX тегов. Многие разработчики не чувствуют разницу. Поэтому если и фильтруют, то по старинке через htmlspecialchars, а этого недостаточно, чтобы обезопаситься от внердения MODX тегов.
Если же начинать думать глобально. То рождаются костыли (на данный момент такая практика считается нормой — но на мой взгляд, эта норма граничит с дебилизмом)

А еще, если в запросе будет передано [[*id]], то modx вырежет это из текста. Если помните, был такой баг, когда передавали что-то в стиле [[[[[[[[[[[[[[[[*id]], чтобы получить [[*id]] и обойти встроенную фильтрацию. Пофиксили. Но сейчас есть еще один способ, но из-за множества условий, работает он далеко не везде. И тем не менее, вы уверены, что на вашем сайте новый способ не сработает?

Лично меня такая гибкость CMS не устраивает с огромным количеством оговорок не устраивает. Поэтому и использую MODX исключительно для визиток, где можно обойтись без этих хаков.

SQL
О том, что xPDO позиционируется как удобная прослойка между стулом и pdo. Но если pdo через плейсхолдеры подставляет данные и обрабатывает их. То xPDO иногда этим жертвует, чтобы пользователю дать синтаксический сахар. В итоге получаем конфуз, т.к. SQL запрос в xPDO иногда собирается конкатенацией строк, а не средствами pdo с обработкой.

Таким образом, программист пишет код думая, что данные будут сами обработаны в соответствии с моделями/схемами. Но они далеко не всегда обрабатываются. А если обрабатывать данные руками, то лично я не вижу разницы между xPDO и нативным pdo. Более того, xPDO мне только все усложняет заставляя делать еще какую-то не нужную работу.

Да были же уже взломы. И чхали они на них. Сейчас вот modxcloud раздает информацию о первых 9 пользователях удовлетворящих запросу. Всего 21168 пользователь. И это только с криво сформированным запросом (никакой SQL-injection и попыток взлома — просто кривой запрос). И это только на этапе регистрации… А что там еще в ЛК твориться — страшно представить.

Сергей, токены отчасти усложнят задачу. Но не решают ее. Грузится страница, берется токен. Затем этот токен и кукиусы подставляются в следующий запрос к уязвимому сценарию.

Господи, как же ты смешон. Последний раз я подобный бред нес лет в 14, когда в автобусе пытался объяснить однокласснику почему пользоватлей *win взламывают чаще, чем *nix. Не поверишь, до сих пор эту историю вспоминаю со стыдом. Моя позици была жестка и не поколибима — прям как у тебя сейчас.
*win — там окошечки. И окошечки можно мышкой перетаскивать. Поэтому нужно контролировать каждый пиксель
*nix — все в терминале. Он текстовый. Поэтому контролировать мы должны только все печатные символы.
Вывод: печатных символов меньше чем пикселей на экране. Поэтому *nix взломать проще.

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

просто закрыл доступ к /core/ /connectors/ и /manager/ там где можно

Это проблему не решает. Есть куча точек в хода из различных компонентов, которые оставляют коннекторы в /assets/components/

В общем печалька. Решения нет. Я думаю даже в ближайшем будущем не будет — все сведется к тому, что данные нужно фильтровать заранее. Так, как это делают до сих пор в MODX Evo. Так что получается, что xPDO далеко не PDO, а псведо-pdo с частичной обработкой входных данных + куча костылей.

Я тоже бы хотел узнать. Вдруг чего-то новое))

Это фишка xPDO.

Тогда расходимся. Безопасность на высоте.

Обходится эта проверка на раз

var_dump([
        isValidClause("SELECT 1 UNION SELECT IF(ORD(SUBSTRING(TABLE_SCHEMA,0,1)) = 0,1,9999999) FROM information_schema.TABLES WHERE TABLE_NAME LIKE '%users' LIMIT 0,1)"),
        isValidClause("SELECT 1 UNION/**/SELECT IF(ORD(SUBSTRING(TABLE_SCHEMA,0,1)) = 0,1,9999999) FROM information_schema.TABLES WHERE TABLE_NAME LIKE '%users' LIMIT 0,1)")
 ]);

P.S.: Писать на Laravel приятно. Но куда девать любовь к MODX?

Сюда. Я это использую для того, чтобы манагер мог в любое место контента вставить галлерею или несколько. Форму обратной связи/подбора тура.

<?php $content = isset($content) ? Modx::mergeSnippets($content) : ''; ?>
@if( ! empty($content))
    <div class="contacts-form text-content" itemprop="articleBody">
        {!!  $content !!}
    </div>
@endif

Как пример https://premier-tur.com/sanitariums/abzakovo — страница объекта с несколькими каруселями и формой в произвольных местах. В итоге MODX теги обрабатываются не везде, а только там, где это нужно.

MODX Evo только для визиток. Но планирую переходить на OctoberCMS. Эта CMS основана на базе Laravel. Один из разработчиков русский парень. Продуманная схема монетизации. Один из крупных русских проектов сделан на этом движке — www.alfa-forex.ru (дочка альфа-банка).

С шаблонными интернет-магазинами я не работаю, поэтому тут посоветовать ничего не могу. Ну а вообще Laravel — для всех остальных проектов сложнее визитки.

Хорошо, поверю тебе на слово, что можно в непроцедурный SQL воткнуть какую-то процедуру, чтобы весь перебор прошел на стороне сервера.

))))))))) Ок. Пусть это так теперь называется))))

Это фишка xPDO.

Тогда расходимся. Безопасность на высоте.

А на чём? Ларавел?

Каждый выбирает сам. Свой путь я выбрал. Тему MODX мониторю просто чтобы не выпадать из тренда, но уже не принимаю никаких действий как разработчик.

Спокойно спать можно если не делать сайты на MODX)). По сабжу — не юзать phpthumb, не юзать getObject без валидации данных, не пускать в адинку, экранировать modx теги, и бла-бла-бла…

пошел, сломал, написал.

Проходили. Даже последствия обсуждали. Спасибо, но пусть я лучше для тебе останусь теоретиком.

Есть или была? Я проверял все процессоры на работу с файлами, они защищены. Но может что-то проморгал.

Есть. Ищи в phpthumb