Введение: Наилучшей практикой в использовании сессий с ZF будет использование куков вместо сохранения идентификатора сессии в URL для отслеживания отдельных пользователей. По умолчанию эта компонента использует только куки для хранения идентификатора сессии. Значением, сохраняемым в куках, является уникальный идентификатор сессии. Расширение ext/session использует этот идентификатор для поддержки однозначно определяемой связи "один-к-одному" между посетителем сайта и хранилищем постоянных данных сессии, уникальным для каждого посетителя. Zend_Session* является оберткой к этому механизму хранения ($_SESSION) с объектно-ориентированным интерфейсом. К сожалению, если атакующий получил доступ к идентификатору сессии в куках, то он может угнать сессию посетителя. Эта проблема не является присущей только PHP или Zend Framework. Метод regenerateId() позволяет приложению изменять идентификатор сессии (сохраненный в куках посетителя) на новое случайное значение. Замечание: Несморя на то, что эти термины не равнозначны, для удобочитаемости мы будем попеременно использовать "агент пользователя" и "веб-броузер".

Почему?: Если атакующий получил валидный идентификатор сессии, то он может имитировать реального пользователя (жертву) и затем получить доступ к конфиденциальной информации или манипулировать данными жертвы через ваше приложение. Изменение идентификатора сессии помогает защитить пользователя от угона сессии. Если идентификатор сессии был изменен и атакующий не знает его новое значение, то он не может использовать новый идентификатор сессии в своей попытке угона сессии посетителя. Даже если атакующий получил доступ к старому идентификатору сессии, то regenerateId() перемещает данные сессии со старого идентификатора на новый, и поэтому данные этой сессии не будут доступны через старый идентификатор.

Когда использовать regenerateId(): Добавление Zend_Session::regenerateId() в файл загрузки Zend Framework является одним из самых безопасных и надежных способов регенерации идентификаторов сессии в куках агента пользователя. Само по себе отсутствие условной логики, определяющей, когда регенерировать идентификатор сессии, не является признаком плохо разработанного кода. Но, несмотря на то, что регенерация при каждом запросе пересекает некоторые возможные пути атак, не все хотят мириться с небольшой потерей в производительности и пропускной способности, связанными с регенерацией. Поэтому приложения обычно пытаются определить ситуации, связанные с наибольшим риском, и только тогда регенерируют идентификаторы сессий. В случаях, когда привилегии сессии посетителя сайта "обостряются" (например, посетитель заново проходит аутентификацию до изменения его личного "профиля") или когда производятся "чувствительные" для безопасности изменения параметров сессии, используется regenerateId() для регенерации идентификатора сессии. Если вы вызываете функцию rememberMe(), то не используйте regenerateId(), т.к. первая функция вызывает вторую. Если пользователь успешно залогинился на вашем сайте, используйте rememberMe() вместо regenerateId().

Отсутствие XSS-уязвимостей на сайте помогает предотвратить угон сессий c него. Согласно статистике Secunia, XSS (межсайтовый скриптинг) - довольно распространенное явление. Лучше минимизировать возможный ущерб от XSS, следуя наилучшей практике программирования, чем предполагать, что этого никогда не случится с вами. Атакующему, использующему XSS, не нужно иметь прямой доступ к сетевому трафику жертвы. Если жертва уже имеет сессионные куки, то XSS с внедрением кода Javascript позволит атакующему прочитать куки и украсть сессию. Если жертва не имеет сессионные куки, то, используя XSS с внедрением кода Javascript, атакующий может создать куку с заранее известным идентификатором сессии в броузере жертвы, затем установить идентичную куку в своей системе, чтобы угнать сессию жертвы. Если жертва посетит сайт атакующего, то атакующий может также сэмулировать и другие доступные для идентификации характеристики агента пользователя жертвы. Если ваш сайт имеет XSS-уязвимости, то атакующий может внедрить AJAX-код, который скрытно "заходит" на сайт атакующего, и атакующий может узнать характеристики броузера жертвы и о скомпрометированной сессии на сайте жертвы. Но несмотря на все это, атакующий не может изменить данные сессии на стороне сервера при условии, что разработчик корректно установил значение опции save_path.

Сам по себе вызов Zend_Session::regenerateId() в то время, как сессия еще только начинает использоваться, не предотвращает атаку через фиксацию сессии, за исключением того случая, когда вы можете отличить сессию, созданную атакующим, имитирующим личность жертвы. На первый взгляд это противоречит предыдущему утверждению, но до тех пор, пока мы не будем считать атакующим того, кто первый иницировал создание настоящей сессии на вашем сайте. Сессия сначала используется атакующим, который знает результат инициализации (regenerateId()). Атакующий затем использует новый идентификатор сессии вместе с найденной XSS-уязвимостью или добавляет идентификатор сессии в ссылку на сайт атакующего (работает в том случае, если use_only_cookies = off).

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

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

<?php
require_once 'Zend/Session.php';
$defaultNamespace = new Zend_Session_Namespace();
 
if (!isset($defaultNamespace->initialized))
{ 
    Zend_Session::regenerateId(); 
    $defaultNamespace->initialized = true;
} 
?>