Кэширование изображений, HTTPHandler и FormsAuthentication

Question

Настройка:

Я работаю на веб-сайте, который использует Formsauthentication, используя куки для хранения входного билета. На сайте также есть HTTPHandler, который управляет изображениями, хранящимися в базе данных. Обработчик кэширует изображения для публичного использования и истекает через 20 минут. Мы заметили, что, поскольку изображения имеют тот же жизненный цикл, что и страница, они также содержат файл cookie Formsauthentication. Конфигурация IIS 6, сервер Win2k, срок действия контента не включен.

Проблема:

Мы сталкиваемся с тем, что Персона А входит в систему и просматривает пару страниц. Затем Персона Б попадает на страницу по умолчанию, не входя в систему, и получает файл cookie для Персоны А и может видеть все данные Персона А. Мы однажды воспроизвели проблему, включив Истечение срока действия контента в IIS, но не воспроизвели последовательно, поэтому мы не уверены, что Истечение срока содержания помогло нам воспроизвести его. Мы предполагаем, что, поскольку изображения кэшируются как общедоступные, и они также содержат cookie с FormsAuthentication, для лица B каким-то образом возможно непреднамеренно получить cookie лица A. Мы знаем, что это не атака на сайт.

Кто-нибудь испытывал что-либо подобное этому поведению? Если да, можете ли вы дать какой-либо совет о том, как последовательно воспроизвести эту проблему?

Answer 1

Мы предполагаем, что файл cookie находится в заголовке ответа и записывает тот же файл cookie, который существует на компьютере пользователя A, для пользователя B. Важно отметить, что эта проблема возникла с человеком A в IE 7 и человеком B в FireFox. Кроме того, когда человек A вышел из системы, он также вышел из системы. Человек B также вышел из системы, поскольку билет Formsauthentication больше не действителен на сервере. Так что да, у них были разные файлы cookie, но один и тот же билет проверки подлинности форм в каждом из этих файлов cookie. Один был сгенерирован без входа в систему.

Мы также нашли эту статью, но не смогли подтвердить, является ли это причиной. http://support.microsoft.com/default.aspx?scid=kb;EN-US;917072

Я посмотрю, что LiveHTTP скажет мне и сообщит. Спасибо.

Answer 2

Может помочь установить Fiddler для проверки ваших http-запросов, как указано выше. Также убедитесь, что файлы cookie совпадают. Использует ли ваш обработчик или систему проверки подлинности форм статическую ссылку на объект? У вас может быть условие гонки в вашем коде. и неправильно блокируют ваши ресурсы.

Answer 3

Вы уверены, что на странице не включено что-то вроде кэширования вывода?

Answer 4

Весь трафик был по протоколу SSL ... при просмотре журналов IIS все проходило через порт 443. Единственное, что было установлено, - это общедоступные изображения, как упоминалось ранее. Мы предполагаем, что это является результатом кэширования выходных данных, вызывающим проблему.

Answer 5

Извините, я забыл упомянуть, что весь трафик проходил через порт 443 как SSL. Мы планируем удалить установленный файл cookie для изображений. Однако нас немного смущает, как это может произойти, когда весь трафик обрабатывается через SSL.

Answer 6

Конечно, если эти изображения (и CSS, и статические JS-файлы и т. Д.) Не используются в качестве HTTPS, они будут подвергаться кешированию со стороны интернет-провайдеров или других прокси-серверов (ну, на самом деле, кеширование), наряду их печенье.

Существует директива кэширования, похожая на эту:

Cache-control: no-cache="set-cookie,set-cookie2"

... который должен указывать кешам не кэшировать заголовки ответа "set-cookie", но я не уверен, насколько широко это поддерживается (несмотря на то, что это стандарт).

Избегайте использования заголовков ответов cookie-файлов при обработке изображений, если можете (возможно, это будет нелегко, если вы не полностью контролируете управление сеансом). Если для просмотра определенных изображений пользователь должен пройти проверку подлинности, эти изображения все равно не должны быть публично кэшированы.

Answer 7

Почему Лицо Б получает печенье Лица А? Я предполагаю, что вы имеете в виду, что сессионный cookie Персона Б связан с идентификатором входа А. Это суть проблемы.

Мне кажется, что идентификатор входа А хранится в месте, которое может пересекать запросы - например, во временном файле или в БД - без привязки его к cookie сеанса. (Связанная проблема: выходные данные страницы кэшируются, но неправильно связываются или извлекаются с помощью файла cookie сеанса.) Когда информация о сеансе сохраняется или кэшируется, она должна быть связана с файлом cookie. Думайте с точки зрения данных сеанса, принадлежащих браузеру, а не логину.

Я бы установил расширение Firefox LiveHTTP и проверил заголовки запроса / ответа. Держу пари, вы увидите, что A и B имеют разные куки, но на сервере они оба связаны с одним и тем же идентификатором входа.