В Moodle (https://moodle.org) (Modular Object-Oriented Dynamic Learning Environment), свободной модульной системе для организации дистанционного обучения, выявлена (http://netanelrub.in/2017/03/20/moodle-remote-code-execution/) критическая узявимость (https://moodle.org/mod/forum/discuss.php?d=349419) (CVE-2017-2641 (https://security-tracker.debian.org/tracker/CVE-2017-2641)), позволяющая осуществить подстановку SQL-кода и организовать выполнение произвольного PHP-кода на сервере. На основе Moodle построены обучающие системы многих известных университетов. В каталоге Moodle (https://moodle.net/sites/) зарегистрировано более 78 тысяч обучающих сайтов, в том числе 2160 в России, 655 - Украине, 151 - Беларуси и 116 - Казахстане.
В ветке Moodle 3.2 уязвимость могут эксплуатировать зарегистрированные пользователи через манипуляции с настройками профиля пользователя в web-интерфейсе. В более ранних выпусках атака возможна только через API для взаимодействия в web-сервисами при наличии соответствующих расширенных прав доступа. Уязвимость позволяет осуществить подстановку SQL-кода, которая может быть использована для получения привилегий администратора Moodle, после чего атакующий может загрузить свой плагин или шаблон и добиться выполнения произвольного PHP-кода. Уязвимость устранена в выпусках 3.2.2, 3.1.5, 3.0.9 и 2.7.19.URL: http://netanelrub.in/2017/03/20/moodle-remote-code-execution/
Новость: http://www.opennet.dev/opennews/art.shtml?num=46236
> критическая узявимость (CVE-2017-2641), позволяющая осуществить подстановку SQL-кода
> php... прошло 22 года с первого релиза похапе. В написанном на нём софте всё ещё находили детские уязвимости...
Будь мужиком, сделай достойную альтернативу без уязвимостей.
Давно уже сделали, это SQL с переменными связывания (bind variables). Но только честные bv, а не с последующим склеиванием всего запроса в плейн SQL как это не редко бывает.
Господи, ну что за страсть непременно строить велосипеды из костылей?Достаточно ограничить похапэ вызовами хранимых процедур, а любые прямые обращения к таблицам наглухо запретить. И все, проблема исчерпана. Но нет, ниасиляторы РСУБД начинают из гoвнa и веточек сооружать гoвнo, нафаршированое веточками...
Не достаточно.Во-первых, для пользования хранимками нужна хорошая СУБД умеющая нормально работать с курсорами и итераторами, да и вообще с хранимками. Какой-нибудь компаньён php в виде mysql не очень подходит.
Во-вторых, не каждый вид деятельности удобно засовывать в хранимки, например различные часто меняющиеся аналитические запросы. А что представимо более-менее стабильным простым API можно, конечно, засунуть в хранимки.
В-третих, разовый SQL запрос (это как раз что делает пых выше склеиванием запроса в текст) выполняется качественно не точно так же, как и prepared SQL запрос или запрос вызванный из хранимки. Есть нюансы работы планировщика запроса. Так, например, prepared запрос, или вызываемый из хранимки, пессимизируется. Это особенно плохо для больших аналитических запросов.
В-четвёртых, из хранимок тоже можно вызывать обычные текстовые запросы напарываясь на похожие грабли. Если заставить php'шника унести логику в хранимки, то проблемы просто переедут в хранимки.
> Для пользования хранимками нужна хорошая СУБД умеющая нормально работать с курсорами
> и итераторамиПочитайте на досуге К.Дж.Дейту. До просветления. Ну, или попейте капель для изгнания из организма кривых паттернов.
> Во-вторых, не каждый вид деятельности удобно засовывать в хранимки, например различные
> часто меняющиеся аналитические запросы.У кого вообще может хватить ума дать публичный доступ к базе для произвольных запросов? Сам в свою - сколько угодно, но когда это продукт для других - за такое надо гнать из профессии.
> Так, например, prepared запрос, или вызываемый из хранимки, пессимизируется.
Фейспалм.тхт
Ну почитайте же хоть что-нибудь о хранимых процедурах!> Если заставить php'шника унести логику в хранимки, то проблемы просто переедут в хранимки.
Потому что нельзя похапешника пускать с немытыми ногами в РСУБД. ДБА должен выкатить АПИ из хранимых процедур, и этим все взаимодействие похапешников с базой должно быть ограничено.
А подскажи язык, на котором нельзя написать софт с SQL инъекцией
html
Скорее даже CSS, потому как в HTML есть WebSocket.
В HTML нет websockets. Они есть в HTML5, который стандарт не только языка разметки HTML, но и кучи сопуствующих технологий, включающих в себя API websockets, который не включает в себя работу с sql. Websockets предоставляет для работы с sql не больше возможностей, чем обычные формы или гипертекстовые ссылки.
Почему же? На html можно реализовать клеточный автомат с правилом 101, а на нем машину Тьюринга и соответственно алгоритм, который использует уязвимость виртуальной машины для запуска работы с сетью.
> А подскажи язык, на котором нельзя написать софт с SQL инъекциейТот, на котором вообще невозможна работа с sql. Это же очевидно.
Внезапно, Java. Если не составлять запросы склеиванием строк, конечно.
Внезапно, на PHP точно такая же ситуация.
А вот и нет. В похапе даже это умудрились сделать через жопу:https://stackoverflow.com/questions/134099/are-pdo-prepared-...
и причем тут php, если речь о mysql api?
(причем в каком-то уникально уродливом варианте использования - узкоглазая кодировка на сервере, клиент не проверяет соответствие инпута кодировке - может в прошлом веке такое было возможно, сейчас у всех и везде будет utf, где этот фокус не получится)
> The important thing to realize here is that PDO by default does NOT do true prepared statements. It emulates them (for MySQL). Therefore, PDO internally builds the query string, calling mysql_real_escape_string() (the MySQL C API function) on each bound string value.Ты читать не умеешь?
Нет там речь именно о PHP. Только непонятно, почему задокументированную фичу PDO оппонент считает ошибкой.
Непонятно с чего оппонент пытается выдать PDO за честные prepared statements, хотя "be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively". Похапе - не просто г-но, хуже того, это ВНЕЗАПНО не работающее г-но.
внезапно, под капотом всё равно может оказаться склеивание строк где тоже можно накосячить.
> ... прошло 22 года с первого релиза похапе. В написанном на нём
> софте всё ещё находили детские уязвимости...То ли дело С, которому уже скоро полтиник стукнет, а младенческие null pointer dereference и buffer overflow всё никуда не деваются.
А они - не младенческие! Это ошибки настоящих мужиков, а не простиоспЫдя рубиков каких нить или пыхеров :) Такие и в песочнице, девочкам, показать не стыдно! :-р
> а младенческие null pointer dereference и buffer overflow всё никуда не деваются.Потому что головой надо думать а не другим местом. Это, кстати, ко всем языкам относится.
Это ты сейчас мощно всех программистов на С обдал. Оказывается они головой не думают, раз делают такие ошибки. Но ты то конечно не такой, ты ведь уже написал ядро аналогичное линукс без единой ошибки такого рода и вот-вот его всем покажешь, правда?
Господа а объясните мне кто-нибудь в чём суть дыры была?А то я полез в коммит и не очень понял суть фикса. Похоже они добавили очистку user preferenc'ов перед сохранением в базу.
Но то что у них там был injection говорит видимо о том, что они потом где-то в голом виде без экранирования в запросах используются??? И они это не стали править???
критическая уязвимость в Moodle позволила досрочно получить аттестаты за среднюю школу первоклассникам :)
Школьники же, небось, и писали. Именно для того, чтобы аттестаты досрочно получить.
> Школьники же, небось, и писали. Именно для того, чтобы аттестаты досрочно получить.Если школьники находят уязвимости и могут написать эксплойт - я спокоен за это поколение.