У меня интересная проблема с попыткой отслеживать истекшие сеансы аутентификации / файлы cookie WIF.
Немного предыстории: сайт является MVC 3, использует Windows Identity Foundation (WIF), который имеет доверие с сервером ADFS в качестве STS. Весь сайт защищен SSL. STS имеет срок действия токена, установленный на 60 минут.
Когда пользователь выходит вручную, мы просто вызываем метод SignOut в модуле FedAuth:
FederatedAuthentication.WSFederationAuthenticationModule.SignOut(false);
Это, конечно, удаляет файлы cookie FedAuth, но здесь начинается проблема. Если я захватываю эти файлы cookie с помощью Fiddler, я могу повторно представить их на сайте по истечении срока их действия и по-прежнему считаться зарегистрированным.
Я понимаю, что это выполняется с привилегированной позиции браузера, который принял скрипач в качестве прокси ... но заказчик обеспокоен тем, что срок действия тех cookie-файлов аутентификации, срок действия которых не истек, представляет значительный риск для безопасности. Они не уверены, что SSL защищает сайт в достаточной степени и что, если злоумышленник может выполнить атаку MITM, он может использовать эти файлы cookie после того, как пользователь подумает, что вышел из системы.
Я объяснил, что если они уязвимы после выхода из системы, они уязвимы во время входа в систему, но им все равно ...
Поэтому я искал способы убедиться, что после выхода пользователя из системы файлы cookie fedauth, связанные с этим сеансом входа в систему, будут считаться просроченными. Обработчики WIF, похоже, не имеют встроенного механизма для отслеживания просроченных токенов, и я не нашел ничего другого, связанного с этим.
Я предполагаю, что это на самом деле более широкая проблема -> как вообще обнаружить просроченные куки? Действительный файл cookie - это действительный файл cookie!
Очевидное решение - как-то отслеживать эти файлы cookie после выхода из системы, но я бы хотел по возможности избежать использования пользовательского маршрута кода; Как новичок, во многих литературных источниках по безопасности говорится, что следует избегать кастомного кодирования любых механизмов сеанса, поскольку вы, вероятно, ошибетесь!
Кто-нибудь знает какие-либо стандартные решения этой проблемы в ASP.NET?
Заранее спасибо.