Опубликованы корректирующие выпуски web-фреймворка Django 4.0.6 и 3.2.14, в которых устранена уязвимость (CVE-2022-34265), потенциально позволяющая выполнить подстановку своего SQL-кода. Проблема затрагивает приложения, использующие непроверенные внешние данные в параметрах kind и lookup_name, передаваемых в функции Trunc(kind) и Extract(lookup_name). Программы, которые допускают в значениях lookup_name и kind только проверенные данные уязвимость не затрагивает...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57452
просто используешь построитель запросов и все. Но нет, давайте клеить sql-строку самому.
Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.
У меня конструкции вида select(func.max(text("cast(key as integer)")),text('value')).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'")) всё норм, ничего не бомбит. Легко читается, даже легче, чем чисто sql. Вы что-то делаете не так.
Кстати, там то же самое рядом через ORM, если это зло и намного хуже, то я даже не знаю ем тут помочь.maxvalue = max([int(k) for k in self.relations])
return (maxvalue, self.relations[str(maxvalue)],)а вот это orm-sql
return select(func.max(text("cast(key as integer)"))).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'"))
ну и где читаемее?
везде нифига не понятно.
интересно, как это будет работать, если строк миллион. а можно ли передать ему подсказку, в каких случаях использовать и какие индексы? нет.
Прекрасно это работает. Откуда там миллиону взяться, если поле с жсоном обновляется пару раз в месяц? Причём, используется всегда только последнее значение, старые данные остаются для истории. Тут никаких проблем быть не может.
> тут никаких проблем быть не может.Вот так и начинаются кадастрофы.
В данном случае это костыль, позволяющий избежать бессмысленного усложнения схемы и заполнения таблиц неконсистентными бесполезными данными. Никогда не поздно мигрировать на новую версию, при необходимости, однако, до сих пор не вижу ровно никаких предпосылок.
max([int(k) for k in self.relations]) - это какая-то хитрая чёрная магия?
Или просто у нас все объекты предвгружены? А если их там 100500000 и каждый по килобайту размером?
В жирных специфично сдизайненных контейнерах ORM получится что-то типа self.relations.getMaxByKey('k'), тогда уже да, никакой магии, просто эксплицитная поддержка.
Но если к max() надо ещё условие присандалить, то будет получаться шиза вида self.relations.getSubCollection(...conditions).getMaxByKey('k'), и это шиза.
Это именно получение последнего по времени объекта из жсона, с ним можно работать как с обычным хеш тейблом. Только возвращает всё текстом, мне не понравился вариант пропатчить на поддержку других типов. При необходимости, он сначала подгружается (целиком, там undefer, да). Изменений там от 0 до нескольких за месяц, содержит категории и ссылки на данные (которые не обязательно имеются в одной из таблиц). Мне показалось это подходящим для моих задач, но я так и не смог нагуглить ничего даже отдалённо похожего. Потом можно будет скидывать старые данные куда-нибудь на диск, это же жсон.
Я ничего тут не понял что там у вас про JSON. Я говорю про человеческую нормализованную СУБД.
Но сразу виду обезьянокод. Какие-то двойные преобразования типов из текста в число. И еще макс можно сделать в одном запросе без вложения.
Да не, тут нормально всё. Это json в sqlite, надо получить последнюю по времени запись из поля с жсоном, ключи в котором принудительно конвертируются в текст, а значит, последнее значение из текстового ключа не получить. Я это к тому, что даже если ORM не позволяет решить не стандартную задачу адекватно (вставки text), это всё ещё вполне прилично выглядит в результате, куда лучше чем голый зубодробительный sql с сотней уязвимостей на запрос.
Ну я же говорю, что это детский садик. Другое дело когда у вас оракл и 120ГБ ОЗУ и пол терабайта данных продаж с тысячи магазинов за пол года перелопатить надо.
Так если бы там были какие-то данные, я бы как минимум не стал использовать жсон в sqlite. Речь то совсем о другом. Я сомневаюсь, что перелопачивать пол терабайта надо прям на каждый запрос (для такого памяти маловато опять же), а значит, не исключено, что орм тут себя прекраснейшим образом проявит.
ОРМ нужен не для того чтобы неадекватную архитектуру покрывать.
Если кто-то модель данных спроектировал так что там без такого геморроя велосипедов запрос не сделать — надо гнать его ссаными тряпками из профессии и переделывать нормально, а не городить вот это вот.
Хех, но ведь это же вообще не имеет отношения к ORM, претензия должна быть к SQL (ну или к json).
На практике в нормализованных БД слишком много джойнов, даже если это база микросервиса с довольно узкой зоной ответственности. Поэтому денормализация до второй формы
и требования к "академичности" пониже и код пожиже. Зато работает в рамках заданного SLA.
Ха. Да. Дальше второй формы уходить - это уже для особых случаев. Когда не жалко.
Глаза чутка подвытекли.
Я уж за производительность этого добра даже не переживаю.
Каждый вызов функции - это офигенные накладные расходы даже в компилируемом языке, чем и плохи все генераторы.
В компилируемых такие вещи хотя бы заинлайнить можно, но в скриптовых всё очень плохо.
Кстати, с производительностью всё удивительно хорошо в итоге. Ну и оно же кэшируется. С диска долго, в памяти нормально, никаких претензий. Проблемы начинаются, когда генерирует что-то не то.
Хотя конечно после cast(key as integer) там уже точно ничего не страшно
> всё норм, ничего не бомбитособенно тут:
> where(text("key and json_type(key) == 'integer' and type=='object'"))
Разве что, чуточку. Но в SQL это выглядело не лучше и позволяло выполнить подстановку чего-нибудь нехорошего в 5 местах, а тут не получится.
> позволяло выполнить подстановку чего-нибудь нехорошегоНе понял, ты на код глазами смотришь или чем? Про возможность эскейпинга подставляемых значений безо всяких ормов что-нибудь слышал?
>Вы что-то делаете не так.Да, я, например, хочу строить запросы одинаково на любом рантайме.
Опять все путают ORM и Query Builder.ORM нужна для того, чтобы автоматически организовать как сохранение данных дерева объектов в РСУБД, так и восстановление их из сохраненных в РСУБД данных в память. Такая своего рода сериализация, только в РСУБД, что позволяет эффективно организовать поиск по данным.
Query Builder нужен преимущественно как часть ORM для построения запросов для поиска нужных объектов в базе. При использовании Query Builder совместно с ORM важно, что они друг с другом интергрированы, и в качестве результата будут получены не сырые данные из базы, а нужный объект (или коллекция) со всеми вложенными объектами-коллекциями.
Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). Query Builder-ы иногда полезны, если запрос строится в зависимости от данных, запрошенным пользователем - без них довольно неудобно собирать запрос по частям (что-то в select, что-то в join, что-то в where и т.д.). Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy. С более примитивными QB, которые разработаны как вспомогательные части для ORM, будет проще генерировать запрос вручную.
> Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга).
> Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemyВот весь прикол в том, что аналитические запросы есть смысл класть на нормальную ORM типа алхимии (DjangoORM говно). Так как статью (ниже) читать дело не царское, скажу тут. ORM позволяет сделать SQL-запрос модульным, позволяет повторно переиспользовать код через наследование или композицию. Также адекватная ORM умеет в вывод типов. Алхимия позволяет также реализовывать макросы, что удачно сочетается с выводом типов.
Ещё раз для тех, что не умеет читать: чмORM типа той же djangoORM дают преимущества только на простейших запросах (CRUD), но на аналитике дрыщут в лужу. Адекватные ORM типа алхимии дают как преимущества на банальном CRUD, так и на аналитике.
Ну и таки шо по производительности? Если верхний мозг не использовать, то алхимия тормозит, джанга чуть меньше тормозит. Если верхний мозг в наличии, то небольшие тормоза получаем на этапе инициализации, но в рантайме производительность мало отличается от raw sql. Вопросу уделено особое внимание в статье
А ещё про миграции никто не рассказал
Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам нет, не совсем корректно называть это ORM.
> Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую
> гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам
> нет, не совсем корректно называть это ORM.Пользуясь случаем, о каком двустороннем маппинге речь? Об ActiveRecord? Если да, то где он вообще есть для такого типа запросов?
Поскольку тормозит применительно к питону - это его естественное состояние, всё вами описанное таки верно.
> нет двухстороннего маппингаДавно уже есть, просто довольно нетривиально
> Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.Меня тоже бомбило, но потом я попробовал алхимию: https://habr.com/ru/post/559738/
Выходит плюс/минус тот же самый синтаксис
Если выходит плюс минус так же, зачем? Чтобы что? В базу оно все равно пойдет в виде запроса. Лишь бы не писать SQL?
Из той же серии билдеры регулярных выражений (не путать с грамматиками). Иррациональный страх перед технологиями отцов-основателей? Своё лучше пахнет и делает волосы мягче и шелковистее?
Как думаете, зачем я дал ссылку на статью? Ответ -- в ней ответы на заданные вами вопросы и некоторые ещё не заданные
Расскажи пожалуйста подробно, зачем ты делаешь сложные операции? Ты не думал что твои геройствования связаны с плохой архитектурой?
Я работал разработчиком BI-отчетов и витрин данных. Там на первом месте оптимизация и скорость выполнения. Как выше написали, ORM/QB детский садик работает для примитивных CRUD. Насчет мапинга не скажу, что удобнее. Точнее мапинг можно и из сырого запроса сделать без всякого блоатваре.
Вон из профессии
Вся эта шелуха работает до тех пор, пока проект более менее не вырастет в большую кучу данных, а не тупо выбрать товары, чтобы в вебне показать витрину.
Но-но, у нас тут хайлоад, кек. Орм в первую очередь, про удобство взаимодействия с данными. У тебя есть инстанс чего-то, у него есть отношения с другими инстансами чего-то, на эти инстансы по различным правилам мапятся данные из таблиц, при совершении определённых операций могут случатся всевозможные полезные вещи с зависимостями в других таблицах. Когда он больше не нужен, он автоматически удаляешься из сессии (и её кэша).Если шпарить sql, довольно быстро свихнёшься, а баги ловить ещё то удовольствие. Хотя ВЫГЛЯДИТ оно куда проще, ага. Стоимость намного выше в итоге, а ошибок и уязвимостей больше, сопровождение и доработка часто превращаются в практически не решаемую проблему.
Если, конечно, задача примитивная, там чем проще тем лучше, но когда связей много, или много условий, что и когда подгружать (у записи много данных, которые не нужны при наиболее частых обращениях) и обновлять, тут без орм никуда.
Я бы не стал прям так демонизировать орм, у этого подхода есть большой спектр задач, которые он способен решать весьма эффективно. В принципе, та же алхимия, может использоваться и без орм, если производительность и эффективность прямо так важны (что крайне маловероятно на практике), всё ещё остаётся много хорошего, что в ней есть помимо него.
Народ ныне очень любит ORM отрывать от логики объектов, превращая его в прослойку между объектами и БД, и запихивая всю логику обработки полностью в рассредоточенные контроллеры. Вот с этого подхода лично меня коробит, это лишняя абстракция ради абстракцииСам предпочитаю жирный ORM и контейнеры. Когда объекты из ORM рассованы по своим управляющим контейнерам, отвечающим за вгрузку-выгрузку, и когда они работают как полноценные объекты от логики - представляя собой не только тупой набор данных, но и всё, что нужно для их обработки. Из ORM у этих объектов "лишнего" только чтение-запись-удаление, в остальном они обычная часть логики обработки. Наличие контейнеров позволяет оптимизировать внутри контейнеров такие операции, как нестандартная выборка по условию, добавляя те части SQL, которые в самых дубовых 1-1 ORM'ах реализуются через одно место внешними запросами и впихиванием данных.
Если у тебя набор данных сложнее товаров для витрины превращается в непроходимую кучу — это исключительно твоя проблема.
И заключается она не в ОРМ, а в том что ты себя возомнил архитектором, когда на самом деле тебе и бейджик кодера-юниора снимать рано ещё.
Пока у тебя да, полтора товара на витрине, как правильно указали - тебе пойдёт и один запрос на объект.
Но когда у тебя хотя бы 100M записей в день начнёт капать, которые ещё надо с другими объектами связывать, тебе так или иначе их придётся пакетной обработкой проходить...
А каким образом Вы боретесь с уязвимостями типа "sql-иньекция"?
Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще изкоробки обычно есть постановка параметров (через ???), которая проверяет.
> Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще
> изкоробки обычно есть постановка параметров (через ???), которая проверяет.Любой драйвер БД умеет в подстановку значений. Я рекомендую читать документацию
Нифига сколько неосиляторов в SQL минусонуло. Ну я тоже с трудом въезжал. Пока не научился делать пятэтажные запросы и такие, и сякие, с динамической группировкой и фильтрами на тысячу строк кода. А бывает, когда в СУБД надо передать хинты, т.к. оптимизатор не экстрасенс на все случаи жизни
Не в этом дело, мне кажется. Просто, комментатор слишком уж категоричен. Ну и потом, я слабо себе представляю, как можно использовать ORM, без чёткого понимания, что и зачем он генерирует.
Ды не, ORM своё место. Тут стоит для начала вернуться к тому, что ORM от SQL-injection как правило не спасает, поскольку часть вещей на ORM всё равно нереализуема и сваливается к передаче в ORM кусков запроса. Самый простой пример - когда надо вгрузить объекты, подходящие по длинным цепочкам пропертей других объектов. Нет, можно всё повгружать "по порядочку", но когда у тебя на каждом шаге по миллиону записей - это становится немножко накладно.
и питоша тоже? я думал только Сишка дырявая
>я думал только Сишка дыряваяНе переживай, дырявым может быть код на любом языке. Даже на том самом ;)
А у тебя минимум 4 дырки.
> подстановку своего SQL-кодаТест на имбецила в 21 веке. Если такая ошибка находится, СРАЗУ же в отдел кадров на увольнение по собственному!
Соглы.
А как это можно использовать ? Не совсем понятно, куда нужно вбивать свой СКУЛь запрос ;(
В эксплоит. Эксплоит тебе придеться купить.
Нужно использовать "подготовленные выражения" и тогда sql-иньекции станут невозможны.
затонеphp(tm)
Суть та же, криворучки - они повсюду.
Sql injection в 2022? Достижение!
Достижение, что наконец-то лидерство какого-то говнянеького фреймворка начинает шататься.
Вопрос только, что где что-то можное современное молодежное с асинхроньщиной и поэтессами =)
Перечисленные методы в нормальных руках (при нормальных мозгах) никогда не будут принимать непроверенные параметры. Расходимся посоны...
> непроверенные внешние данныеА раст может как-то помочь? Или в расте такие же дыры?
От ошибок в бизнес-логике раст тоже не защитит. Только от гонок и некоторых видов утечек в куче.
Пока вебрендера не было, синхронизация вкладок не отваливалась.
Ратс не нужен забудь про него плз.
Так его так и не доснимали же ...