Когда пользователь с низким уровнем привилегий, не являющийся администратором, успешно регистрируется в моем веб-приложении, я сохраняю следующие данные в $_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 )
Содержимое сеанса видимо и может быть изменено только на стороне сервера.
Они могут быть изменены только «несанкционированным» образом, если ваше приложение или сервер содержит некоторую уязвимость.
Вы также должны знать о таких атаках , как атаки на сеанс , когда злоумышленник заставляет конкретный идентификатор сеанса на ничего не подозревающего пользователя, который при входе в систему и повышает привилегии этого сеанса, позволяя злоумышленнику разделить этот сеанс.
Один из подходов к их смягчению – восстановить идентификатор сеанса всякий раз, когда вы меняете уровни привилегий сеанса.
См. Также этот вопрос:
Если вы хотите, чтобы javascript не читал ваши файлы cookie и человека в средних атаках, вам нужно использовать сервер с 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 времени, пользователь должен снова войти в систему, чтобы использовать права администратора.
Более короткие сеансы также более безопасны, чем более длинные.
Сеансы хранятся на сервере. Пользователь может изменять данные сеанса, если они имеют прямой доступ к каталогу, в котором хранятся сеансы. Решением этого является защита каталога. И убедитесь, что у вас нет отверстия в вашем php-коде, где вы разрешаете user_id устанавливать $ _POST или $ _GET.
Но на стороне клиента манипулирование сеансами возможно путем захвата someones session_id. Это позволит угонщику позировать как этот пользователь. И отправьте запрос от их имени.
Существует также кросс-сайт запрос подделка . Это когда хакер заставляет пользователя отправлять запросы для него . Например, нажав на ссылку. Вы могли бы бороться с этим с помощью токенов. Токен – это сгенерированная строка, которая помещается в массив $ _SESSION и в каждую HTML-форму как скрытое поле. Когда пользователь отправляет форму, значения проверяются друг на друге. И каждый раз, когда пользователь запрашивает новую страницу, токен изменяется. Таким образом, злоумышленник должен попытаться предсказать токен, что довольно сложно в зависимости от того, как вы делаете токен.
В ссылках также будут показаны примеры этих атак.
Если вы не предоставляете такой доступ в своем скрипте, это не так много, что пользователи могут это сделать. Поэтому ваши данные сеанса должны быть достаточно безопасными. Единственное, что пользователь может сделать, это манипулировать cookie сеанса или идентификатором сеанса, переданным в URL-адресе, но маловероятно, что он найдет существующий идентификатор сеанса другого пользователя.
Нет, если вы не оставили где-то в безопасности (например, чтобы пользователи могли каким-либо образом добавлять / изменять данные $ _SESSION).
Насколько я знаю, нет, если пользователь не угадает ваш идентификатор сеанса и не заменит его в своих файлах cookie. Вы должны добавить дополнительную IP-проверку, по крайней мере, на стороне сервера, чтобы предотвратить это.