Браузеры игнорируют заголовок ответа Set-Cookie, если мы пытаемся установить cookie, который ранее был безопасным

Question

Я обнаружил странную проблему и понятия не имею, какой обходной путь необходимо применить.

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

Допустим, есть URL-адрес, по которому можно войти в систему: contoso.com/AutoLogin/

Если я открою его в режиме HTTPS, тогда файл cookie AUTH будетустановить и это безопасно:

GET https://contoso.com/AutoLogin/<user token>
Response: Set-Cookie: .ASPXAUTH=<cookie is here>; expires=Fri, 11-Oct-2019 14:51:40 GMT; path=/; secure; HttpOnly

Это совершенно нормально.Я вижу печенье в Dev Tools.Теперь в том же сеансе браузера, и я пытаюсь открыть тот же URL, но в HTTP-режиме.Запросы cookie-файлов больше не содержат AUTH-cookie - это ясно и предсказуемо из-за природы безопасных cookie-файлов.

GET http://contoso.com/AutoLogin/<user token>
Response: .ASPXAUTH=<here comes the cookie>; expires=Fri, 11-Oct-2019 14:54:07 GMT; path=/; HttpOnly

• no Безопасный флаг на этот раз - ОК.

Однако файл cookie не установлен, и все последующие запросы не имеют файла AUTH.Подтверждено поведение по крайней мере в Chrome и Firefox (не проверялось в других браузерах).

Как вы могли заметить, серверная часть реализована с использованием ASP.NET MVC.Возможно, может помочь тот факт, что запросы GET являются запросами AJAX.

Спасибо за помощь.

Answer 1

Я нашел прекрасную статью об этой проблеме.Вкратце:

Эта ситуация возникает, когда веб-сайт обслуживает запросы как через http (порт 80), так и через https (порт 443) и имеет безопасный флаг для файлов cookie https.

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

Автор заявляет для разныхПоведение браузера - некоторые браузеры допускают переопределение защищенных куки-файлов через незащищенные, некоторые нет.

И Chrome 71, и Firefox 64 предотвращают перезапись защищенного куки на обычном http.Я протестировал Edge 42, и он не работает так же, он перезапишет защищенный файл cookie незащищенным файлом cookie.Safari 12 работает аналогично Edge.

Полагаю, единственное решение - использовать веб-сайт только одним желаемым способом - защищенным или нет.