The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода"  +/
Сообщение от opennews (??), 04-Июл-22, 15:32 
Опубликованы корректирующие выпуски 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.ru/opennews/art.shtml?num=57452

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (1), 04-Июл-22, 15:32 
просто используешь построитель запросов и все. Но нет, давайте клеить sql-строку самому.
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость в web-фреймворке Django, которая может привести к..."  –6 +/
Сообщение от Без аргументов (?), 04-Июл-22, 15:50 
Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.
Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в web-фреймворке Django, которая может привести к..."  –7 +/
Сообщение от Аноним (6), 04-Июл-22, 16:06 
У меня конструкции вида 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. Вы что-то делаете не так.
Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в web-фреймворке Django, которая может привести к..."  –2 +/
Сообщение от Аноним (6), 04-Июл-22, 16:11 
Кстати, там то же самое рядом через 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'"))

ну и где читаемее?

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Без аргументов (?), 04-Июл-22, 19:54 
везде нифига не понятно.
интересно, как это будет работать, если строк миллион. а можно ли передать ему подсказку, в каких случаях использовать и какие индексы? нет.
Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 04-Июл-22, 20:19 
Прекрасно это работает. Откуда там миллиону взяться, если поле с жсоном обновляется пару раз в месяц? Причём, используется всегда только последнее значение, старые данные остаются для истории. Тут никаких проблем быть не может.
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от ПерлухаБратуха (?), 05-Июл-22, 04:46 
> тут никаких проблем быть не может.

Вот так и начинаются кадастрофы.

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 05-Июл-22, 13:44 
В данном случае это костыль, позволяющий избежать бессмысленного усложнения схемы и заполнения таблиц неконсистентными бесполезными данными. Никогда не поздно мигрировать на новую версию, при необходимости, однако, до сих пор не вижу ровно никаких предпосылок.
Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Онаним (?), 04-Июл-22, 22:11 
max([int(k) for k in self.relations]) - это какая-то хитрая чёрная магия?
Или просто у нас все объекты предвгружены? А если их там 100500000 и каждый по килобайту размером?
В жирных специфично сдизайненных контейнерах ORM получится что-то типа self.relations.getMaxByKey('k'), тогда уже да, никакой магии, просто эксплицитная поддержка.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

40. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Онаним (?), 04-Июл-22, 22:13 
Но если к max() надо ещё условие присандалить, то будет получаться шиза вида self.relations.getSubCollection(...conditions).getMaxByKey('k'), и это шиза.
Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 04-Июл-22, 22:45 
Это именно получение последнего по времени объекта из жсона, с ним можно работать как с обычным хеш тейблом. Только возвращает всё текстом, мне не понравился вариант пропатчить на поддержку других типов. При необходимости, он сначала подгружается (целиком, там undefer, да). Изменений там от 0 до нескольких за месяц, содержит категории и ссылки на данные (которые не обязательно имеются в одной из таблиц). Мне показалось это подходящим для моих задач, но я так и не смог нагуглить ничего даже отдалённо похожего. Потом можно будет скидывать старые данные куда-нибудь на диск, это же жсон.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

24. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Без аргументов (?), 04-Июл-22, 19:52 
Я ничего тут не понял что там у вас про JSON. Я говорю про человеческую нормализованную СУБД.
Но сразу виду обезьянокод. Какие-то двойные преобразования типов из текста в число. И еще макс можно сделать в одном запросе без вложения.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

30. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 04-Июл-22, 20:16 
Да не, тут нормально всё. Это json в sqlite, надо получить последнюю по времени запись из поля с жсоном, ключи в котором принудительно конвертируются в текст, а значит, последнее значение из текстового ключа не получить. Я это к тому, что даже если ORM не позволяет решить не стандартную задачу адекватно (вставки text), это всё ещё вполне прилично выглядит в результате, куда лучше чем голый зубодробительный sql с сотней уязвимостей на запрос.
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Без аргументов (?), 05-Июл-22, 00:03 
Ну я же говорю, что это детский садик. Другое дело когда у вас оракл и 120ГБ ОЗУ и пол терабайта данных продаж с тысячи магазинов за пол года перелопатить надо.
Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 05-Июл-22, 00:11 
Так если бы там были какие-то данные, я бы как минимум не стал использовать жсон в sqlite. Речь то совсем о другом. Я сомневаюсь, что перелопачивать пол терабайта надо прям на каждый запрос (для такого памяти маловато опять же), а значит, не исключено, что орм тут себя прекраснейшим образом проявит.
Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в web-фреймворке Django, которая может привести к..."  –2 +/
Сообщение от GG (ok), 05-Июл-22, 10:53 
ОРМ нужен не для того чтобы неадекватную архитектуру покрывать.
Если кто-то модель данных спроектировал так что там без такого геморроя велосипедов запрос не сделать — надо гнать его ссаными тряпками из профессии и переделывать нормально, а не городить вот это вот.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

55. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 05-Июл-22, 14:39 
Хех, но ведь это же вообще не имеет отношения к ORM, претензия должна быть к SQL (ну или к json).
Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Аноним (56), 06-Июл-22, 03:13 
На практике в нормализованных БД слишком много джойнов, даже если это база микросервиса с довольно узкой зоной ответственности. Поэтому денормализация до второй формы
и требования к "академичности" пониже и код пожиже. Зато работает в рамках заданного SLA.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

67. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Онаним (?), 08-Июл-22, 00:03 
Ха. Да. Дальше второй формы уходить - это уже для особых случаев. Когда не жалко.
Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Онаним (?), 04-Июл-22, 22:07 
Глаза чутка подвытекли.
Я уж за производительность этого добра даже не переживаю.
Каждый вызов функции - это офигенные накладные расходы даже в компилируемом языке, чем и плохи все генераторы.
В компилируемых такие вещи хотя бы заинлайнить можно, но в скриптовых всё очень плохо.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

44. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 04-Июл-22, 22:52 
Кстати, с производительностью всё удивительно хорошо в итоге. Ну и оно же кэшируется. С диска долго, в памяти нормально, никаких претензий. Проблемы начинаются, когда генерирует что-то не то.
Ответить | Правка | Наверх | Cообщить модератору

38. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Онаним (?), 04-Июл-22, 22:07 
Хотя конечно после cast(key as integer) там уже точно ничего не страшно
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

61. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (61), 06-Июл-22, 19:50 
> всё норм, ничего не бомбит

особенно тут:
> where(text("key and json_type(key) == 'integer' and type=='object'"))

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

62. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 06-Июл-22, 20:08 
Разве что, чуточку. Но в SQL это выглядело не лучше и позволяло выполнить подстановку чего-нибудь нехорошего в 5 местах, а тут не получится.
Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (68), 09-Июл-22, 17:02 
> позволяло выполнить подстановку чего-нибудь нехорошего

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

Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (66), 07-Июл-22, 18:38 
>Вы что-то делаете не так.

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Уязвимость в web-фреймворке Django, которая может привести к..."  +3 +/
Сообщение от Аноним (7), 04-Июл-22, 16:09 
Опять все путают ORM и Query Builder.

ORM нужна для того, чтобы автоматически организовать как сохранение данных дерева объектов в РСУБД, так и восстановление их из сохраненных в РСУБД данных в память. Такая своего рода сериализация, только в РСУБД, что позволяет эффективно организовать поиск по данным.

Query Builder нужен преимущественно как часть ORM для построения запросов для поиска нужных объектов в базе. При использовании Query Builder совместно с ORM важно, что они друг с другом интергрированы, и в качестве результата будут получены не сырые данные из базы, а нужный объект (или коллекция) со всеми вложенными объектами-коллекциями.

Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). Query Builder-ы иногда полезны, если запрос строится в зависимости от данных, запрошенным пользователем - без них довольно неудобно собирать запрос по частям (что-то в select, что-то в join, что-то в where и т.д.). Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy. С более примитивными QB, которые разработаны как вспомогательные части для ORM, будет проще генерировать запрос вручную.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

18. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от kai3341 (ok), 04-Июл-22, 19:29 
> Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга).
> Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy

Вот весь прикол в том, что аналитические запросы есть смысл класть на нормальную ORM типа алхимии (DjangoORM говно). Так как статью (ниже) читать дело не царское, скажу тут. ORM позволяет сделать SQL-запрос модульным, позволяет повторно переиспользовать код через наследование или композицию. Также адекватная ORM умеет в вывод типов. Алхимия позволяет также реализовывать макросы, что удачно сочетается с выводом типов.

Ещё раз для тех, что не умеет читать: чмORM типа той же djangoORM дают преимущества только на простейших запросах (CRUD), но на аналитике дрыщут в лужу. Адекватные ORM типа алхимии дают как преимущества на банальном CRUD, так и на аналитике.

Ну и таки шо по производительности? Если верхний мозг не использовать, то алхимия тормозит, джанга чуть меньше тормозит. Если верхний мозг в наличии, то небольшие тормоза получаем на этапе инициализации, но в рантайме производительность мало отличается от raw sql. Вопросу уделено особое внимание в статье

А ещё про миграции никто не рассказал

Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (19), 04-Июл-22, 19:41 
Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам нет, не совсем корректно называть это ORM.
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от kai3341 (ok), 04-Июл-22, 19:48 
> Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую
> гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам
> нет, не совсем корректно называть это ORM.

Пользуясь случаем, о каком двустороннем маппинге речь? Об ActiveRecord? Если да, то где он вообще есть для такого типа запросов?

Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в web-фреймворке Django, которая может привести к..."  –1 +/
Сообщение от Онаним (?), 04-Июл-22, 22:16 
Поскольку тормозит применительно к питону - это его естественное состояние, всё вами описанное таки верно.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

50. "Уязвимость в web-фреймворке Django, которая может привести к..."  –1 +/
Сообщение от GG (ok), 05-Июл-22, 10:56 
> нет двухстороннего маппинга

Давно уже есть, просто довольно нетривиально

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

9. "Уязвимость в web-фреймворке Django, которая может привести к..."  –3 +/
Сообщение от kai3341 (ok), 04-Июл-22, 16:16 
> Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.

Меня тоже бомбило, но потом я попробовал алхимию: https://habr.com/ru/post/559738/
Выходит плюс/минус тот же самый синтаксис

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

12. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (12), 04-Июл-22, 17:30 
Если выходит плюс минус так же, зачем? Чтобы что? В базу оно все равно пойдет в виде запроса. Лишь бы не писать SQL?
Из той же серии билдеры регулярных выражений (не путать с грамматиками). Иррациональный страх перед технологиями отцов-основателей? Своё лучше пахнет и делает волосы мягче и шелковистее?
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость в web-фреймворке Django, которая может привести к..."  –2 +/
Сообщение от kai3341 (ok), 04-Июл-22, 18:19 
Как думаете, зачем я дал ссылку на статью? Ответ -- в ней ответы на заданные вами вопросы и некоторые ещё не заданные
Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость в web-фреймворке Django, которая может привести к..."  +2 +/
Сообщение от Аноним (11), 04-Июл-22, 16:53 
Расскажи пожалуйста подробно, зачем ты делаешь сложные операции? Ты не думал что твои геройствования связаны с плохой архитектурой?
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

20. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Без аргументов (?), 04-Июл-22, 19:45 
Я работал разработчиком BI-отчетов и витрин данных. Там на первом месте оптимизация и скорость выполнения. Как выше написали, ORM/QB детский садик работает для примитивных CRUD. Насчет мапинга не скажу, что удобнее. Точнее мапинг можно и из сырого запроса сделать без всякого блоатваре.
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в web-фреймворке Django, которая может привести к..."  –3 +/
Сообщение от GG (ok), 05-Июл-22, 10:57 
Вон из профессии
Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в web-фреймворке Django, которая может привести к..."  –1 +/
Сообщение от Без аргументов (?), 04-Июл-22, 19:57 
Вся эта шелуха работает до тех пор, пока проект более менее не вырастет в большую кучу данных, а не тупо выбрать товары, чтобы в вебне показать витрину.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

32. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 04-Июл-22, 20:51 
Но-но, у нас тут хайлоад, кек. Орм в первую очередь, про удобство взаимодействия с данными. У тебя есть инстанс чего-то, у него есть отношения с другими инстансами чего-то, на эти инстансы по различным правилам мапятся данные из таблиц, при совершении определённых операций могут случатся всевозможные полезные вещи с зависимостями в других таблицах. Когда он больше не нужен, он автоматически удаляешься из сессии (и её кэша).

Если шпарить sql, довольно быстро свихнёшься, а баги ловить ещё то удовольствие. Хотя ВЫГЛЯДИТ оно куда проще, ага. Стоимость намного выше в итоге, а ошибок и уязвимостей больше, сопровождение и доработка часто превращаются в практически не решаемую проблему.

Если, конечно, задача примитивная, там чем проще тем лучше, но когда связей много, или много условий, что и когда подгружать (у записи много данных, которые не нужны при наиболее частых обращениях) и обновлять, тут без орм никуда.

Я бы не стал прям так демонизировать орм, у этого подхода есть большой спектр задач, которые он способен решать весьма эффективно. В принципе, та же алхимия, может использоваться и без орм, если производительность и эффективность прямо так важны (что крайне маловероятно на практике), всё ещё остаётся много хорошего, что в ней есть помимо него.

Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в web-фреймворке Django, которая может привести к..."  +2 +/
Сообщение от Онаним (?), 04-Июл-22, 21:59 
Народ ныне очень любит ORM отрывать от логики объектов, превращая его в прослойку между объектами и БД, и запихивая всю логику обработки полностью в рассредоточенные контроллеры. Вот с этого подхода лично меня коробит, это лишняя абстракция ради абстракции

Сам предпочитаю жирный ORM и контейнеры. Когда объекты из ORM рассованы по своим управляющим контейнерам, отвечающим за вгрузку-выгрузку, и когда они работают как полноценные объекты от логики - представляя собой не только тупой набор данных, но и всё, что нужно для их обработки. Из ORM у этих объектов "лишнего" только чтение-запись-удаление, в остальном они обычная часть логики обработки. Наличие контейнеров позволяет оптимизировать внутри контейнеров такие операции, как нестандартная выборка по условию, добавляя те части SQL, которые в самых дубовых 1-1 ORM'ах реализуются через одно место внешними запросами и впихиванием данных.

Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в web-фреймворке Django, которая может привести к..."  –1 +/
Сообщение от GG (ok), 05-Июл-22, 11:00 
Если у тебя набор данных сложнее товаров для витрины превращается в непроходимую кучу — это исключительно твоя проблема.
И заключается она не в ОРМ, а в том что ты себя возомнил архитектором, когда на самом деле тебе и бейджик кодера-юниора снимать рано ещё.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

36. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Онаним (?), 04-Июл-22, 22:03 
Пока у тебя да, полтора товара на витрине, как правильно указали - тебе пойдёт и один запрос на объект.
Но когда у тебя хотя бы 100M записей в день начнёт капать, которые ещё надо с другими объектами связывать, тебе так или иначе их придётся пакетной обработкой проходить...
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

17. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (17), 04-Июл-22, 18:56 
А каким образом Вы боретесь с уязвимостями типа "sql-иньекция"?
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Без аргументов (?), 04-Июл-22, 19:46 
Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще изкоробки обычно есть постановка параметров (через ???), которая проверяет.
Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от kai3341 (ok), 04-Июл-22, 20:05 
> Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще
> изкоробки обычно есть постановка параметров (через ???), которая проверяет.

Любой драйвер БД умеет в подстановку значений. Я рекомендую читать документацию

Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимость в web-фреймворке Django, которая может привести к..."  –1 +/
Сообщение от Без аргументов (?), 04-Июл-22, 19:56 
Нифига сколько неосиляторов в SQL минусонуло. Ну я тоже с трудом въезжал. Пока не научился делать пятэтажные запросы и такие, и сякие, с динамической группировкой и фильтрами на тысячу строк кода. А бывает, когда в СУБД надо передать хинты, т.к. оптимизатор не экстрасенс на все случаи жизни
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

33. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (6), 04-Июл-22, 21:00 
Не в этом дело, мне кажется. Просто, комментатор слишком уж категоричен. Ну и потом, я слабо себе представляю, как можно использовать ORM, без чёткого понимания, что и зачем он генерирует.
Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Онаним (?), 04-Июл-22, 22:19 
Ды не, ORM своё место. Тут стоит для начала вернуться к тому, что ORM от SQL-injection как правило не спасает, поскольку часть вещей на ORM всё равно нереализуема и сваливается к передаче в ORM кусков запроса. Самый простой пример - когда надо вгрузить объекты, подходящие по длинным цепочкам пропертей других объектов. Нет, можно всё повгружать "по порядочку", но когда у тебя на каждом шаге по миллиону записей - это становится немножко накладно.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

2. Скрыто модератором  –1 +/
Сообщение от васёк (?), 04-Июл-22, 15:36 
Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором  +1 +/
Сообщение от Корец (?), 04-Июл-22, 15:46 
Ответить | Правка | Наверх | Cообщить модератору

5. Скрыто модератором  +/
Сообщение от Без аргументов (?), 04-Июл-22, 15:51 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

14. "Уязвимость в web-фреймворке Django, которая может привести к..."  –2 +/
Сообщение от Аристарх (??), 04-Июл-22, 18:46 
> подстановку своего SQL-кода

Тест на имбецила в 21 веке. Если такая ошибка находится, СРАЗУ же в отдел кадров на увольнение по собственному!

Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Без аргументов (?), 04-Июл-22, 19:47 
Соглы.
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Sergey (??), 04-Июл-22, 18:46 
А как это можно использовать ? Не совсем понятно, куда нужно вбивать свой СКУЛь запрос ;(
Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (63), 07-Июл-22, 14:41 
В эксплоит. Эксплоит тебе придеться купить.
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Аноним (17), 04-Июл-22, 18:49 
Нужно использовать "подготовленные выражения" и тогда sql-иньекции станут невозможны.
Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость в web-фреймворке Django, которая может привести к..."  –1 +/
Сообщение от Онаним (?), 04-Июл-22, 20:10 
затонеphp(tm)
Суть та же, криворучки - они повсюду.
Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Аноним (34), 04-Июл-22, 21:51 
Sql injection в 2022? Достижение!
Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (63), 07-Июл-22, 14:43 
Достижение, что наконец-то лидерство какого-то говнянеького фреймворка начинает шататься.
Вопрос только, что где что-то можное современное молодежное с асинхроньщиной и поэтессами =)
Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Аноним (47), 05-Июл-22, 04:32 
Перечисленные методы в нормальных руках (при нормальных мозгах) никогда не будут принимать непроверенные параметры. Расходимся посоны...
Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (61), 05-Июл-22, 14:06 
> непроверенные внешние данные

А раст может как-то помочь? Или в расте такие же дыры?

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (56), 06-Июл-22, 03:25 
От ошибок в бизнес-логике раст тоже не защитит. Только от гонок и некоторых видов утечек в куче.
Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Аноним (6), 06-Июл-22, 03:47 
Пока вебрендера не было, синхронизация вкладок не отваливалась.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в web-фреймворке Django, которая может привести к..."  +1 +/
Сообщение от Аноним (60), 06-Июл-22, 17:45 
Ратс не нужен забудь про него плз.  
Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимость в web-фреймворке Django, которая может привести к..."  +/
Сообщение от Аноним (63), 07-Июл-22, 14:49 
Так его так и не доснимали же ...
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру