Как убить файл .ASPXAUTH cookie на сервере?

Question

Я НЕ разработчик, но тестер проникновения. Выполняя пентет на веб-сайте на базе .NET, я сообщил об ошибке «Неправильное управление сеансом». Пользователь получал аутентификацию с помощью файла cookie .ASPXAUTH. Что происходит, когда пользователь выходит из системы, значение cookie .ASPXAUTH устанавливается в пустом браузере клиента. Но если вы используете тот же самый .ASPXAUTH, поместите его в браузер вручную и обновите страницу, пользователь напрямую получает аутентификацию.

Я рекомендовал разработчикам, чтобы файл cookie .ASPXAUTH был уничтожен на сервере, как только пользователь выйдет из системы. Но они предположили, что файлы cookie и связанные с сеансом полностью управляются с помощью фреймворка, и его невозможно убить на сервере.

Итак, есть ли способ убить .ASPXAUTH на сервере?

Спасибо заранее

Answer 1

Так есть ли способ убить .ASPXAUTH на стороне сервера?

Нет, это невозможно сделать, поскольку ASP.NET FormsAuthentication не связана ни с одним из состояний на сервере. Это один из его слабых мест. Что вы можете сделать, так это связать этот файл cookie с состоянием сеанса, которое будет сохраняться на сервере. Таким образом, чтобы быть аутентифицированным, недостаточно иметь допустимый файл cookie для проверки подлинности, но в дополнение к этому он должен относиться к некоторому состоянию на сервере, которое может быть недействительным в любое время (например, при выходе из системы). В этом случае после того, как пользователь выйдет с веб-сайта, он больше не сможет использовать cookie .ASPXAUTH, полагая, что он зафиксировал его значение, пока он был аутентифицирован.

Answer 2

Чтобы развернуть ответ Дарина, веб-формы Cookie auth не имеют гражданства. Ваш клиент прав, заявив, что структура делает много «магии» под обложками. Это не значит, что клиент ничего не может с этим поделать.

По умолчанию cookie Forms Auth не имеет гражданства. Он включает в себя какой-то идентификатор (имя пользователя, идентификатор пользователя, это зависит от разработчика), и это все. Есть много свойств, которые вы можете установить в cookie (это cookie сеанса, как долго это хорошо и т. Д.), Но это не влияет на то, как обрабатывается содержимое cookie. Содержимое cookie затем зашифровывается и MACed с помощью машинного ключа, поэтому их нельзя подделать, но это не мешает им переноситься или воспроизводиться.

Клиент может продолжать использовать аутентификацию форм, если они этого хотят, им просто нужно немного отступить от всей магии.

Предполагаю, что под обложками они делают что-то вроде FormsAuthentication.SetAuthCookie. Вместо этого они могут создать FormsAuthenticationTicket, который позволяет включать данные, предоставленные пользователем. Эти данные могут быть связаны с сеансом (не обязательно, сеансом HTTP). Затем используйте FormsAuthentication.Encrypt для шифрования билета, и он возвращает cookie, который можно установить на успешном ответе на аутентификацию.

Когда страница загружается (или еще лучше в Global.asax Application_AuthorizeRequest), они могут захватить файл cookie из запроса, вызвать FormsAuthentication.Decrypt, чтобы дешифровать файл cookie аутентификации и проверить, соответствуют ли данные пользователя сеансу.

Когда пользователь явно выдает отчет, очистите сеанс от этого пользователя, чтобы он больше не соответствовал файлу cookie. Затем проверка пользовательских данных должна отклонять файл cookie и заставлять их приобретать новый.