Должен ли SessionID в QueryString или Cookie запроса GET иметь приоритет?

Question

Если я получаю запрос к URL host.com/site-directory/page-slug.html?session={someValidNonExpiredSessionGuid} и обнаруживаю файл cookie сеанса со значением: {someOtherValidNonExpiredSessionGuid}, то

Какой сеанс является правильным сеансом, который нужно связать с запросом?

Вот несколько предысторий:

Шаблон, который я использую для поддержания состояния в HTTP-запросах, заключается в сохранении уникального идентификатора в строке запроса, коллекции форм и / или cookie.Затем при каждом запросе я нахожу уникальный идентификатор и дату извлечения из таблицы базы данных.Если идентификатор недействителен или сеанс истек, будет создан новый сеанс (с новым идентификатором, новым файлом cookie и т. Д.).

Поведение по умолчанию состоит в том, что все формы будут иметь поле:

 <input type="hidden" name="session" value="{someGuid}" />

Все ссылки на другие страницы сайта будут иметь добавленный параметр строки запроса

 <a href="site-directory/page-slug.html?session={someGuid}">a sample link</a>

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

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

Однако у меня концептуальная концепция.проблема при принятии решения о том, должен ли параметр сеанса строки запроса иметь приоритет над значением cookie или наоборот.Кажется, что я мог бы получить плохие данные в любом случае.Я мог бы получить данные с неверным параметром строки запроса, если бы пользователь добавил в закладки страницу с параметром сеанса, включенным в URL.Я также мог бы получить неверные данные из cookie, если пользователь закрывает браузер, не завершая сеанс, и окно истечения сеанса еще не закрылось.Также кажется, что оба варианта могут быть уязвимы для злоумышленника, перехватывающего запрос и отправляющего запрос с той же информацией о сеансе.

Итак, еще раз, мой вопрос

Если я получузапрос к URL host.com/site-directory/page-slug.html?session={someValidNonExpiredSessionGuid}, и я обнаружил файл cookie сеанса со значением: {someOtherValidNonExpiredSessionGuid}, затем Какой сеанс является правильным сеансом, который нужно связать с запросом?

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

В дополнение к основному вопросу, я ценю любое понимание любых связанных с безопасностью или логических упущений, которые я выразил в этом описании. Прошу прощения за длинный пост, но посчитал необходимым объяснить ситуацию.Большое спасибо за ваш вклад.

Кроме того, это не обязательно относится к вопросу, но в большинстве случаев я использую ASP.NET MVC и вручную устанавливаю файлы cookie с помощью Response.Cookies.

Answer 1

С точки зрения безопасности сеансы не должны храниться в строках запроса.

Например: если сеансы хранятся в запросах и вы ссылаетесь на удаленный хост на той же странице, допустимый сеанс пользователей может быть отправлен на удаленный хост через заголовок реферера.

Сеансывсегда должны храниться в куки.

Answer 2

Если я получу запрос к URL-адресу host.com/site-directory/page-slug.html?session= enjsomeValidNonExpiredSessionGuid} и обнаружу файл cookie сеанса со значением: {someOtherValidNonExpiredSessionGuid}, то какой сеансправильный сеанс для связи с запросом?

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

Единственный способ использовать строку запросов для передачи информации о сеансе - это использовать метод резервного копирования дляустановить сеанс браузера на новый экземпляр браузера.Вот сценарий: у вас есть активный сеанс с использованием браузера A на компьютере A, который терпит катастрофическую ошибку.Вы хотите восстановить этот же сеанс на другом экземпляре браузера на том же компьютере или на другом компьютере.Если ваш программный код может распознать, что cookie-файл сеанса не существует, но в строке запроса существует действительный идентификатор сеанса, вы могли бы инициировать ответ-вызов, чтобы проверить целостность этого идентификатора сеанса, а затемперенести новый сеансовый файл cookie на новый компьютер.Это, на мой взгляд, крайность, но функциональность может быть полезна в определенных ситуациях.

ДОБАВЛЕНО: Я понимаю, что вы можете разместить пользователей, которые отключили файлы cookie в своих браузерах, и хотя вы можете используйте строку запроса для хранения идентификатора сеанса, который я рекомендовал бы против него.Но если вам нужно, зашифруйте эту присоску, используя информацию, специфичную для браузера.

Answer 3

Я бы тоже склонялся к использованию идентификатора сеанса cookie в случае неоднозначности.Это в первую очередь потому, что я уверен, что реализация cookie-файлов будет более хорошо выпеченной, более проверенной и более идиотской, чем моя собственная реализация отслеживания сеансов.Например, есть случаи, когда ASP.NET автоматически знает, как очистить сеансовые куки, обновить их и т. Д.

Кроме того, я бы разработал так, чтобы куки не были постоянными, чтобы минимизировать пограничные случаи.Если пользователь закрывает браузер, то сеанс закрывается.

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

Мысли?

Любопытно ... Какова была ваша причина исключить использование стандартной реализации сеанса ASP.NET без файлов cookie?- http://msdn.microsoft.com/en-us/library/aa479314.aspx#cookieless_topic2

Answer 4

Вы должны попытаться сохранить его в куки (глядя на заглавные буквы браузера, чтобы увидеть, поддерживает ли браузер куки), а затем вернуться к строке запроса.