идентификатор сессии это что

Защита идентификатора сессий в PHP

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

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

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

В данной статье я постараюсь изложить все известные мне способы защиты идентификатора сессии в PHP.

Использование cookie

По умолчанию вся информация о сессии, включая ID, передается в cookie. Но так бывает не всегда. Некоторые пользователи отключают cookie в своих браузерах. В таком случае браузер будет передавать идентификатор сессии в URL.

php_flag session.use_only_cookies on

Использование шифрования

Если на вашем сайте должна обрабатываться конфиденциальная информация, такая как номера кредитных карт (привет от Sony), следует использовать SSL3.0 или TSL1.0 шифрование. Для этого при установке cookie следует указывать true для параметра secure.

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

Проверка браузера

Чтобы отсечь возможность использования сессии с другого браузера (компьютера), следует ввести проверку поля HTTP-заголовка user-agent:

Срок действия сессии

# Время жизни сессии в секундах
php_value session.gc_maxlifetime 3600
# Время жизни куки в секундах
php_value session.cookie_lifetime 3600

Привязка по IP-адресу

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

либо по IP-адресу для каждого запроса (только для статичных IP):

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

Источник

Немного о защите идентификаторов веб-сессий

Предлагаем вашему вниманию перевод статьи из блога Eran Hammer — создателя фреймворка hapi.js. На этот раз речь пойдет об обеспечении безопасности идентификаторов сессий.

На Github прозвучал вопрос о том, зачем в Node.js-фреймворке Express к идентификационной cookie сессии добавляется хэш-суффикс? Отличный вопрос.

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

Брутфорс

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

Пароли — это не единственные учетные данные, использующиеся для веб-аутентификации. В наиболее распространенных реализациях используется страница логина, после успешного ввода данных на которой клиенту присваивается cookie-идентификатор сессии. Он служит «токеном предъявителя» — любой, кто «предъявит» этот токен, рассматривается системой в качестве прошедшего аутентификацию пользователя. Использование cookie-идентификатора избавляет от необходимости ввода логина и пароля на каждой странице. Однако теперь, этот id сессии является единственным ключом аутентификации, и любой, кто получит к нему доступ, сможет попасть в систему. В конце концов, cookie — это не более, чем строка символов.

Атаки подборка идентификаторов сессии — это разновидность брутфорс-атак. Вместо того, чтобы пытаться угадать пароль, атакующий подбирает идентификатор сессии. Злоумышленник генерирует идентификаторы сессии и отправляет с их помощью запросы в надежде на то, что какой-то из вариантов совпадет с реальным идентификатором активной сессии. Например, если в веб-приложении идентификаторы генерируются последовательно, то киберпреступник может просто использовать идентификатор собственной сессии и на его основе уже подбирать действующий id (предлагая системе «близлежащие» значения).

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

Нецелесообразность

Прежде всего необходимо сделать так, чтобы идентификаторы сессиий были достаточно длинными и выдавались не последовательно. Тут как с паролями — чем длиннее идентификатор, тем сложнее подобрать «валидный» с помощью перебора. Критически важно еще и генерировать такие id не с помощью предсказуемого алгоритма (например, со счетчиком), поскольку если такая логика присутствует, то атакующему уже даже не надо угадывать идентификаторы — он просто будет их генерировать по алгоритму. Использование для создания достаточно длинных id криптографически безопасного генератора случайных чисел — наилучший вариант. Что значит «достаточно длинных»? Это зависит от природы конкретной системы. Размер должен приводить к нецелесообразности усилий по подбору идентификатора сессии.

Другой способ защититься от угадывания сессионых id заключается в построении целостности токена с помощью добавления хэша или подписи для cookie сессии. В Express промежуточный софт, отвечающий за работу с сессиями, делает это вычисляя хэш для комбинации сессионного id и некого дополнения («секрета»). Поскольку для вычисления хэша в таком случае нужно знать секрет, то злоумышленник не сможет сгенерировать «валидный» идентификатор сессии без необходимости угадывания секрета (в противном случае ему просто предется перебирать хэши). Как и в случае сильных случайных id сессий, размер хэша должен соответствовать требованиям безопасности конкретного приложения. Не забываем, что сессионная cookie — это всего лишь строка символов, которые можно и подобрать.

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

Уровни защиты

Если в нашей системе генерируются сильные случайные идентификаторы сессий, нужен ли нам все равно хэш? Безусловно!

Ключевым принципом безопасности является наслоение. Еще его называют принципом «не класть все яйца в одну корзину». Если полагаться только на один источник безопасности, то в случае, если его удастся взломать, никакой безопасности не останется вообще. К примеру, что будет, если кто-то найдет ошибку в используемом генераторе случайных чисел? Что если затем им удастся взломать эту часть системы, и модифицировать ее? История знает множество примеров успешных атак, организаторы которых проделали именно это — генерировали случайные числа, которые на поверку оказывались совсем не такими случайными (мы писали о подобных уязвимостиях: раз и два).

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

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

Оповещение о проблемах

Важное отличие в подборе паролей и идентификаторов сессий заключается в том, что пароли ассоциированы с учетной записью (например, именем пользователя). Пара имя пользователя-пароль облегчает отслеживание брутфорс атак — увидеть, что кто-то много раз неверно ввел пароль для конкретной учетной записи, довольно легко. Однако, когда дело касается идентификаторов сессий, все не так просто — у сессий есть время действия и они не имеют дополнительного контекста, вроде имени пользователя. Это значит, что идентификатор может быть «невалидным» и в случае ее истечения, и при проведении атаки. Но без дополнительных данных (например, IP-адреса), понять, что на самом деле происходит, довольно трудно.

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

Гигиена безопасности

Аутентификационные данные должны иметь срок действия, поэтому у идентификатора сессии должен быть конечный срок жизни (его конкретная длина зависит от особенностей системы). У сookie есть срок истечения, однако не существует способа проверить его соблюдение. Злоумышленник может установить любое значение параметра экспирации cookie, и сервер никак не сможет об этом узнать. Хорошей практикой здесь является использование временной метки для любых аутентификационных данных — можно просто добавлять суффикс временной метки к случайно сгенерированному id сессии. Однако, чтобы в полной мере доверять таким меткам, нужно убедиться в том, что ее никто не изменял. Для этого и нужны подпись или хэш.

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

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

Аварийная кнопка

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

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

Общее предназначение

Важная функция промежуточного сессионного софта фреймворка Express — это поддержка user-generated идентификаторов сессий. Она позволяет разработчикам развертывать программное обеспечение в существующей среде, где сессионные идентификаторы генерируются некой существующей сущностью, которая может быть реализована на совсем другой платформе. Если не добавлять хэш к сгенерированному пользователем идентификатору сессии, то за построение безопасной системы будет отвечать не эксперт (разработчик конкретного модуля), а пользователь (новый подход к безопасности). Использование хэша — куда более верный подход, чем применение внутреннего генератора идентификаторов сессий.

Нужны ли крокодилы

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

Другой распространенный способ — создание cookie с общей информацией о пользователей (имя, недавно просмотренные элементы и т.п.) в добавок к сессии, впоследствии к хэшу добавляется что-либо из этой cookie — так создается связь между активным состоянием пользователя и аутентификацией. «Имя пользователя» опять возвращается в игру.

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

Заключение

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

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

Источник

Термин: Идентификатор сессии

Идентификатор сессии – это переменная сессии, посредством которой происходит идентификация клиента (браузера). Этот уникальный идентификатор присваивается клиенту (браузеру) с той целью, чтобы он вернул ее при следующем запросе. По умолчанию в PHP идентификатор сессии обозначается как PHPSESSID.

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

В частности, поисковики, индексирующие сайты, воспринимают ссылку с измененной переменной PHPSESSID как новую и индексируют ее повторно, тем самым переполняя поисковую базу дубликатами страниц и увеличивая нагрузку на сервер.

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

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

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

Источник

Session id что это

session_id – получает и/или устанавливает id текущей сессии.

Описание

string session_id ([string id])

session_id() возвращает id текущей сессии.

Константа SID также может использоваться для запрашивания текущих имени и >SID определена только в том случае, если клиент не отправил правильной куки. См. Обслуживание сессии.

session_id — Получает и/или устанавливает идентификатор текущей сессии

Описание

session_id() используется для получения или установки идентификатора текущей сессии.

Константа SID также может быть использована для получения текущего имени и идентификатора сессии в виде строки, подходящей для добавления в URL-адреса. См. также Работа с сессиями.

Список параметров

Замечание: При использовании сессионных cookie, указание id для session_id() приводит к тому, что при вызове session_start() всегда будут отправлены новые cookie, независимо от того, совпадает ли идентификатор текущей сессии с вновь установленным.

Возвращаемые значения

session_id() возвращает идентификатор текущей сессии или пустую строку («»), если нет текущей сессии (идентификатор текущей сессии не существует).

Смотрите также

User Contributed Notes 22 notes

It may be good to note that PHP does not allow arbitrary session ids. The session id validation in PHP source is defined in ext/session/session.c in the function php_session_valid_key:

To put it short, a valid session id may consists of digits, letters A to Z (both upper and lower case), comma and dash. Described as a character class, it would be [-,a-zA-Z0-9]. A valid session id may have the length between 1 and 128 characters. To validate session ids, the easiest way to do it use a function like:

session_id() itself will happily accept invalid session ids, but if you try to start a session using an invalid id, you will get the following error:

Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and ‘-,’

session_ >
If we use session_id() to read the cookie it will output a value of this: enGHumY,-2De-F-TDzNHVmE,hY5

The two values don’t match! Use either setrawcookie() or URL encode if you wish to match the original value.

I was perplexed by inconsistent results with the session ID depending on whether I retrieve it using SID, COOKIE, or session_id(). I have found that session_id() is the most reliable method, whereas SID and COOKIE[«PHPSESSIONID»] are sometimes undefined.

I used this simple script to quickly test the problem on my servers:

Regardless of browser I see the COOKIE undefined on the first load and the other two defined, then SID is empty on subsequent reloads and COOKIE is defined, but session_id() is always defined.

If I insert the session_regenerate_id() method that jeff_zamrzla gives below the refresh the page, I get a new session_id() but the COOKIE value is initially the prior session_id() until I hit refresh a second time. So again, session_id() proves to be the most reliable method.

It’s probably not a bug since I found the behaviour to be consistent in PHP versions 5.2.14, 5.3.3 and 5.3.4, but I can’t figure what I’m missing and hopefully this will help others who run into this.

About the note from Cybertinus :

The following test doesn’t work, the code following is always executed :

Note that Firefox and Mozilla use the same process for launching new windows or tabs, they will pick up the same session id as the previous windows until the parent process dies or is closed. This may cause undesired results if the session id is stored in a db and checked, a solution is to check at the new entry point (new tab or window if the user went back to the index page) for an existing session. If a session id exists and a new one is required use something like:

Gosh, took a LOOONG time to figure this one out! If you have suhosin built into your PHP and can’t get sessions to work after changing the session id through session_id(), try turning off suhosin’s session encryption option in php.ini with:

The higher you set session.hash_bits_per_character the shorter your session_id will become by using more bits per character. The possible values are 4, 5, or 6.

When using sha-1 for hashing (by setting ini_set(‘session.hash_function’, 1) the following session string lengths are produced by the three session.hash_bits_per_character settings:

4 – 40 character string
5 – 32 character string
6 – 27 character string

It would seem desirable to use sha-l with 5 bits_per_character because this will emulate a standard 32 character md5 string and make a would-be attacker think that is what you’re hashing with.

The documentation for session_id is incomplete when it says:
«For example, the file session handler only allows characters in the range a-z, A-Z and 0-9!».

It is untrue when changing the default for the session.hash_bits_per_character as Colin said. session_id may therefore contain «-» and «,».

I had a lot of trouble with session_regenerate_id() as it did not regenerate. Session_id() stayed the same no matter what (unless closing the window). I wanted to have different sid and empty vars for each session/page meeting a condition for security reasons. Finally, this worked:

Now you get different sid and session variables empty for each session_start if condition is met (i.e. user hits refresh on user/password form, which I needed badly :). Hope this helps someone out there.
Env: localhost
Note: condition is mandatory, otherwise it destroys on each load.

This can looks obvious, but as me, you can spend some hours to make a simple session work between different browsers and devices. These are the basics for me, but you can build upon.

In response to simon at quo dot com dot au:

The PHPSESSID is produced using an hash function. By default, it uses MD5 which produces 128 bits long (i.e: 16 bytes long) hashes.
But, since some bytes’ values may not be used in the HTTP header, PHP outputs the hash in its hexadecimal representation, thus resulting in a 32 bytes long text.

Starting with PHP 5.0, you can change the hash function used (by setting «session.hash_function» to whatever function you want to use in php.ini).
You may for example set it to 1 to switch to SHA-1 which produces 160 bits (20 bytes) long hashes.

Please also note that another setting was introduced in PHP 5 (session.hash_bits_per_character) which sort of «compresses» the hash. Thus, resulting in what seems to be a shorter hash.
This feature helps you improve your application’s security by producing IDs that are harder to prodict for a malicious attacker.

Get a shared session.

Sometimes is good can interchange messages and vars between one session and another, but PHP dont support this. I create this script that allows with session_id() change from current session to shared session (this is, info with scope to all sessions) for read and write info and back in to user session. The code:

Сессии в PHP или как данные о зашедшем на сайт пользователе или покупателе сохраняются при переходе между страницами сайта без особого труда. Урок очень важный. Актуален для создания 95% сайтов.

Что такое сессия в php

Сессии используются для хранения сведений временных данных (например, о том, что пользователь зашёл на сайт) при переходах между страницами одного сайта. При использовании сессий данные сохраняются во временных файлах на сервере.

Чаще всего сессиями (и куками впрочем тоже) пользуются при создании Интернет-магазинов, форумов, досок объявлений, социальных сетях, блогах и других ресурсах. Удобство системы сессий заключается хранении временной информации зашедшего пользователя/покупателя, данные о котором находятся в быстром доступе определённое время. У сессии существует естесственный срок годности – до закрытия браузера. Если закрыть только страницу, то при открытии сайта данные о пользхователе/покупателе всё равно будут доступны.

Логика работы сессии

Session (или сессия) это некое временное хранилище данных. Сразу предупреждаю, сохранять стоит небольшой объём данных. Например, логин и пароль заходящего пользователя или его порядковый номер в базе данных.

Пример работы
1. Пользователь вводит логин и пароль и заходит на сайт
2. Данные с логином и паролем сохраняются в сессии одной из страниц сайта:

Файл index.php

3. При переходе на другую страницу сайта эти данные также будут доступны:

Файл example.php (или любая другая страница)

4. Если хотите очистить данные сессии, то достаточно:

Файл example.php

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

Передача значения или массива с помощью сессии PHP

В сессию можно записывать не только строку, но и массив данных. Только не переусердствуйте с объёмом массива, так как всё это повлияет на быстройдействие и занятое пространство на сервере.

Вновь используем некую стартовую страницу index.php

Сохранили данные в сессии и переходим по ссылке на другую страницу, где всё данные и будем выводить.

Файл получатель, страница test.php где открываем массив

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

Другие функции для работы с сессиями

session_unregister(string) – сессия забывает значение заданной глобальной переменной;
session_destroy() – сессия уничтожается (например, если пользователь покинул систему, нажав кнопку выход);
session_set_cookie_params(int lifetime [, string path [, string domain]]) – с помощью этой функции можно установить, как долго будет жить сессия, задав unix_timestamp определяющий время смерти сессии.

Список функций для работы с сессиями (session) в php

Примеры работы сессий

Счётчик просмотров страницы во время сессии. Наглядно пример работы. Однако после закрытия браузера отсчёт начнётся заново.

Счётчик посещений одной страницы в рамках одной сессии

При каждом переходе счётчик будет увеличиваться на 1)

Источник