Сессии. Подробное описание работы и объяснение механизма. Базовые принципы управления сессиями Сессии и автоматический вход

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

Оценка важности данных, передаваемых в рамках сессии, важна для выбора мер по защите этой информации; все имеет свою цену и обычно дополнительные меры защиты приводят к ухудшению удобства для конечного пользователя. Например, если необходимо защитить пользователя от простейших методов социальной инженерии, следует включить session.use_only_cookies . В данном случае со стороны пользовательского ПО обязательна поддержка cookie, иначе механизм сессий не будет работать.

Существует несколько способов утечки существующего идентификатора сессии третьим лицам. Например инъекции JavaScript, передача идентификатора сесии в URL, перехват пакетов, физический доступ к устройству и т.д. Перехваченный идентификатор сессии позволит третьим лицам получить доступ ко всем ресурсам, связанным с данной сессией. Во-первых, передача идентификатора сессии в URL. При переходе на внешний сайт идентификатор сессии пользователя и адрес ресурса могут попасть в статистику переходов данного сайта. Во-вторых, при более активной атаке возможно прослушивание сетевого трафика злоумышленником. Если канал передачи данных не зашифрован, идентификаторы сессии будут переданы в виде простого текста. В таком случае решением является обязательное использование SSL/TLS пользователями при доступе к сайту. Для этих целей следует применять HSTS.

Замечание : Даже HTTPS иногда может не защитить конфиденциальные данные. Например, уязвимости типа CRIME, BEAST могут позволить злоумышленнику получить доступ к данным. Многие сети используют прокси HTTPS MITM для аудита. Атакующие также могут настроить такие прокси.

Неадаптивное управление сессиями

В настоящее время PHP использует адаптивное управление сессиями по умолчанию. Адаптивное управление сессиями несет дополнительные риски.

С версии PHP 5.5.2 доступна опция session.use_strict_mode . При её включении и при условии, что обработчик сохранения сессий её поддерживает, неинициализированный сессионный ID отвергается и создается новый. Это защищает от атак, которые принуждают пользователя использовать заранее извесный ID. Ататкующий может размещать ссылки или отправлять письма, которые содержат сессионный ID. Например http://example.com/page.php?PHPSESSID=123456789 . Если опция session.use_trans_sid включена, то жертва откроет сессию с этим идентификатором. Опция session.use_strict_mode уменьшает этот риск.

Внимание

Определённый пользователем обработчик сохранения также может поддерживать строгий сессионный режим, путем реализации функции/метода проверки корректности идентификатора сессии. Все определённые пользователем обработчики сохранения обязаны его реализовывать.

Cookie с сессионным ID должна устанавливаться с указанием параметров domain, path, httponly, secure и, начиная с PHP 7.3, аттрибут SameSite. Их приоритетность определяется браузерами. Опираясь на эту приоритетность, атакующий может может установить сессионный ID, который будет использоваться бесконечно. Применение session.use_only_cookies не решает эту проблему. session.use_strict_mode уменьшает риск. session.use_strict_mode =On, не допускает использование неинициализированных сессионных ID.

Замечание : Даже при уменьшении риска с помощью session.use_strict_mode атакующий все ещё может заставить пользователя использовать уже инициализированную сессию, созданную атакующим. Например JavaScript-инъекция. Эта атака может быть смягчена, если следовать рекомендациям этого руководства. Если вы следуете этому руководству, вы должны включить session.use_strict_mode , использовать управление сессиями на основе временных меток и пересоздавать идентификатор сессии с помощью session_regenerate_id() , как рекомендуется. Если вы всё это сделаете, идентификатор сессии злоумышленника в итоге будет удален. Если произошел доступ к истекшей сессией, вы должны сохранить все данные активных сессий пользователя. Это позволит для дальнейшего расследования причин произошедшего. После этого, принудительно заставьте пользователя выйти из всех активных сессий, то есть потребуйте от пользователей переавторизации. Это позволит предотвратить атаку с использованием краденной сессии.

Внимание

Доступ к истекшей сессии не всегда означает атаку. Нестабильное сетевое соединение и/или немедленное удаление активной сессии может повлечь за собой подобное поведение.

С PHP 7.1.0 добавлена функция session_create_id() . Эта функция может быть полезна для создания идентификатора сессии с использованием идентификатора пользователя в качестве префикса для достижения большей управляемости. При её использовании крайне важно разрешать session.use_strict_mode . В противном случае недобросовестные пользователи смогут устанавливать поддельные идентификаторы сессий для других пользователей.

Замечание : В версиях PHP до 7.1.0 необходимо использовать CSPRNG, то есть /dev/urandom или random_bytes() и функции хеширования для генерации нового идентификатора сессии. session_create_id() имеет встроенный функционал обнаружения коллизий и генерирует идентификатор основываясь на INI-настройках. Использование session_create_id() является предпочтительной практикой.

Пересоздание идентификатора сессии

Внимание

Для подобной настройки требуется включение session.use_strict_mode . Убедитесь, что эта опция включена, иначе база данных активных сессий может быть скомпрометирована.

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

Сессии и автоматический вход

Разработчики НЕ ДОЛЖНЫ использовать долгоживущие сессии для реализации автоматического входа в систему, потому что это резко повышает вероятность кражи сессии. Автоматический вход в систему должен реализовываться разработчиком самостоятельно.

Устанавливайте безопасные хешированные одноразовые ключи в качестве ключей автологина с помощью setcookie() . Используйте безопасное хеширование, посильнее чем SHA-2, например SHA-256 или выше со случайными данными из random_bytes() или /dev/urandom.

Если пользователь не авторизован, проверьте, корректен ли одноразовый ключ автологина. Если ключ корректен, авторизуйте пользователя и установите ему новый одноразовый ключ. Ключ автологина обязательно должен быть одноразовым, то есть никогда не используйте его повторно, а всегда создавайте новый.

Ключ автологина - это очень долгоживущий ключ авторизации. Его надо защищать по максимуму. Используйте параметры path/httponly/secure/SameSite при установке cookie для его защиты. Никогда не передавайте ключ автологина, кроме случаев, когда это необходимо.

Разработчик должен реализовать функционал, который отключает автоматический вход в систему и удаляет ненужные "cookie", установленные для его реализации.

CSRF (Межсайтовая подделка запроса)

output_add_rewrite_var() может быть использована для защиты от CSRF. Читайте руководство для подробностей.

Замечание : До PHP 7.2.0 использовался один и тот же буфер вывода и INI-настройки для "trans sid". Так что использование output_add_rewrite_var() с PHP более ранних версий не рекомендуется.

Многие фреймворки поддерживают защиту от CSRF. Обратитесь к документации своего фреймворка для более подробной информации.

Начиная с PHP 7.3, для сессионной cookie можно установить атрибут SameSite. Это обеспечит дополнительную защиту против CSRF.

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

В недавнем обновлении Телеграмм кроме превью ссылок был создан новый раздел в настройках безопасности и конфиденциальности Telegram. Он называется «Активные сеансы».

В разделе содержится информация об IP-адресе пользователя Telegram и его активных сеансах. У каждого появляется возможность завершить неиспользуемые сеансы, как и те активные сессии, что кажутся подозрительными.

Авторизация в два этапа

Еще одно нововведение тоже касается раздела безопасности и конфиденциальности. Это авторизация в Телеграмм в два этапа (Двухэтапная авторизация).

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

Но с этим нужно быть осторожным: если созданный пароль будет утерян, владелец учетной записи не сможет войти в собственный аккаунт Telegram с другого гаджета.

• настроить возможность восстановления пароля через почту;

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

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

Модуль «Активные сессии»

Просмотр информации о текущих подключениях

• Id сессии - уникальный номер, идентифицирующий сеанс работы с панелью управления. По умолчанию информация отображается в таблице в течение 60 минут.
• Пользователь - имя пользователя, подключенного к системе в настоящее время.
• Доступ - уровень доступа данного пользователя к панели управления (например, суперпользователь, администратор сервера, пользователь и др.).
• IP-адрес - удалённый IP-адрес, с которого осуществляется доступ.
• Ожидание - время, прошедшее с момента, когда панель управления получила последнюю команду от пользователя.
• Активных запросов - количество активных запросов.

Завершение сеанса

Чтобы завершить тот или иной сеанс работы с панелью управления, выделите нужные строки в списке активных сеансов и нажмите кнопку "Завершить".

Для предотвращения случайных удалений панель управления попросит подтвердить или отменить ваше действие. Если в окне подтверждения вы нажмёте "Ок", то выделенные сеансы будут завершены.

Если сеанс был завершен, для дальнейшей работы с панелью управления пользователь должен снова авторизоваться.

Эта форма - не обращение в поддержку.
Мы не можем идентифицировать вас и ответить на ваше сообщение.

Давайте рассмотрим такое понятие как сессия (HTTP-сессия, Session). Или по-другому, сеанс пользователя. Почему важно понимать механизм работы сессий. И посмотрим, как можно работать с состояниями сеансов на платформе ASP.NET.

Прежде чем мы дадим определение термину "сессия", давайте немного рассмотрим предысторию, зачем вообще возникла потребность в сессиях, рассмотрим одну особенность протокола HTTP.

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

Что, если оставить stateless-природу протокола HTTP и не идентифицировать пользователя? Без состояний сеанса можно легко обойтись, если на вашем сайте представлена статичная (обезличенная) информация, например, новостная статья, состоящая из текста и изображений. В таком контексте совершенно необязательно ассоциировать несколько запросов с одним пользователем. Ведь содержание статьи никак не изменится, будь то десять запросов с одного устройства, либо десять запросов от разных людей с разных устройств.

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

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

Сессия (session) - это некоторый отрезок во времени, в пределах которого веб-приложение может определять все запросы от одного клиента.

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

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

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

1. скрытые поля на HTML-форме (hidden form fields)
2. куки (cookies)
3. сессия (session, session State)

Попробуем их реализовать, используя платформу ASP.NET. Давайте кратко рассмотрим первые два механизма, и особое внимание уделим третьему, как более надежному, удобному и безопасному.

Скрытые поля на HTML-форме (hidden form fields)

Суть данного подхода состоит в том, что мы обеспечиваем навигацию по сайту при помощи стандартных html-форм. И при каждом следующем запросе мы сохраняем данные из предыдущего в скрытых полях на форме. Например:

Public ActionResult Forms2() { ViewBag.UserName = Request.Form["userName"]; return View(); }

В данном примере мы на первой html-форме получаем имя пользователя. Далее в контроллере в методе Forms2() мы извлекаем это значение из коллекции Form и передаем в представление посредством объекта ViewBag . В этом представлении генерируется код новой формы и в скрытом поле сохраняется имя пользователя. Таким образом, значение имени пользователя будет передано уже на третью формы вместе с дополнительной информацией - значением поля с именем "foodName" . И так далее.

Давайте рассмотрим особенности такого подхода. Плюсов практически нет, разве что реализовать данную технику можно очень быстро. Но опять же и другие подходы тоже можно реализовать очень быстро. А вот минусы есть, и довольно существенные:

Куки (cookies)

Public ActionResult Cookies2() { HttpCookie cookie = new HttpCookie("userName", HttpUtility.UrlEncode(Request.Form["userName"])); cookie.Expires = DateTime.UtcNow.AddHours(1); Response.Cookies.Add(cookie); return View(); }

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

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

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

Серверный механизм управления сессией (Session, SessionState)

Разберем, как работает механизм сессии со стороны сервера и со стороны клиента.

При стандартных настройках работы состояния сеанса для отслеживания серии запросов от одного клиента используется т.н. сессионная куки (session cookie). Алгоритм следующий:

1. Абсолютно для каждого нового запроса на сервер (неважно, разные это клиенты или один) ASP.NET генерирует уникальный идентификатор сессии.
   Идентификатор сессии представляет собой случайно сгенерированное число, закодированное с помощью специального алгоритма в строку длиной 24 символа. Строка состоит из литералов от A до Z в нижнем регистре, а также чисел от 0 до 5. Пример идентификатора - hjnyuijl1pam3vox2h5i41in
2. Если в течение текущего запроса данные клиента НЕ сохраняются для дальнейшей работы с ним, то и время жизни сессии этого клиента заканчивается (фактически не начавшись). При этом ранее сгенерированный идентификатор сессии становится недействительным (так как не был использован). В ответ на такой запрос клиент не получает ничего, чтобы связало его с новой сессией.
3. Если же данные клиента (например, имя, адрес доставки товара) сохраняются на сервере, ASP.NET связывает сохраненные данные с ранее сгенерированным идентификатором сессии. Далее создается специальная сессионная куки, и в нее записывается также этот идентификатор. Эта куки добавляется в ответ на запрос и сохраняется в браузере клиента. Таким образом, создается связь клиента и его персонализированной информации на сервере. Новая сессия для данного клиента создана.
4. При каждом следующем запросе клиент передает на сервер персональный идентификатор сессии через куки. Сервер сопоставляет идентификаторы и «узнает» клиента в рамках текущей сессии.
5. До тех пор пока клиент передает свой персональный ключ, сессия считается активной. Сессия может закончиться по разным причинам, например, вручную на стороне сервера или по истечении какого-то установленного времени (таймаут).

От теории перейдем к практике. Давайте запрограммируем данный алгоритм и посмотрим, как он выполняется. Для этого используем специальный класс HttpSessionState . При работе в контроллере можно воспользоваться свойством HttpContext.Session . Работать с сессией очень просто, как с любой NameValueCollection :

Session["userName"] = Request.Form["userName"]; bool isSessionNew = Session.IsNewSession; string sessionId = Session.SessionID;

В этом участке кода мы записываем в состояние сеанса имя пользователя. Это имя мы забираем с html-формы, которую он нам отправил. Дополнительно через свойства мы узнаем, создана ли эта сессия только что, то есть в рамках текущего запроса (если да, то и значение свойства IsNewSession будет равняться true), и уникальный идентификатор сессии. Этот идентификатор после обработки запроса будет автоматически записан в сессионную куки (если еще нет) и отправлен в ответе клиенту.

В браузере клиента можно наблюдать соответствующую куки и идентификатор его сессии:

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

String userName = Session["userName"].ToString(); //обработка запроса... Session.Abandon();

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

Давайте посмотрим на наиболее интересные свойства и методы класса HttpSessionState , которые чаще всего используются в работе:

Item - возвращает элемент данных по его индексу
Item - возвращает элемент данных по его ключу
Remove(index) - удаляет элемент данных по его индексу
Remove(key) - удаляет элемент данных по его ключу
Clear() - удаляет все данные
Count - возвращает общее количество элементов данных для текущей сессии
Abandon() - принудительно завершить сессию
SessionID - возвращает идентификатор текущей сессии
IsNewSession - возвращает true если сессия была создана в рамках текущего запроса
Timeout - возвращает число минут, допустимое между запросами, перед тем как сессия завершится по причине таймаута (по умолчанию, 20 минут)

Изменить настройки для сессии можно либо программно в коде посредством членов класса HttpSessionState , либо через конфигурацию приложения (). Например:

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

И еще одно важное замечание в плане безопасности. Когда вы завершаете сессию пользователя методом Session.Abandon(); сессионная куки, хранящая идентификатор сессии SessionId, в браузере пользователя не удаляется. Это означает, что если пользователь начнет новую сессию в ближайшее время, не закрывая браузер, то его новой сессии будет присвоен тот же SessionId. Желательно каждой новой сессии всегда присваивать новый уникальный идентификатор, для этого нам нужно вручную удалять сессионную куки после закрытия сессии:

Session.Clear(); //очищаем сессию Session.Abandon(); //отменяем сессию //вручную очищаем куки так Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")); //или сокращаем время жизни Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddYears(-30); //ASP.NET_SessionId - это стандартное название сессионной куки, у вас может быть свое

Вот таким образом происходит отслеживание состояния сеанса пользователя на платформе ASP.NET, с использованием сессий. Этот подход является стандартом и рекомендуется к использованию, когда необходимо сохранять информацию о пользователе и идентифицировать его между запросами на сервер.

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

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

В принципе, довольно несложно сделать собственный аналог сессий, не такой функциональный, как встроенный в PHP, но похожий по сути. На куках и базе данных.
При запросе скрипта смотрим, пришла ли кука с определенным именем. Если куки нет, то ставим ее и записываем в базу новую строку с данными пользователя. Если кука есть, то читаем из базы данные. Еще одним запросом удаляем из базы старые записи и вот у нас готов механизм сессий. Совсем несложно. Но есть некоторые нюансы, которые делают предпочтительным использование именно встроенного механизма сессий.

Если включена только первая, то при старте сессии (при каждом вызове session_start () ) клиенту устанавливается кука. Браузер исправно при каждом следующем запросе эту куку возвращает и PHP имеет идентификатор сессии. Проблемы начинаются, если браузер куки не возвращает. В этом случае, не получая куки с идентификатором, PHP будет все время стартовать новую сессию, и механизм работать не будет.

Если включена только вторая, то кука не выставляется. А происходит то, ради чего, в основном, собственно, и стоит использовать встроенный механизм сессий. После того, как скрипт выполняет свою работу, и страница полностью сформирована, PHP просматривает ее всю и дописывает к каждой ссылке и к каждой форме передачу идентификатора сессии. Это выглядит примерно так:
Index превращается в
Index
а к формам добавляется скрытое поле

И браузер при клике на любую ссылку, или при нажатии на кнопку в форме, пошлет в запросе нужную нам переменную - идентификатор сессии!
По очевидным причинам идентификатор добавляется только к относительным ссылкам.

Теоретически, в наших с вами самодельных сессиях на куках и базе, можно самому, руками приписать ко всем ссылками передачу ид - и тогда наши собственные сессии будут работать независимо от кук. Но, согласитесь - приятнее, когда эту работу делает кто-то другой? ;-)

По умолчанию в последних версиях PHP включены обе опции. Как PHP поступает в этом случае? Кука выставляется всегда. А ссылки автодополняются только если РНР не обнаружил куку с идентификатором сессии. Когда пользователь в првый раз за этот сеанс заходит на сайт, ему ставится кука, и дополняются ссылки. При следующем запросе, если куки поддерживаются, PHP видит куку и перестает дополнять ссылки. Если куки не работают, то PHP продолжает исправно добавлять ид к ссылкам, и сессия не теряется.
Пользователи, у которых работают куки, увидят длинную ссылку с ид только один раз.

Фух. С передачей идентификатора закончили.
Теперь осталось привязать к нему файл с данными на стороне сервера.
PHP это сделает за нас. Достаточно просто написать
session_start ();
$_SESSION [ "test" ]= "Hello world!" ;
И PHP запишет в файл, связанный с этой сессией, переменную test.
Здесь очень важное замечание.
Массив $_SESSION - особенный.
В нем, собственно, и находятся переменные, которые мы ходим сделать доступными в различных скриптах.
Чтобы поместить переменную в сессию, достаточно присвоить ее элементу массива $_SESSION.
Чтобы получить ее значение - достаточно обратиться к тому же элементу. Пример будет чуть ниже.

Cборкой мусора - удалением устаревших файлов PHP тоже занимается сам. Как и кодированием данных и кучей всяких других нужных вещей. В результате этой заботы работа с сессиями оказывается очень простой.
Вот мы, собственно, и подошли к примеру работы сессий.
Пример очень маленький:
session_start ();

echo "Вы обновили эту страницу " . $_SESSION [ "counter" ]++. " раз. " ;
echo "
обновить" ;
?>
Мы проверяем, есть ли у нас в сессии переменная counter, если нет, то создаем ее со значением 0, а дальше выводим ее значение и увеличиваем на единицу. Увеличенное значение запишется в сессию, и при следующем вызове скрипта переменная будет иметь значение 1, и так далее.
Все очень просто.

Для того, чтобы иметь доступ к переменным сессии на любых страницах сайта, надо написать ТОЛЬКО ОДНУ(!) строчку в самом начале КАЖДОГО файла, в котором нам нужны сессии:
session_start ();
И далее обращаться к элементам массива $_SESSION. Например, проверка авторизации будет выглядеть примерно так:
session_start ();
if ($_SESSION [ "authorized" ]<> 1 ) {
header ("Location: /auth.php" );
exit;
}

Удаление переменных из сессии.
Если у вас register_globals=off , то достаточно написать
unset($_SESSION [ "var" ]);
Если же нет, то тогда рядом с ней надо написать
session_unregister ("var" );

Самыми распространенными ошибками, которые выдает РНР при попытке работать с сессиями, являются такие:
Две из них,
Warning: Cannot send session cookie - headers already sent
Warning: Cannot send session cache limiter - headers already sent
вызваны одной и той же причиной, решение описано в этом факе
Третья,
Warning: open(/tmp\sess_SID, O_RDWR) failed: No such file or directory (2) in full_script_path on line number (ранее она выглядела, как Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) ),
если перевести ее с английского, подробно объясняет проблему: недоступен указанный в php.ini путь к каталогу, в который пишутся файлы сессий. Эту ошибку исправить проще всего. Просто прописать каталог, который существует, и доступен на запись, например,
session.save_path = c:\windows\temp
И не забыть перезагрузить апач после этого.

Как выясняется, сообразительность людская не имеет пределов, и поэтому я вынужден пояснить:
сообщение о третьей ошибке (невозможно найти каталог) НЕИЗБЕЖНО приведет к появлению первых двух, поскольку сообщение об ошибке - это вывод в браузер и после него заголовками пользоваться нельзя. Поэтому не спешите искать преждевременный вывод, а сначала пропишите правильный путь!

Следующей по распространенности проблемой при работе с сессиями является тяжелое наследие register_globals. НЕ давайте переменным скрипта имена, совпадающие с индексами массива $_SESSION!
При register_globals=on значения будут перезаписывать друг друга, и вы запутаетесь.
А при register_globals=off появится другая ошибка: "Your script possibly relies on a session side-effect which existed until PHP 4.2.3.", в случае, если в скрипте есть переменная сессии не имеющая значения, и глобальная переменная с тем же именем. Чтобы от неё избавиться, надо всегда инициализировать переменные перед использованием (или хотя бы проверять на существование) и не давать глобальным переменным имена, совпадающие с индексами массива $_SESSION.

Если не работает, но и никаких сообщений не выводится, то добавьте в самое начало скрипта две строчки, отвечающие за вывод ВСЕХ ошибок на экран - вполне возможно, что ошибки есть, но вы их просто не видите.
ini_set ("display_errors" , 1 );
error_reporting (E_ALL );
или смотрите ошибки в error_log. Вообще, тема отображения сообщений об ошибках выходит за рамки данной статьи, поэтому просто убедитесь хотя бы, что вы можете их видеть. Чуть продробнее о поиске ошибок можно прочитать в этом разделе .

Если вы уверены, что ошибок нет, но приведенный пример не работает все равно, то, возможно, в PHP не включена передача ид через урл, а куки по каким-то причинам не работают .
Смотрите, что у вас с куками.
Вообще, если у вас "не работают" сессии, то сначала попробуйте передать идентификатор сессии руками, то есть, сделать ссылку и приписать к ней идентификатор:
session_start ();
if (!isset($_SESSION [ "counter" ])) $_SESSION [ "counter" ]= 0 ;
echo "Вы обновили эту страницу " . $_SESSION [ "counter" ]++. " раз.

обновить" ;
?>
При этом следует убедиться, что не включена директива session.use_only_cookies , которая запрещает PHP принимать идентификатор сессии, если он был передан через URL

Если этот пример не заработает, то проблема либо в банальных опечатках (половина "проблем" с сессиями происходит от неправильно написанного имени переменной), либо в слишком старой версии PHP: поддержка сессий появилась в версии 4.0, а массив $_SESSION - в 4.1 (До этого использовался $HTTP_SESSION_VARS ).
Если же заработает - то проблема в куках. Отслеживайте - что за куку ставит сервер браузеру, возвращает ли браузер ее. Искать очень полезно, просматривая просматривая обмен HTTP-заголовками между браузером и сервером.
Объяснение принципа работы кук выходит за рамки этого и так уж слишком большого текста, но хотя бы убедитесь, что сервер куку с идентификатором посылает, а браузер - возвращает. И при этом идентификаторы совпадают друг с другом =)
Установка куки должна выглядеть, как
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6;
или как
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; path=/
(если вы запрашиваете скрипт не из корневого каталога)
Ответ сервера должен выглядеть, как
Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6
либо
Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; b=b
если браузер возвращает другие куки, кроме идентификатора сессии.

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

Если пример отсюда работает, а ваш собственный код - нет, то проблема, очевидно, не в сессиях, а в алгоритме. Ищите, где потеряли переменную, по шагам переносите пример отсюда, отлаживайте свой скрипт.

Еще одна проблема может возникнуть, если вы используете перенаправление через header или навигацию с помощью JavaScript.
Дело в том, что РНР автоматически дописывает идентификатор сессии только к ссылкам вида , но не делает этого для header-ов, яваскрипта, мета-тегов.
Поэтому надо добавлять идентификатор руками, например, так:
header ("Location: /script.php?" . session_name (). "=" . session_id ());

Так же, весьма редкая, и совершенно непонятно, откуда появляющаяся, проблема бывает в том, что настройка session.save_handler имеет значение, отличное от files. Если это не так - исправляйте.

Безопасность
Безопасность сессий - тема обширная. Поэтому остановлюсь на нескольких основных моментах.
Самый хрестоматийный - не передавать идентификатор через адресную строку. Об этом написано даже в php.ini, но это ограничивает функциональность сессий. Если вы решите последовать этому совету, то кроме session.use_trans_sid = 0 не забудьте session.use_only_cookies = 1
Желательно привязывать сессию к IP адресу: таким образом, если идентификатор будет украден, то злодей все равно не сможет им воспользоваться в большинстве случаев.
Рекомендуется пользоваться директивой session.save_path, с помощью которой задать собственный каталог для сохранения файлов сессий. Это более безопасно, чем когда они хранятся в общем временном каталоге сервера по умолчанию.

Дополнительная информация: