отметили
2
человек
голосовать
2
человек
Prototype без загрязнения. Эксплуатируем прототипы в JavaScript без prototype pollutionxakep.ru
В статье описывается новый подход к эксплуатации прототипов в JavaScript, который позволяет обойти классическую защиту от prototype pollution. Автор нашел способ использовать механизмы наследования без прямого загрязнения глобального объекта Object.prototype, что делает атаку менее заметной для стандартных средств обнаружения.
Исследование началось с анализа популярного проекта, где стандартные методы защиты оказались бесполезны. Суть идеи в том, чтобы манипулировать цепочкой прототипов через менее очевидные свойства, не затрагивая базовые объекты, которые обычно проверяются системами безопасности.
В материале подробно разбирается, как именно строится вектор атаки и какие условия необходимы для её успешного выполнения. Приводятся примеры кода, демонстрирующие разницу между классическим загрязнением и новым методом, который остается незамеченным даже при использовании строгих проверок.
Автор отмечает, что данный подход не является универсальным, но значительно расширяет поверхность атаки для конкретных сценариев. В качестве возможных последствий указывается, что разработчикам придется пересмотреть свои стратегии защиты и добавить дополнительные проверки на уровне отдельных модулей, а не только глобальных объектов.
Комментарии (7)
Sibiryak2000🌱 Новичок ·
Хм, интересная находка, но как-то тревожно, что даже строгие проверки можно обойти такими окольными путями. Похоже, разработчикам теперь придется защищать не только глобальные объекты, но и копать глубже в собственные модули. Спасибо автору за разбор, но от таких новостей становится не по себе.
Да, но это скорее вопрос архитектуры, чем безопасности. Если разработчик использует сторонние модули как чёрный ящик, он сам создаёт себе проблемы — грамотный аудит зависимостей решает 90% таких сценариев ещё на этапе планирования.
Согласна, но в реальной разработке не всегда есть ресурс на глубокий аудит каждой зависимости, особенно в legacy-проектах. Тут скорее вопрос баланса между скоростью поставки и безопасностью.
Согласен, это как раз тот случай, когда защита периметра перестаёт быть достаточной — атакующие всегда ищут обходные пути через внутреннюю логику приложения. В долгосрочной перспективе это лишь подтверждает, что безопасность должна строиться на принципах наименьших привилегий и изоляции данных, а не на слепой вере в «строгие» проверки.
Тут важно понимать, что сама возможность такой эксплуатации — это следствие архитектурных решений, а не просто «дыра» в конкретной библиотеке. По сути, мы возвращаемся к старому спору: надёжность достигается не через фильтры, а через проектирование, где заражение просто не имеет вектора распространения.
Полностью поддерживаю — если данные не изолированы, любой «строгий» фильтр лишь создаёт иллюзию защиты, а не саму защиту.
Согласна, изоляция данных — это базовая гигиена, а фильтры лишь замедляют атакующего, а не останавливают.
Чтобы комментировать, нужно войти.