Когда браузеры, такие как IE 11, Firefox 26, Chrome 32 и т. Д., Получают Cookie через небезопасное (HTTP) соединение, которое имеет "Безопасный» указанный атрибут, они сохраняют куки и отправляют их обратно, как только они делают запрос на тот же сервер через безопасное (HTTPS) соединение.

Хотя это, вероятно, согласуется с некоторой спецификацией (я полагаю, файлы cookie Netscape), мне интересно, открывает ли это дополнительную дыру в безопасности (фиксация сеансов) для сайтов, защищенных SSL.

Рассмотрим следующий сценарий:

Пользователь (имеющий чистое / не содержащее вредоносных программ клиентское устройство) хочет получить доступ к веб-сайту с именем пользователя и паролем через незащищенную сеть (например, незашифрованную точку доступа WiFi), где злоумышленник может прочитать и изменить все данные, отправленные через него. сеть. Пусть DNS-имя сайта будет.www.example.com

Пользователь знает, что когда этот веб-сайт просит его ввести пароль, чтобы всегда искать, если браузерs адресная строка содержит значок блокировки SSL перед вводом пароля.

Веб-сайт:

обеспечивает доступ ко всем его страницам и ресурсам через SSL / TLS. Это означает, что как только пользователь заходит на страницу, используя https, все внутренние ссылки на этой странице являются ссылками https, так что они этого не делают ».понижаем» соединение от HTTPS к HTTP. Также он не содержит смешанного (HTTP / HTTPS) контента.перенаправляет пользователя с HTTP на HTTPS с кодом состояния 301, если пользователь получает доступ к одной из своих страниц через HTTP.сохраняет информацию для входа в Session Cookie.гарантирует, что все файлы cookie (включая файлы cookie сеанса), отправленные клиенту, отправляются только через безопасное (HTTPS) соединение, и что они всегда устанавливают "Безопасный» а также "HttpOnly» атрибутов.принимает только идентификаторы сеанса, которые были сгенерированы сайтом и отправлены клиентом через cookie, который имеет "Безопасный» набор атрибутов (веб-сайт непринимать идентификаторы сессий из URL и т. д.)защищен от CSRF путем установки пользовательского токена в формах HTML, который проверяется сервером, когда пользователь отправляет запрос POST.защищен от XSS путем правильного кодирования всех строк, которые выводятся в виде HTML.делаетне реализовать HSTS, или пользовательБраузер не поддерживает HSTS (например, IE, Safari).делаетне изменить идентификатор сеанса (значение файла cookie сеанса), когда пользователь входит в систему.

Теперь представьте, что злоумышленник запускает программу, которая перехватывает все данные, отправленные по незащищенным HTTP-запросам, и, если это HTML-страницы, вставьте фрагмент, который заставляет браузер отправлять HTTP-запрос на www.example.com, как невидимый img. или тег iframe:

<img src="http://www.example.com/" style="display: none;">

Затем злоумышленник посещаетhttps://www.example.com/ самостоятельно, чтобы получить сессионный cookie, сгенерированный сервером, и продолжает просматривать сайт, чтобы поддерживать сеанс в живых. Затем он также изменяет HTTP-запросы пользователяwww.example.com включить тот же cookie сеанса в ответ HTTP, который злоумышленник только что получил с сервера. Печенье имеет "Безопасный» флаг установлен.

Теперь представьте, что пользователь посещает некоторые обычные HTTP-сайты, которые неt передавать конфиденциальные данные и, следовательно, не имеют SSL. Это означает, что пользовательБраузер получит сессионный cookie, отправленный злоумышленником по этим запросам.

Позже пользователь хочетhttps://www.example.com/ и хочет войти в систему. Он просматривает адресную строку, чтобы убедиться, что отображается значок SSL, и, поскольку это так, входит в систему со своим паролем. Однако, потому что злоумышленник зациклил пользователясессия, отправив куки с "Безопасный» Причиняя атрибут небезопасного HTTP-запроса ранее, злоумышленник теперь имеет доступ к пользователю.состояние сеанса.

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

Мое впечатление об этом браузереПоведение состоит в том, что он вводит дополнительный сценарий фиксации сеанса, как описано выше. Единственный способ предотвратить это - изменить идентификатор сеанса при каждом запросе (для HTML-страницы).

Я что-то здесь упускаю?

На мой взгляд, если браузер отклонит файлы cookie, которые имеютБезопасный» атрибут установлен, но был отправлен по небезопасному HTTP-соединению, злоумышленник не смог бы:

внедрить файл cookie сеанса в пользователябраузер, имеющий "Безопасный» атрибут, установленный браузером, отклонит его, и(РЕДАКТИРОВАТЬ: не применимо) внедрить файл cookie сеанса в пользователябраузер, который не имеет "Безопасный» атрибут, так как веб-сайт будет игнорировать куки без "Безопасный» приписывать.

Это избавило бы от необходимости для конкретного веб-сайта изменять идентификатор сеанса с каждым запросом.

РЕДАКТИРОВАТЬХорошо, одна вещь, которую я пропустил, это то, что браузеры, похоже, не отправляютБезопасный» атрибут в заголовке Cookie обратно на сервер, поэтому сервер не может определить, был ли этот cookie установлен для клиентабраузер с "Безопасный» приписывать.

Но это будет означать, даже если браузеры будут отклонять куки с "Безопасный» флаг на соединениях без SSL, злоумышленник может установить cookie без "Безопасный» флаг, который затем принимается сайтом по запросам HTTPS, как можетпроверить "Безопасный» флаг печенья.

Есть идеи?

Спасибо!