Как полностью (я имею в виду ПОЛНОСТЬЮ) уничтожить все данные сеанса и предотвратить кешированный доступ? - PullRequest
0 голосов
/ 26 января 2019

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

Мне удалось полностью уничтожить все данные сеанса, сохраненные на сервере, а также переименовать и очистить файлы cookie сеанса (см. Код ниже). К сожалению, этого недостаточно, кажется. Я все еще могу получить доступ к странице, передав старый идентификатор сессии через переменную GET, и я все еще могу загрузить страницу. Я подозреваю, что это кэшированная версия. Я попытался добавить заголовки php, чтобы предотвратить это, но он все еще загружается!

Код выхода:

<?php

if ($_POST) {
    session_start($_POST["SID"]);
    $_SESSION[] = array();

    setcookie( session_name(), "", time()-3600, "/" );

    session_destroy();
    session_write_close();
    echo("Session ".$_POST["SID"]." has been destroyed");
}
?>

Код заголовка:

<?php
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
?>

Я ожидал, что смогу нажать кнопку выхода из системы, и если бы я попытался вручную получить доступ к странице, указав старый идентификатор сессии с помощью команды GET, я должен был быть отклонен этой страницей. Есть ли способ обойти это? Может быть, вынудите страницу повторно запросить сервер (если я могу просто заставить его пинговать сервер снова, я считаю, что мой php должен отклонить запрос? Я говорю это с некоторой нерешительностью, хахаха )

EDIT:

Хорошо, так что после долгих отладок я сузил проблему и до моей $_SESSION["IS_AUTHORIZED"] переменной? Это не должно быть возможным, но каким-то образом автономный скрипт PHP, который я написал для уничтожения сеанса, когда пользователь выходит из системы, может запустить тот же session_id(), но каким-то образом не может получить доступ ни к одной из переменных сеанса ?! если я var_dump($_SESSION["IS_AUTHORIZED"]), он выплевывает NULL, тогда как на всех других страницах он выплевывает логическое значение 0 или 1?!?!?! Я очень смущен ... Наверное, поэтому я не могу правильно удалить сеанс?

Код:

<?php
if ($_POST) {
    session_id($_POST["SID"]);
    echo(session_id()); //comes out as same as session origin page
    session_start();
    echo("|||"); //to make payoad easier to read lol
    echo($_SESSION["IS_AUTHORIZED"]); //nothing... and var_dump() is NULL?
?>

РЕДАКТИРОВАТЬ 2:

О, господин. Так что теперь, после некоторой обработки, автономный скрипт PHP работает и связывается с правильным session_id(), и я могу сделать весь бит session_destroy(), $_SESSION = array();, чтобы очистить информацию о сеансе. Небольшая проблема, хотя, если я обновлю HTML-страницу с session_id() в качестве переменной GET, она все равно загрузит страницу? Даже говорит, что переменная `$ _SESSION [" IS_AUTHORIZED "], которую я предположительно только что очистил в своем автономном скрипте, теперь вернулась и вернулась к ней, прежде чем я ее очистил? Что буквально побеждает весь смысл использования сессий? Помогите, пожалуйста! (Я ненавижу php сессии до сих пор о моей душе!)

Ответы [ 4 ]

0 голосов
/ 28 января 2019

Исправлено! Просто отправляю сообщения всем, у кого есть эта проблема.

Оказывается, все это связано с командой session_write_close(). На моей HTML-странице, на которой размещался ограниченный контент, у меня был PHP-код, который проверял переменные сеанса, чтобы определить погоду или не показать страницу или перенаправить. Очевидно, что для доступа к переменным $_SESSION[] сначала мне нужно было установить session_id($_GET[<session id passed via GET>]), а затем выполнить проверку. К сожалению, я никогда не звонил session_write_close(), чтобы веб-страница никогда не отключалась от файла сеанса. Мой автономный скрипт выхода из системы действительно удалял работающие $_SESSION и unset($_SESSION[<variable name>]). Проблема заключается в том, что после обновления HTML-страницы, я думаю, она заново сохраняла файл сеанса снова и эффективно воссоздала его.

Самая простая аналогия, которую я мог бы объяснить, - это отредактировать документ Word и удалить фактический файл, пока он был открыт в Word, затем сохранить из Word, эффективно воссоздав документ заново.

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

Надеюсь, это поможет будущим PHP-кодерам (удачи, вам это понадобится, lol)

0 голосов
/ 26 января 2019
<?php
  session_start() ;
  unset($_SESSION["IS_AUTHORIZED"]);
  session_destroy();
  session_write_close();
  $_SESSION=new array();
  session_regenerate_id(true);
?>
0 голосов
/ 26 января 2019

Если вы [королевский пользователь, то есть системы кеша] храните пользовательские данные, для каждого комментария вы можете включить «частный» в управление кешем. Однако, учитывая состояние невыполнения, прокси-сервер и недостаточно хорошо документированный caniuse для протокола передачи гипертекста. Это может на самом деле не сделать другое. Но, тем не менее, это кажется правильным, и , используя директивы, браузеры более склонны к их реализации.

https://tools.ietf.org/id/draft-ietf-httpbis-cache-00.html#rfc.section.5.2.2.6

Максимальный возраст = 0 хорошо реализован, и, если все настроено неправильно, в нижней части сервера должно быть все, что требуется.

Если что-то настроено неправильно, злонамеренно или неправильно ведет себя ... добавление? пометка уникальным значением, следующим за ним в URL, обманывает эти неверные реализации, чтобы считать URL другой страницей. Сломан кеш систем или нет, это заставляет соединение с сервером запрашивать страницу.


Директива must-revalidate, которую вы используете, является подходящей для выполнения того, что вы просите. Если это будет реализовано на линии вниз?

При любых обстоятельствах кеш ДОЛЖЕН подчиняться директиве must-revalidate; в частности, если кеш не может достичь исходного сервера для какого-либо причина, она ДОЛЖНА генерировать ответ 504 (время ожидания шлюза).

0 голосов
/ 26 января 2019

Уничтожить файл данных сеанса, расположенный в директории session_save_path() folder / session.save_path.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...