Обновление: обратите внимание, что каждый веб-сайт, переходящий между незащищенными HTTP и зашифрованными страницами HTTPS, неизбежно подвержен SSL-полосе . Пожалуйста, подумайте об использовании HTTPS для всего сайта, хотя это не может предотвратить SSL-полосу, по крайней мере, это дает пользователю возможность безопасно звонить на сайт, если он заботится. Для сайтов, которые необходимо переключить, этот метод, вероятно, по-прежнему является наилучшим вариантом.
Это распространенный сценарий, что на веб-сайте есть страницы с конфиденциальными данными, к которым следует обращаться только с протоколом HTTPS, а другие – с некритичными данными.
Я нашел решение, которое позволяет переключаться между безопасными и небезопасными страницами, сохраняя сеанс и хотел бы попросить вас о каких-либо намеках на недостатки в концепции. Вся статья, которую вы можете найти здесь: Secure session cookie с SSL (конечно, я также рад слышать, что это безопасно).
Проблема
HTTPS гарантирует, что никто между клиентом и сервером не сможет подслушивать наше общение и предотвращает нападение «человек в середине». К сожалению, это не относится к сеансовому файлу, он также отправляется в незашифрованные запросы.
PHP предлагает функцию session_set_cookie_params (…) с параметром $ secure. Это то, что нам нужно, но это оставляет нам проблему, что мы теряем нашу сессию, когда переходим на незащищенную страницу.
Файл cookie аутентификации
Идея файла cookie для проверки подлинности заключается в том, что, когда пользователь вводит свой пароль (увеличивает свои права доступа), мы создаем второй файл cookie дополнительно к незащищенному cookie-сеансу и следим за тем, чтобы к нему были доступны только зашифрованные HTTPS-страницы.
https://www.example.com/login.php <?php session_start(); // regenerate session id to make session fixation more difficult session_regenerate_id(true); // generate random code for the authentication cookie and store it in the session $authCode = md5(uniqid(mt_rand(), true)); $_SESSION['authentication'] = $authCode; // create authentication cookie, and restrict it to HTTPS pages setcookie('authentication', $authCode, 0, '/', '', true, true); print('<h1>login</h1>'); ... ?> Теперь каждая страница (HTTPS и HTTP) может читать небезопасный файл cookie сеанса, но страницы с конфиденциальной информацией могут проверять файл cookie с защищенной аутентификацией.
https://www.example.com/secret.php <?php session_start(); // check that the authentication cookie exists, and that // it contains the same code which is stored in the session. $pageIsSecure = (!empty($_COOKIE['authentication'])) && ($_COOKIE['authentication'] === $_SESSION['authentication']); if (!$pageIsSecure) { // do not display the page, redirect to the login page } ... ?>
Злоумышленник может манипулировать файлом cookie сеанса, но он никогда не имеет доступа к файлу cookie аутентификации. Только человек, который ввел пароль, может владеть файлом cookie аутентификации, он всегда отправляется через зашифрованные HTTPS-соединения.
Большое спасибо за каждый ответ!
Более простая альтернатива: она становится все более приемлемой альтернативой использованию TLS все время, вместо того, чтобы переключаться между безопасными и незащищенными соединениями. Основная часть дополнительного времени обработки тратится на создание защищенного туннеля, но это делается только один раз и кэшируется (обычно). Симметричное шифрование последующего трафика очень, очень быстро на современных процессорах. Это несколько устаревшее мышление, чтобы полагать, что это вызовет проблему с избыточным или масштабируемым сервером.
В недавнем сообщении в блоге инженер Google сообщил, что, когда они перешли на HTTPS-only для GMail, они обнаружили, что их сервер подслушивал увеличение всего на 4%. (Не могу найти цитату.)