Кажется нежелательным поддерживать сеанс между HTTP и HTTPS, используя один и тот же файл cookie или URLтокен.
Представьте себе случай, когда ваш пользователь вошел в систему, когда данный cookie-файл (или URL-токен) передается взад-вперед для каждого запроса / ответа на веб-сайте электронной коммерции.Если кто-то посередине может прочитать этот cookie, он может войти с ним в HTTP или HTTPS-вариант сайта.Даже если все, что законный пользователь делает затем, работает по протоколу HTTPS, злоумышленник все равно сможет получить доступ к этому сеансу (поскольку у него тоже будет допустимый файл cookie).Он мог видеть такие страницы, как корзина, способ оплаты, возможно, изменить адрес доставки.
Имеет смысл передавать некоторую форму токена между сеансом HTTP и сеансом HTTPS (если вы используете сеансы),но отношение к ним как к одному и тому же может привести к некоторой уязвимости.Создание одноразового токена в параметре запроса просто переход может быть решением.Однако вы должны относиться к ним как к двум отдельным аутентифицированным сеансам.
Эта уязвимость иногда может возникать на веб-сайтах, которые используют смешанный контент HTTP и HTTPS (некоторые браузеры, такие как Firefox, будут предупреждать вас об этом, хотя большинство людей склоннычтобы отключить его в первый раз, когда он всплывает).У вас может быть файл cookie сеанса HTTPS для главной страницы, но эта страница содержит изображения для логотипа компании через обычный HTTP.К сожалению, браузер отправляет cookie для обоих (так что злоумышленник сможет использовать cookie).Я видел, как это происходит, даже если рассматриваемого изображения даже не было (браузер отправлял запрос с cookie на сервер, даже если он возвращал 404 не найденных).