- Работа с сессиями в PHP
- Способы передачи идентификатора сессии
- Идентификатор сессии
- Идентификаторы сессий и поисковые системы
- Как с этим бороться?
- Запрет идентификаторов
- Канонизация URL
- Запреты в мета robots
- Роботам сессии не открываем
- Защита идентификатора сессий в PHP
- Использование cookie
- Использование шифрования
- Проверка браузера
- Срок действия сессии
- Привязка по IP-адресу
- Передача идентификатора сессии
Работа с сессиями в PHP
Отредактировано: 04 Февраля 2019
Сессия, механизм php, созданный для возможности передачи данных предназначенных конкретному пользователю при повторных запросах (веб-сервер не поддерживает постоянного соединения с клиентом, и каждый запрос обрабатывается, как новый, без какой-либо связи с предыдущими).
Принцип работы сессий: сервер выдает браузеру уникальный идентификатор, и просит передавать его с каждым запросом. Передача происходит стандартными способами, либо через куки, либо через переменные POST/GET.
Идентификатор сессии — это обычная переменная, по умолчанию ее имя — PHPSESSID. Можно изменить директивой session.name в php.ini.
На сервере за передачу информации о сессиях отвечают две настройки в php.ini:
- session.use_cookies — если равно 1, то PHP передает идентификатор в куках, если 0 — то нет.
- session.use_trans_sid — если равно 1, то PHP передает его, добавляя к URL и формам, если 0 — то нет.
Соответственно, если включена только первая настройка и браузер отдает куки, то идентификатор передается через них, если не отдает, то сессия обнуляется при каждом запросе.
Если включена только вторая, то PHP дописывает к каждой относительной ссылке и к каждой форме передачу идентификатора сессии, примерно так:
Если включены обе, то браузеру выставляется кука, а ссылки и формы дополняются только если кука найдена не была.
Вся информация о сессии храниться в глобальном массиве $_SESSION.
Запись данных в сессию работает так:
Используем например так:
Удаление переменных из сессии:
Для закрытия сессии используется функция:
Данные из глобального массива $_SESSION php хранит либо в файлах, путь к которым указывается в session.save_path в php.ini, либо в БД.
Для управления HTTP-заголовками отвечающими за кэш, используется функция session_cache_limiter(). Установка nocache, например, отменяет кэширование на стороне клиента.
Источник
Способы передачи идентификатора сессии
Существуют два метода передачи идентификатора сессии:
- Cookies
- Параметр URL
Модуль сессии поддерживает оба метода. Метод с cookies является оптимальным, но он не всегда доступен. Поэтому PHP предоставляет второй способ, который внедряет идентификатор сессии непосредственно в URL.
PHP умеет преобразовывать ссылки прозрачно. Если session.use_trans_sid включена, все относительные URI-адреса будут автоматически содержать идентификатор сессии.
Директива arg_separator.output из php.ini позволяет настраивать разделитель аргументов. Для полной совместимости с XHTML следует указывать &.
В качестве альтернативы вы можете использовать константу SID , которая устанавливается при запуске сессии. Если клиентское ПО не хранит подходящую сессионную cookie, SID имеет вид session_name=session_id . В противном случае содержит пустую строку. Таким образом, вы можете в любом случае внедрять его в URL.
Приведённый ниже пример демонстрирует, как зарегистрировать переменную и как правильно построить ссылку на другую страницу, используя SID .
Пример #1 Подсчёт количества посещений конкретного пользователя
if (empty( $_SESSION [ ‘count’ ])) <
$_SESSION [ ‘count’ ] = 1 ;
> else <
$_SESSION [ ‘count’ ]++;
>
?>
Здравствуйте, посетитель, вы видели эту страницу echo $_SESSION [ ‘count’ ]; ?> раз.
Функция htmlspecialchars() может использоваться для вывода SID с целью предотвращения XSS-атак.
Вывод SID способом, показанном выше, не является обязательным, если опция —enable-trans-sid была использована при компиляции PHP.
Подразумевается, что неотносительные URL-адреса указывают только на внешние сайты и потому SID к ним не добавляется, т.к. это представляло бы угрозу для безопасности, в частности, риск утечки SID другому серверу.
Источник
Идентификатор сессии
Это случайная последовательность символов, используемая для идентификации пользователя при его переходах по сайту. Обычно идентификатор делается достаточно длинным, чтобы он не повторялся на протяжении достаточно долгого времени. Например, в php изначально использовались идентификаторы в виде 32-значных шестнадцатиричных чисел. Если идентификация пользователя не связана с реквизитами авторизации (логином и паролем), идентификатор обычно генерируется на основе метки текущего времени (хеш md5, sha1 и т. п.), это обеспечивает его уникальность на много лет.
Идентификатор сессии обычно отсылается браузеру клиента в виде Cookie, но нередко есть вероятность, что браузер его не примет или вообще не получит. Для надежности идентификатор сессии автоматически добавляется ко всем «внутренним» ссылкам на странице в виде параметра с определенным именем (в php по умолчанию PHPSESSID, но это имя можно и переопределить). Такая технология получила название transparent SID («прозрачная» идентификация сессии).
Идентификаторы сессий и поисковые системы
Скрипт, использующий механизм сессий, выдает уникальный идентификатор каждому новому посетителю, не предъявившему его в Cookie и пришедшему по ссылке без идентификатора. Но поисковые боты не поддерживают Cookie. Нетрудно догадаться, что при каждом визите бота по ссылке без идентификатора ему будет выдана страница с новым идентификатором во всех ссылках. Формально ссылка с параметром PHPSESSID и без такого параметра — это две разные ссылки. Следовательно, при каждом обходе сайта бот будет получать новый набор уникальных ссылок на одни и те же страницы. Тупо индексируя эти находки, поисковик будет наполнять свою базу практически неограниченным числом страниц-дубликатов.
Как это отразится на положении сайта в поиске — нетрудно догадаться. Для тех, кто не догадался, подсказка: отразится очень плохо. Обнаружив в индексе большое количество страниц-дубликатов, поисковик оценит качество исполнения сайта как очень низкое, что неминуемо скажется на позициях в поиске. Но это еще не все. Поисковику совсем не нужно тратить свое дисковое пространство на ваши бесконечные дубли, поэтому он рано или поздно начнет чистить базу от этого мусора. Не рассчитывайте на разумный подход к чистке: поисковик — не человек, а тупая машина, думать он не умеет, соображать не обучен и интуиции ему не дано. Поэтому нечего удивляться, если он выметет из своей базы всё старьё (в том числе ссылки без идентификаторов), а оставит самое свежее и актуальное (ссылки с идентификаторами, которые собрал при последнем обходе сайта). Или выкинет страницу без идентификатора, а с идентификатором оставит, потому что Вася Пупкин дал на нее ссылку в своем блоге, а на страницу без идентификатора никаких ссылок нет. Значит, она менее важная.
Как с этим бороться?
Волшебных кнопок на все случаи жизни не бывает. Поэтому пути могут быть разными в зависимости от целей, которые вы ставите. Например, для форума и для интернет-магазина возможны принципиально разные решения.
Запрет идентификаторов
Самый простой выход — вообще запретить механизм «прозрачной идентификации» сессий, оставив идентификацию только через Cookie. Так, например, построена работа форума SEO-board. В php для полного запрета достаточно изменить настройки, прописав в .htaccess вот такое заклинание:
Первая строка предписывает отключить механизм передачи идентификаторов в ссылках, вторая — использовать только Cookie для идентификации сессий.
Канонизация URL
Сравнительно новый метод, поисковиками он поддерживается не так давно. Реализуется программно, в секцию страницы нужно внедрить тег канонизации:
Запреты в мета robots
Или так (не рекомендуется):
Разница невелика: второй вариант разрешает боту следовать по ссылкам, обнаруженным на странице, но оба варианта запрещают индексирование страницы. Для защиты от дубликатов с сессиями второй вариант нежелателен: никаких нужных ссылок на этой странице поисковик все равно не найдет — все ссылки будут с идентификатором сессии.
Роботам сессии не открываем
Оба варианта защиты с тегами (канонизация и мета robots) имеют один явный недостаток: чтобы поисковик «узнал», что эту страницу нельзя брать в индекс, он должен сначала ее считать и разобрать. Поскольку обход страниц сайта роботы проводят не сразу, а небольшими порциями в порядке очереди, это отвлекает бота на сканирование и разбор ненужных страниц. А значит, новые попадут в индекс позднее, чем хотелось бы; сначала бот будет обходить ранее запланированные «дубли».
Источник
Защита идентификатора сессий в PHP
Безопасность веб-сайтов основывается на управлении сессиями. Когда пользователь подключается к безопасному сайту, он предоставляет учетные данные, как правило, в форме имени пользователя и пароля. Веб-сервер не имеет представления о том, какой пользователь уже вошел в систему и как он переходит от страницы к странице. Механизм сессий позволяет пользователям не вводить пароль каждый раз, когда они хотят выполнить новое действие или перейти к новой странице.
В сущности, управление сессией гарантирует, что в настоящее время соединен тот пользователь, который проходил авторизацию. Но, к сожалению, сессии стали очевидной мишенью для хакеров, поскольку они могут позволить получить доступ к веб-серверу без необходимости проверки подлинности.
После аутентификации пользователя, веб-сервер предоставляет ему идентификатор сессии. Этот идентификатор хранится в браузере и подставляется всякий раз, когда нужна проверка подлинности. Это позволяет избежать повторяющихся процессов ввода логина/пароля. Все это происходит в фоновом режиме и не доставляет дискомфорта пользователю. Представьте, если бы вы вводили имя и пароль каждый раз, когда просматривали новую страницу!
В данной статье я постараюсь изложить все известные мне способы защиты идентификатора сессии в PHP.
Использование cookie
По умолчанию вся информация о сессии, включая ID, передается в cookie. Но так бывает не всегда. Некоторые пользователи отключают cookie в своих браузерах. В таком случае браузер будет передавать идентификатор сессии в URL.
Здесь ID передается в открытом виде, в отличие от сессии через cookie, когда информация скрыта в HTTP-заголовке. Самым простым способом защиты от этого будет запрет передачи идентификатора сессии через адресную строку. Сделать это можно, прописав следующее в конфигурационном файле Apache-сервера .htaccess:
php_flag session.use_only_cookies on
Использование шифрования
Если на вашем сайте должна обрабатываться конфиденциальная информация, такая как номера кредитных карт (привет от Sony), следует использовать SSL3.0 или TSL1.0 шифрование. Для этого при установке cookie следует указывать true для параметра secure.
Если вы храните пароль сессии в переменной $_SESSION (все-таки лучше использовать sql), то не стоит хранить его в открытом виде.
Приведенный выше код не безопасный, так как пароль хранится в виде обычного текста в переменной сессии. Вместо этого используйте md5-шифрование, примерно так:
Проверка браузера
Чтобы отсечь возможность использования сессии с другого браузера (компьютера), следует ввести проверку поля HTTP-заголовка user-agent:
Срок действия сессии
Ограничьте время жизни сессии, а также время действия cookie. По умолчанию срок действия сессии 1440 секунд. Изменить это значение можно через php.ini и .htaccess. Пример для .htaccess:
# Время жизни сессии в секундах
php_value session.gc_maxlifetime 3600
# Время жизни куки в секундах
php_value session.cookie_lifetime 3600
Привязка по IP-адресу
В определенных ситуациях (не всегда) следует установить привязку по IP-адресу. В основном когда количество пользователей ограничено и имеют статичные IP. Проверка может быть либо по списку разрешенных IP-адресов,
либо по IP-адресу для каждого запроса (только для статичных IP):
Следует осознавать, что полностью избежать взлома невозможно. Можно только максимально усложнить этот взлом любыми известными способами. Однако следует также не забывать о своих легальных пользователях, чтобы не осложнить им жизнь такой защитой.
Источник
Передача идентификатора сессии
Существуют два метода передачи идентификатора сессии:
- Cookies
- Параметр URL
Модуль сессии поддерживает оба метода. Метод с cookies является оптимальным, но он не всегда доступен. Поэтому PHP предоставляет второй способ, который внедряет идентификатор сессии непосредственно в URL.
PHP умеет преобразовывать ссылки прозрачно. Однако, если вы используете версию PHP младше 4.2.0, вам следует включить эту возможность вручную при сборке PHP. Под UNIX следует передать конфигуратору опцию —enable-trans-sid. Если эта опция сборки и опция времени исполнения session.use_trans_sid включены, в относительные URI будут автоматически добавляться идентификаторы сессии.
Директива arg_separator.output из php.ini позволяет настраивать разделитель аргументов. Для полной совместимости с XHTML следует указывать &.
В качестве альтернативы вы можете использовать константу SID , которая устанавливается при запуске сессии. Если клиентское ПО не хранит подходящую сессионную cookie, SID имеет вид session_name=session_id. В противном случае содержит пустую строку. Таким образом, вы можете в любом случае внедрять его в URL.
Приведенный ниже пример демонстрирует, как зарегистрировать переменную и как правильно построить ссылку на другую страницу, используя SID .
Пример #1 Подсчет количества посещений конкретного пользователя
if (empty( $_SESSION [ ‘count’ ])) <
$_SESSION [ ‘count’ ] = 1 ;
> else <
$_SESSION [ ‘count’ ]++;
>
?>
Здравствуйте, посетитель, вы видели эту страницу echo $_SESSION [ ‘count’ ]; ?> раз.
Функция htmlspecialchars() может использоваться для вывода SID с целью предотвращения XSS-атак.
Вывод SID способом, показанном выше, не является обязательным, если опция —enable-trans-sid была использована при компиляции PHP.
Подразумевается, что неотносительные URL указывают только на внешние сайты и потому SID к ним не добавляется, так как это увеличивало бы риски в области безопасности, в частности, риск утечки SID другому серверу.
Источник