Сессия потеряна при переключении с HTTP на HTTPS в PHP

Это может быть невозможно, поскольку файл cookie, похоже, теряется. Используемый вами браузер должен думать, что он предназначен для совершенно другого домена.

Какой браузер вы конкретно используете?

По умолчанию я ожидаю, что браузер будет рассматривать подключения к http и https как совершенно разные сеансы. Хотя по соглашению http: // someUrl / и https: // someUrl / будут указывать на одну и ту же страницу, это не гарантируется. У вас могут быть совершенно разные сайты, работающие на портах 80 (http) и 443 (https).

Я не знаю PHP, но в целом я не ожидал бы, что переменные сеанса будут свободно доступны между безопасными и незащищенными сеансами, например. Я бы не ожидал, что номер кредитной карты из моей последней проверки будет доступен для всех последующих незащищенных страниц, которые я посещаю.

Простите неавторитетный ответ, но я подумал, что брослю свой 2c, так как ответов не так много.

Когда вы переключаетесь между службами HTTP и HTTPS на одном сервере, ваш идентификатор сеанса HTTP не передается сеансу HTTPS. Вы можете установить его, передав идентификатор сеанса со страницы HTTP на страницу HTTPS одним из трех возможных способов:

От PHP: session_start:

session_start() creates a session or resumes the current one based on the current session id that's being passed via a request, such as GET, POST, or a cookie

Когда вы используете сеансы, вы обычно запускаете свой сценарий с session_start(). Если в браузере установлен файл cookie идентификатора сеанса, session_start() будет использовать этот идентификатор сеанса. Если в браузере не установлен файл cookie с идентификатором сеанса, session_start() создаст новый.

Если идентификатор сеанса не установлен (в вашем примере браузер создает новый файл cookie идентификатора сеанса для сеанса HTTPS), вы можете установить его с помощью функции session_id(). session_id() также удобно возвращает идентификатор сеанса в виде строки. Так

...

$currentSessionID = session_id();

...

устанавливает переменную $currentSessionID, равную идентификатору текущего сеанса, и

...

session_id($aSessionID);

...

устанавливает файл cookie идентификатора сеанса в браузере на $aSessionID. из PHP: session_id

Вот пример с двумя скриптами. Доступ к одному осуществляется через HTTP, а к другому - через HTTPS. Они должны находиться на одном сервере для хранения данных сеанса.

Скрипт 1 (HTTP):

<?php

// This script will create a session and display a link to your secure server address
// to transfer your session ID. In this example, the secure page to receive the session
// ID is located at http://www.yoursite.com/safePages/securePage.php

// Start a session using the current session ID stored in a cookie, or create
// a new session if none is set.
session_start();

$currentSessionID = session_id();

// Set a variable that will be retrieved with the HTTPS script.
$_SESSION['testvariable'] = 'It worked';

// $secureServerDomain is the domain of your secure server
$secureServerDomain = 'www.yoursite.com';

// $securePagePath is the path to the page that will receive and set the session ID.
$securePagePath = '/safePages/securePage.php'

echo '<a href = "https://' . $secureServerDomain . $securePagePath . '?session = "' . $currentSessionID . '">Click here to transfer your session to the secure server</a>';

?>

Скрипт 2 (HTTPS):

<?php

// Retrieve the session ID as passed via the GET method.
$currentSessionID = $_GET['session'];

// Set a cookie for the session ID.
session_id($currentSessionID);

// Start a session.
session_start();

// Test retrieval of variable set when using HTTP.
if (!empty($_SESSION['testvariable'])) {
      echo $_SESSION['testvariable'];
} else {
      echo 'It did not work.';
}

?>

Чтобы это работало, серверы HTTP и HTTPS должны использовать одну и ту же подложку для хранения данных сеанса (т.е. для обработчика файлов по умолчанию, запускаемого на одном физическом компьютере с одним и тем же файлом php.ini). Здесь есть некоторые недостатки безопасности, поэтому я бы не стал использовать этот код для передачи конфиденциальной информации. Это просто как работоспособный пример.

Когда я раньше сталкивался с этой проблемой, я предлагал описанное выше как быстрое решение, но я просто вспомнил первоначальную причину проблемы. Я переходил с http://www.example.com/page.php на https://example.com/page.php (обратите внимание на отсутствие www). Убедитесь, что http://www.example.com/page.php будет ссылаться на https://www.example.com/page.php, а http://example.com будет ссылаться на https://example.com/page.php.

PS, на самом деле я не запускал эти сценарии, поэтому может быть одна или две опечатки, которые не позволяют им работать должным образом, как есть.

Похоже, файл cookie сеанса настроен на безопасность. Файлы cookie имеют флаг "безопасный", который, если установлен в значение true, означает, что файл cookie не будет отправлен на сайты, не использующие https. PHP, вероятно, использует это для своих файлов cookie сеанса. Вы можете изменить это с помощью функции session_set_cookie_params или с помощью параметра session.cookie_secure в php.ini.

Похоже, ваш файл cookie сеанса создан с флагом безопасности, но есть что-то с URL-адресом вашей страницы оформления заказа, из-за чего файл cookie сеанса не передается.

Или, возможно, ваш файл cookie сеанса небезопасен - просто URL-адрес страницы оформления заказа достаточно отличается (http://mysite.com против http://www.mysite.com), чтобы браузер не отправлял cookie.

Если вы хотите узнать больше о переходе с http на https и наоборот - взгляните на в моей записи на выборочном ssl :-)

У нас тоже была эта проблема. Оказалось, это потому, что мы использовали патч Сухосин в нашей установке PHP. Исправляем, установив suhosin.session.cryptdocroot = Off в /etc/php.d/suhosin.ini.

Для руководства suhosin о suhosin.session.cryptdocroot см. http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptdocroot.

Первоначально мы нашли исправление из этого сообщения в блоге: http://www.yireo.com/blog/general-news/315-switch-between-http-and-https-looses-php-session.

Вы не можете передавать значения сеанса между разными доменами. Вы должны использовать http post-get или базу данных для передачи ваших значений. В целях безопасности вы можете объединить все свои значения в строку и использовать

sha1($string)

и разместите его вместе со своими значениями и вычислите sha1 для значений, которые получает другая страница, а затем сравните хэши.

Метод публикации в разных доменах заставляет браузеры отображать сообщение безопасности, поэтому не используйте его.

Использование URL-адреса для метода get небезопасно, вам нужно будет запросить пароль на перенаправленной странице, чтобы разрешить получение параметров в вашей системе.

Не используйте файлы cookie, если вам нужна безопасность.

Я предлагаю сохранить значения в базе данных и сгенерировать ключ, затем сделать ссылку перенаправления, используя свой ключ, перенаправить страницу пользователей с параметром get, который имеет ключ, затем пользователь страницы перенаправляется, чтобы получить этот ключ , извлекает данные и удаляет ключ. вы можете сгенерировать ключ с помощью sha1

PAGE 1---
$key=sha1($allvalsconcat);
//insert your session values to a database also the key in a column
header("Location: page2.php?key = ".$key);

PAGE 2---
// select from database where key=$_GET["key"];
// delete from table where key=$key

это довольно безопасно.

что может случиться: сценарий, вводящий случайные значения для параметра «ключ», чтобы ваш сайт загружал данные в вашу память?

Этого не произойдет, потому что вы удалите запись после ее использования. Распространенное заблуждение состоит в том, что значения get небезопасны, и их всегда следует избегать.

вы можете установить тип движка таблицы в mysql, если хотите добиться максимальной производительности.

Следующее решение предполагает, что безопасные и незащищенные серверы имеют доступ к одним и тем же внутренним службам (кеш, хранилище базы данных и т. д.).

Нам приходилось сталкиваться с этой же проблемой при отправке пользователя в наш процесс оформления заказа, когда он делал покупки. Чтобы решить эту проблему, мы создали слой кеширования и кэшировали все соответствующие данные. Например, мы могли бы извлечь идентификаторы продукта и идентификатор пользователя из значений сеанса, сериализовать их, создать хэш и, наконец, сохранить данные сеанса в кеше, используя хеш в качестве ключа. Затем мы перенаправляем пользователя на защищенный сайт с хешем в URL-адресе.

Когда пользователь оказывался на защищенном сайте, мы пытались извлечь данные из кеша на основе хэша. Затем, используя идентификатор пользователя и идентификаторы продукта, мы можем загрузить все данные о ценах и описании из базы данных и представить пользователю для окончательной проверки.

Существует риск наследования в том, что данные кеша изменчивы, но у нас никогда не было проблем с ними, поскольку перенаправление происходит быстро.

Не волнуйтесь, это нормальное поведение, потому что HTTPS предназначен для обеспечения безопасности и выполняет свою часть работы.

Ниже приведены некоторые приемы, с помощью которых вы можете поддерживать сеанс при переключении с HTTP на HTTPS.

1. Передача идентификатора сеанса между страницами с помощью GET

2. Идентификатор сеанса POST по POST

3. Используйте файлы для сохранения сессий

4. Используйте файлы cookie для сеансов

5. Использовать базу данных для сохранения сеанса

Надеюсь, вы что-то получите из моего ответа.

Я бы порекомендовал, в дополнение к тому, что большинство заявило здесь о передаче зашифрованной информации, смотреть на нее так же, как если бы вы передавали конфиденциальную информацию через сторонний API. Как узнать, что кто-то не подделывает запрос? Существует множество протоколов для подлинного подтверждения подлинности запроса, в зависимости от того, насколько чувствительны ваши настройки. Вы открываете себя для взлома учетных записей, если не будете осторожны.

Даже если он находится на том же сервере, учтите следующее:

Когда кто-то переходит по ссылке, действию формы и т. д., Которые передают зашифрованный ключ, что может помешать кому-то его обнюхать ДО того, как они попадут на защищенную версию вашего сайта? Если бы я был в общественном месте с WIFI, это было бы не слишком надуманно. Я мог бы притвориться вашим сайтом, перенаправить запросы на свой ноутбук, захватить токен и перенаправить посетителя обратно туда, где они пришли. Они подумали бы, что это сбой, и не знали бы. Теперь я могу войти в систему под их именем и, возможно, пойти купить вещи на 10 000 долларов с их кредитной картой и отправить их куда-нибудь еще. Степень осторожности, которую вы здесь принимаете, должна соответствовать степени чувствительности.

Кроме того, убедитесь, что срок действия ваших токенов истекает (только одно использование, через X секунд и т. д.), Но я бы также подумал об использовании шаблона Post-Redirect-Get на обоих концах, то есть:

Не показывать прямую ссылку на странице или в виде незащищенного сайта, но показывать ссылку, которая затем будет перенаправлять на серверную часть (и обрабатывать все токены / шифрование). Когда вы перейдете к защищенной версии, сделайте то же самое (не оставляйте параметр "? Token = asdfjalksfjla" просто так в URL-адресе; перенаправьте его).

Итак, формальные системы на основе токенов были разработаны для решения этой самой проблемы, но реализация OAuth только для этого может быть излишним. Потратьте некоторое время на планирование потенциальных уязвимостей перед выполнением. То, что угадать токен будет очень трудно, не означает, что это невозможно (или не может быть коллизий и т. д.), Поэтому планируйте соответственно.

Вам также может потребоваться более сложная система управления сеансом, чем встроенные обработчики PHP. Я не знаю, можете ли вы заставить PHP продолжать сеанс через несколько посещений (так обрабатывается переключение протоколов).

Подумайте об использовании HTTPS для всех страниц, это самый простой способ избежать этой проблемы и повысит безопасность вашего сайта.

Если SSL для всех страниц вам не подходит, вы можете использовать этот подход: Переключение между страницами HTTP и HTTPS с помощью безопасного файла cookie сеанса. Идея заключается в том, что вы оставляете файл cookie сеанса незащищенным (и, следовательно, доступным для страниц HTTP и HTTPS), но имеете второй безопасный файл cookie для обработки аутентификации. Это хороший способ разделить две проблемы: «поддержание сеанса» и «аутентификация».

Вы можете управлять сеансом между HTTP и HTTPS или HTTPS и HTTP:

1. Передача идентификатора сеанса между страницами с помощью GET

2. Идентификатор сеанса POST по POST

3. Используйте файлы для сохранения сессий

4. Используйте файлы cookie для сеансов

5. Использовать базу данных для сохранения сеанса

Пример ниже можно использовать для передачи с помощью GET….

Файл: http.php ……………

<?php

session_start();

$sessionID = session_id();

$_SESSION['demo'] = ‘Demo session between HTTP HTTPS’;

echo ‘<a href=”https://www.svnlabs.com/https.php?session=’.$sessionID.’”>Demo session from HTTP to HTTPS</a>’;

?>

Файл: https.php ……………

<?php

$sessionID = $_GET['session'];

session_id($sessionID);

session_start();

if (!empty($_SESSION['demo'])) {
echo $_SESSION['svnlabs'];
} else {
echo ‘Demo session failed’;
}

?>

IE7: эта страница содержит как безопасные, так и небезопасные элементы.

Вы должны использовать относительный путь для всех статических ресурсов на странице, таких как css, js, images, flash и т. д., Чтобы избежать безопасных и небезопасных элементов сообщений IE ...

Сообщение IE

У вас есть выделенный IP? в некоторых общих средах https и http маршрутизируются через разные серверы, поэтому при переключении фактически теряется доступ к файлам cookie, поскольку они находятся в разных доменах.

решения будут: выделенный IP

принудительное использование https на всех страницах в любое время

У меня была аналогичная проблема, однако это решение было для меня хорошим, возможно, поможет другим в будущем

добавьте это в свой php.ini

suhosin.session.cryptdocroot = Выкл.

suhosin.cookie.cryptdocroot = Выкл.

У меня есть решение ... Попробуй.

$_SESSION['test'] = 'test';
session_regenerate_id(true);

header("Location: /");// the header must be sent before session close
session_write_close(); // here you could also use exit();

У меня была эта проблема при переходе с http на https, и я смог решить эту проблему, изменив URL-адрес веб-сайта с http://example.com на https://www.example.com

добавление www к URL-адресу решило эту проблему для меня.

Спасибо.