Блог

Обновление: Обратите внимание, что каждый веб-сайт, переключающийся между незащищенными страницами HTTP и зашифрованными страницами HTTPS, неизбежно подвержен блокировке SSL. Пожалуйста, подумайте об использовании HTTPS для всего сайта, хотя это и не может предотвратить блокировку SSL, по крайней мере, это дает пользователю возможность безопасно заходить на сайт, если ему не все равно. Для сайтов, которым необходимо переключаться, этот метод, вероятно, по-прежнему является лучшим вариантом.

Это распространенный сценарий, когда на веб-сайте есть страницы с конфиденциальными данными, доступ к которым должен осуществляться только по протоколу HTTPS, и другие страницы с некритическими данными.

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

Проблема

HTTPS гарантирует, что никто между клиентом и сервером не сможет подслушать наше общение и предотвращает атаку «человек посередине». К сожалению, это не относится к сеансовому cookie, оно также отправляется на незашифрованные запросы.

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']))
    amp;amp; ($_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%. (Не могу найти цитату.)