Опасная уязвимость в популярной библиотеке Sequelize

[Suvitruf]

А уязвимость то в чём? Ведёт себя ORM как положено. Во всех примерах в статье проблема не в ORM, а в голове того, кто входные данные в контроллере не валидирует.

[apapacy]

Не вникал в статью полностью. Но от ORM ожидаешь что при любом входном наборе все будет вести себя как ожидается. Например помню один случай с whaterline + nongodb. При отсутствии входного параметра id оператор delete или update вместо того чтобы пройти мимо, обновил или удалил все записи — точно не помню. Да после этого добавил проверки но как-то доверие к такой ORM стало меньше (если что я ее не выбирал проект пришел на сопровождение от фрилансера)

[Suvitruf]

Не вникал в статью полностью. Но от ORM ожидаешь что при любом входном наборе все будет вести себя как ожидается.

Так она, собственно, и ведёт себя как ожидается. Это поведение описано в документации.

[mark_ablov]

Эта опция deprecated уже фиг знает сколько времени. Может и была такая уязвимость лет 5 назад, но сейчас это не совсем актуально.

[Wallarm]

Все верно, давно deprecated. Однако, это было обнаружено случайно в одном из решений, используемом заказчиком и позволило обойти ограничения и получить несанкционированный доступ. Если на проектах сегодня встречается эта уязвимость, значит, угроза есть. Описание разных вариантов эксплуатации — это краткое простое руководство, как не совершить ошибку в ситуации, когда совершить ее достаточно легко.

[Jsty]

Концептуальная проблема с plain text password, а не с Sequelize.

[apapacy]

Недавно был шокирован. Фейсбук потребовал смены пароля. Я добавил к паролю один символ и получил ответ что мой пароль слишком похож на текущий. А как же с тоннами статей о хранении хэшей? Оказуется не только студенты так делают

[y4ppieflu]

Вы же, наверное, в ходе запроса на смену пароля и свой старый пароль тоже вводили в формочку?

[apapacy]

Вводил при логине. Не в ту же самую форму. То есть пароль в открытом виде хранится. Так что оптимизм в этим поводе излишен. Боюсь что картина с Эммой Уотсон и Томом Хэнксом (Круг или как ее там) провалилась именно потому что на момент ее выхода корпорации делали все то же только более цинично. И конечно это хранилище — как из фильмом про ЭВМ 60-х годов довершило не актуальность темы.

[ivanovych666]

Думаю, на самом деле пароли в открытом виде они не хранят. Здесь помню была статья как фейсбук "фиксит" пароли, например если капслок включен. Предположу что они берут новый пароль, делают простые модификации (меняют регистр, удаляют символы...) и сравнивают хеш суммы.

[apapacy]

Что дает повод так думать? Есть где-то требование (например в GDPR) не хранить пароли в открытом виде? Если они никак не пострадают от того что будет выявлено хранение паролей в открытом виде — то что им помешает сделать это? Совесть?

[Jsty]

Вот объяснение news.ycombinator.com/item?id=13426544

[Wallarm]

Кейс оформлен с plain text для наглядности, чтобы показать, что можно вытащить, используя username и password при запросе. И несмотря на то что эти символы исправлены, batching все равно работает. Проблема заключается не в самой библиотеке, а в том как она используется. В статье указано, что уязвимость существует из-за нестрогой типизации. Если бы при вызове ORM использовались строковые значения на уровне бэкенда, то такие методики уже бы не сработали.

[faiwer]

Мне кажется, что хранение паролей в открытом виде, это такой смертный грех, что даже в примерах лучше так не писать. Вдруг кто возьмёт на вооружение от незнания, невникая. "А что? В статье на хабре так написано".