Безопасность массива $ _SESSION

Question

Когда пользователь без прав доступа с правами администратора входит в мое веб-приложение, я сохраняю следующие данные в массиве $_SESSION:

$_SESSION = array(
    'user_id'     => 2343,  // whatever their user_id number is from the DB
    'allow_admin' => false, // don't give them access to admin tools
    'allow_edit'  => false, // don't let them edit stuff
    );

Есть ли способ, которым они могли бы манипулировать массивом $_SESSION, чтобы предоставить им доступ администратора или редактирования, кроме как каким-либо образом редактировать файлы сеанса в /tmp? (Приведенный выше код является единственным местом, где эти элементы добавляются в $_SESSION)

Answer 1

Содержимое сеанса отображается и изменяется только на стороне сервера.

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

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

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

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

• PHP Session Security

Answer 2

Если вы не хотите, чтобы javascript читал ваши куки и человек в середине атаки, вам нужно использовать сервер с https и настроить сеансовый cookie только для передачи через https.

session.cookie_secure указывает, следует ли отправлять файлы cookie только через безопасные соединения. По умолчанию выключено. Этот параметр был добавлен в PHP 4.0.4. Смотрите также session_get_cookie_params () и session_set_cookie_params ().

session.cookie_httponly Помечает файл cookie как доступный только по протоколу HTTP. Это означает, что cookie не будет доступен для языков сценариев, таких как JavaScript. Этот параметр может эффективно помочь уменьшить кражу личных данных с помощью XSS-атак (хотя он поддерживается не всеми браузерами).

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

Более короткие сеансы также более безопасны, чем более длинные.

Answer 3

Сервер

Сеансы хранятся на сервере. Пользователь может изменить данные сеанса, если он имеет прямой доступ к каталогу, в котором хранятся сеансы. Решением этой проблемы является защита каталога. И убедитесь, что у вас нет дыры в вашем php-коде, где вы разрешаете устанавливать user_id с помощью $ _POST или $ _GET.

Клиент

Но на стороне клиента манипулирование сессиями возможно путем угона someones session_id. Это позволит угонщику выдавать себя за этого пользователя. И отправьте запрос от их имени.

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

В ссылках также приведены примеры этих атак.

Answer 4

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

Answer 5

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

Answer 6

Нет, если вы где-то не оставили дыру в безопасности (например, позволяя пользователям каким-либо образом добавлять / изменять данные $ _SESSION).