Переключение между страницами HTTP и HTTPS с помощью безопасного сеанса cookie - программирование
Подтвердить что ты не робот

Переключение между страницами HTTP и HTTPS с помощью безопасного сеанса cookie

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

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

Я нашел решение, которое позволяет переключаться между безопасными и небезопасными страницами, сохраняя сеанс и хотел бы задать вам какие-либо намеки на недостатки в концепции. Вся статья вы можете найти здесь: Безопасный сеансовый файл с 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']))
    && ($_COOKIE['authentication'] === $_SESSION['authentication']);

  if (!$pageIsSecure)
  {
    // do not display the page, redirect to the login page
  }

  ...
?>

Злоумышленник может манипулировать файлом cookie сеанса, но он никогда не имеет доступа к файлу cookie аутентификации. Только человек, который ввел пароль, может владеть файлом cookie аутентификации, он всегда отправляется через зашифрованные HTTPS-соединения.

Спасибо за каждый ответ!

4b9b3361

Ответ 1

Простая альтернатива: она становится все более приемлемой альтернативой использованию TLS все время, вместо того, чтобы переключаться между безопасными и незащищенными соединениями. Основная часть дополнительного времени обработки тратится на создание защищенного туннеля, но это делается только один раз и кэшируется (обычно). Симметричное шифрование последующего трафика очень, очень быстро на современных процессорах. Это несколько устаревшее мышление, полагающее, что это вызовет проблему с избыточным или масштабируемым сервером.

В недавнем сообщении в блоге инженер Google сообщил, что, когда они перешли на HTTPS-only для GMail, они обнаружили, что их сервер подслушивает увеличение всего на 4%. (Не могу найти цитату.)