Как отследить просроченные куки-файлы WIF fedauth?

У меня интересная проблема с попыткой отслеживать истекшие сеансы аутентификации / файлы 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?

Заранее спасибо.


person oolong    schedule 13.04.2014    source источник


Ответы (2)


Вы не можете этого сделать, не ведя серверный список недавно отозванных токенов. Вот почему обычно мы полагаемся на неотъемлемое истечение срока действия, а также на HTTPS, чтобы предотвратить утечку / кражу токена.

person Brock Allen    schedule 15.04.2014
comment
Спасибо за этот @Brock Allen, это тот прагматичный ответ, который я частично искал. Вы бы сказали, что ваше заявление. Вот почему мы обычно полагаемся на неотъемлемый срок действия, а https - это обычная практика в Интернете? Я знаю, что независимо от каких-либо объяснений, которые я дам, они все равно будут просить меня предложить возможные решения для отслеживания просроченных токенов. Есть ли у вас / знаете какие-либо рабочие примеры этого ASP.NET? Оставшись наедине с собой, я бы, вероятно, предпочел использовать словарь для хранения токенов по какому-либо идентификатору, а затем выполнить поиск post-initial-auth ... - person oolong; 16.04.2014
comment
Да, срок действия встроенного токена - это способ предотвратить несанкционированный доступ. Если вы хотите отслеживать это, вы просто создаете базу данных токенов, пользователя и срок действия. - person Brock Allen; 16.04.2014
comment
Можете ли вы указать мне на рабочие примеры такой системы? Я много раз искал пример, но не нашел ничего связанного с какой-либо технологией. :( - person oolong; 16.04.2014
comment
Нет, я не знаю образцов - в своих приложениях я полагаюсь на срок годности. Но мне интересно, от чего вы пытаетесь защититься? Файл cookie есть только у пользователя (потому что вы должны использовать SSL). Так почему вы пытаетесь запретить пользователю кэшировать cookie и отвечать на него после того, как они заявят, что хотят выйти из системы? У них уже был доступ. - person Brock Allen; 16.04.2014
comment
Спасибо за ответы! Они беспокоятся не о пользователе. Они обеспокоены тем, что, если злоумышленник смог провести какую-либо атаку MITM (учитывая, что весь сайт защищен SSL), он мог бы воспроизвести запросы законных пользователей (которые содержат действительные токены) для выполнения вредоносных действий. повреждать. - person oolong; 17.04.2014
comment
Насколько я знаю (я ни в коем случае не эксперт), атаки с воспроизведением будут единственной успешной атакой MITM, которую вы могли бы осуществить с помощью защищенных SSL-запросов. В этом сценарии кража токенов в виде обычного текста невозможна. Имейте в виду, что в другом месте я также читал, что SSL имеет некоторую врожденную защиту от повторного воспроизведения сообщений. - person oolong; 17.04.2014
comment
Суть SSL заключается в аутентификации сервера, поэтому MITM не должен быть проблемой. - person Brock Allen; 18.04.2014
comment
@BrockAllen Вы все еще полагаетесь на HTTPS / Expiration в 2018 году для защиты файлов cookie? Изменилось ли что-нибудь за последние 4 года, чтобы сделать этот подход недействительным? - person foldinglettuce; 17.02.2018
comment
Изучите привязку токена HTTP. - person Brock Allen; 29.04.2018

Мне была поручена аналогичная просьба от нашей службы безопасности. Я решил сохранить идентификатор сеанса asp.net в файле cookie OWIN, и для каждого запроса, содержащего идентификатор сеанса в файле cookie, я проверяю, что он соответствует идентификатору активного сеанса.

Сохранить идентификатор сеанса в файле cookie (адаптировано из этого ответа) в конце первого запроса, который прошел проверку подлинности и не уже есть идентификатор сеанса в cookie:

protected override void OnActionExecuted(ActionExecutedContext filterContext)
    { 
        base.OnActionExecuted(filterContext);

        bool authenticated = User.Identity.IsAuthenticated;

        var sessionGuid = (User as ClaimsPrincipal).FindFirst("sessionID")?.Value;

        //put the SessionID into the cookie.
        if (authenticated && string.IsNullOrEmpty(sessionGuid))
        {
            var id= Session.SessionID;

            //update the guid claim to track with the session
            var authenticationManager = HttpContext.GetOwinContext().Authentication;

            // create a new identity from the old one
            var identity = new ClaimsIdentity(User.Identity);

            // update claim value
            identity.RemoveClaim(identity.FindFirst("sessionID"));
            identity.AddClaim(new Claim("sessionID", id));

            // tell the authentication manager to use this new identity
            authenticationManager.AuthenticationResponseGrant =
                new AuthenticationResponseGrant(
                    new ClaimsPrincipal(identity),
                    new AuthenticationProperties { IsPersistent = true }
                );
        }
    } 

Затем при каждом следующем запросе, если я найду сеанс в файле cookie, сравните его с активным сеансом. Если они не совпадают, выйдите из системы:

protected override void OnActionExecuting( ActionExecutingContext filterContext)
    {
        var claim = (User as ClaimsPrincipal).FindFirst("sessionID")?.Value;

        //does the owin cookie have a sessionID?
        if (!string.IsNullOrEmpty(claim))
        {
            string session = Session.SessionID;

            //does it match the one stored in the session?
            if(session != claim)
            {
                //no? log the user out again..
                Session.Abandon();

                //redirect to logged out page
                this.Request.GetOwinContext().Authentication.SignOut();

                //tell them its over..
                Response.Write("Expired Session");

                Response.End();
            }
        }

        base.OnActionExecuting(filterContext);
    }
person foldinglettuce    schedule 19.02.2018
comment
Есть ли у этого возможные непредвиденные побочные эффекты? Жизненный цикл вашего сеанса напрямую не связан с жизненным циклом ваших файлов cookie аутентификации, поэтому теперь вам нужно тщательно управлять двумя, чтобы предотвратить истечение срока действия одного раньше другого и т. Д. - person oolong; 27.06.2018
comment
@oolong Я предпочитаю ответ Брока, потому что у него нет описанных вами побочных эффектов. Мне не удалось убедить сотрудников службы безопасности в том, что ответ Брока был достаточно хорош, поэтому я решил добавить сюда свое решение для потомков. - person foldinglettuce; 07.07.2018