Только что, раскрутил просто изумительный баг в одном ASP.NET-приложении. Он крайне интересен с т.з. безопасности тем, какие возможности открывает атакующему, а противникам синглтона возможно будет интересен, как еще один аргумент против их использования где ни попадя. Хотел закинуть как этюд в ИБ, но чувствую, что с подобной спецификой вряд ли кто-либо сталкивался.
Данное приложение взаимодейстует с моделью через единый класс ModelManager, обеспечивающий доступ ко всем сущностям (по сути activerecord'ам) модели. Часть записей, из соображений быстродействия, дублируется в состоянии сеанса, чтобы лишний раз не ходить в базу, а взять данные прямо из памяти (модель обработки сесиий InProc, приложение явно не высоконагруженное, зачем это так реализовали — лично для меня загадка). Несколькими из таких записей, являются данные профиля текущего пользователя, в частности, его почтовый адрес (на который, помимо прочего, происходит сброс пользовательского пароля). ModelManager реализован в виде синглтона, соответственно обращение к отдельным таблицам происходит через их разыменование посредством дерганья его статического поля Instance.
Проблема в том, что и в состояние сеанса эти записи сохраняются именно так: как то, что возвращается при обращении к некоему статическому полю. В этом случае (по крайней мере, при модели обработки сессий InProc) ASP.NET шарит значения всех полей статичных классов между всеми имеющимися на данный момент сессиями. Иными словами, если пользователь меняет себе почтовый адрес и не дает после этого своей сессии умереть (периодически отправляя какие-либо запросы, например повторные, на смену почтового адреса), то при сбросе пароля другим пользователем, его новое значение уйдет по адресу первого пользователя, а не того, кто реально сбрасывал пароль.
Здравствуйте, adontz, Вы писали: A>Здравствуйте, kochetkov.vladimir, Вы писали:
A>Рассказ на редкость бессвязный.
Есть синглтон, который обеспечивает доступ ко всей модели. Есть механизм сессий в ASP.NET, позволяющий сохранять произвольные объекты в пользовательской сессии, чем и пользуется данное приложение для кэширования наиболее часто используемых сущностей. Есть особенность ASP.NET, заключающаяся в том, что если ты сохраняешь в такую сессию поля статичного класса, то они разделяются между всеми пользовательскими сессиями. И есть разработчик, который не подумал о том, что использование синглтона с его статичным полем Instance как раз попадает под эту особенность.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Что непонятно-то?
Непонятно, почему акцент на слове Синглтон, а не "особенность ASP.NET, заключающаяся в том, что если ты сохраняешь в сессию поля статичного класса, то они разделяются между всеми пользовательскими сессиями".
Я не защищаю Синглтон, судя по твоему рассказу он и правда не к месту, но поле статического класса может и не быть полем синглтона и почему сообщение озаглавлено так, как озаглавлено мне не понятно.
Здравствуйте, adontz, Вы писали:
A>Я не защищаю Синглтон, судя по твоему рассказу он и правда не к месту, но поле статического класса может и не быть полем синглтона и почему сообщение озаглавлено так, как озаглавлено мне не понятно.
Потому что, если бы разработчик везде, где использует синглтон, просто пробрасывал бы честный экземпляр модели, то этой баги бы просто не было. Статичное поле там появилось как следствие желания применить синглтон, а не как сама цель.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, adontz, Вы писали:
A>>Я не защищаю Синглтон, судя по твоему рассказу он и правда не к месту, но поле статического класса может и не быть полем синглтона и почему сообщение озаглавлено так, как озаглавлено мне не понятно.
KV>Потому что, если бы разработчик везде, где использует синглтон, просто пробрасывал бы честный экземпляр модели, то этой баги бы просто не было. Статичное поле там появилось как следствие желания применить синглтон, а не как сама цель.
Это же особенность статичных полей. Зачем вы работаете с Синглтоном неправильно?
Или отделите зависимый интерфейс для каждого пользователя в отдельный класс
специализация — удел насекомых... (с) Р. Хайнлайн
Re[6]: О вреде синглтонов (на этот раз, про безопасность)
Здравствуйте, hVostt, Вы писали:
V>Это же особенность статичных полей. Зачем вы работаете с Синглтоном неправильно?
Так, стоп. Я не "работаю с синглтоном" в вашем понимании. Я занимаюсь анализом защищенности веб-приложений, а не их разработкой.
V>Или отделите зависимый интерфейс для каждого пользователя в отдельный класс
Это будет делать разработчик того приложения. Причем весьма быстро, судя по всему
Здравствуйте, hVostt, Вы писали:
V>Это же особенность статичных полей. Зачем вы работаете с Синглтоном неправильно?
Но вот скажите мне, много разработчиков дойдут до мысли, что обращение к модели через поле синглтона и есть та самая особенность? Мне показалось, что немного. Допускаю, что ошибаюсь, но по-моему, этот баг весьма неочевиден.
V>Или отделите зависимый интерфейс для каждого пользователя в отдельный класс
Там проще убить этот синглтон, чем что-то отделять.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV> то при сбросе пароля другим пользователем, его новое значение уйдет по адресу первого пользователя, а не того, кто реально сбрасывал пароль.
KV>По-моему, это просто здорово
Ну так если используется статическое поле разделяемое между всеми сессиями без проверки что за мусор там находится перед важной операцией, то удивительно как вообще другие статическме поля не дают сбоев.
Трудно обновить значение поля из БД перед его использованием? Или я вообще ничего не понял про сессии в ASP.NET
PS. Я не тот программист который такое напрограммировал
Re[3]: О вреде синглтонов (на этот раз, про безопасность)
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Есть особенность ASP.NET, заключающаяся в том, что если ты сохраняешь в такую сессию поля статичного класса, то они разделяются между всеми пользовательскими сессиями.
А можно хотя бы псевдокод какой-то? А то чё-то не очень понятно, а тут уже начинаются гадалки кто на самом деле виноват — синглтон, ASP.NET или программист.
Re[2]: О вреде синглтонов (на этот раз, про безопасность)
Здравствуйте, MozgC, Вы писали:
MC>А можно хотя бы псевдокод какой-то? А то чё-то не очень понятно, а тут уже начинаются гадалки кто на самом деле виноват — синглтон, ASP.NET или программист.
Ставлю на программиста
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[5]: О вреде синглтонов (на этот раз, про безопасность)
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Потому что, если бы разработчик везде, где использует синглтон, просто пробрасывал бы честный экземпляр модели, то этой баги бы просто не было. Статичное поле там появилось как следствие желания применить синглтон, а не как сама цель.
То есть, проблема в статике, а не в синглтоне.
Re: О вреде синглтонов (на этот раз, про безопасность)
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Только что, раскрутил просто изумительный баг в одном ASP.NET-приложении. Он крайне интересен с т.з. безопасности тем, какие возможности открывает атакующему, а противникам синглтона возможно будет интересен, как еще один аргумент против их использования где ни попадя. Хотел закинуть как этюд в ИБ, но чувствую, что с подобной спецификой вряд ли кто-либо сталкивался.
Нужен переводчик
Re: О вреде синглтонов (на этот раз, про безопасность)