Переключение между страницами HTTP и HTTPS с безопасным cookie-файлом сессии - PullRequest
Новая
       23

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

28 голосов
/ 30 апреля 2011

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

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

  ...
?>

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

Большое спасибо за каждый ответ!

1 Ответ

24 голосов
/ 30 апреля 2011

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

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

...