tgoop.com/devsecops_weekly/1238
Last Update:
5 лет, 160 комментариев и уязвимость устранена!
Всем привет!
Сегодня предлагаем вам очень увлекательную и захватывающую с первых минут статью.
Началось все с того, что Автор наткнулся на CVE-2022-1471, эксплуатация которой могла привести к RCE при использовании SnakeYAML.
И это удивило Автора, ведь в статье, которой на тот момент было уже 5 лет, упоминалась ровно та же самая уязвимость (только ей не был присвоен CVE), а SnakeYAML приводился в качестве одного из примеров.
Дальнейшее разбирательство немного шокировало: project maintainer перевел ее в значение «won’t fix», аргументируя это тем, что надо «просто использовать безопасный вариант реализации».
Да, он был прав. Но большинство людей не задумываются о том, как это правильно использовать. Им нужно реализовать десереализацию и только. Это подтверждается множеством примеров в интернете, где рекомендуется использовать небезопасный вариант.
С точки зрения Автора такой подход был в корне неверным. Ведь, если есть возможность, то лучше реализовать secure-by-default, а все остальное – на усмотрение пользователей.
Именно так и начался thread о том, что это надо исправить. На момент окончания обсуждения было порядка 160 комментариев.
Хорошая новость в том, что project maintainer все-таки согласился с тем, что можно сделать иначе и предоставил secure-by-default реализацию. Она попала в SnakeYAML 2.0.
В статье можно прочесть много интересных размышлений Автора:
🍭 О том, как используют средства анализа кода (иногда фокус смещается на создание новых правил для сканеров, а не на устранение существующих недостатков)
🍭 О том, что делать ИБ-исследователям, если они зашли в тупик при общении с «автором уязвимости»
🍭 О том, почему secure-by-default это важно и не только
Но это все лучше прочитать самим ☺️ Рекомендуем!
BY DevSecOps Talks
Share with your friend now:
tgoop.com/devsecops_weekly/1238