Насколько безопасны переменные сеанса PHP?

У меня есть логин script, который проверяет имя пользователя/пароль на данные в таблице 'user'. Кроме того, у меня есть таблица "ролей", которая определяет уровень доступа данного пользователя. Предполагая, что я использую безопасные сценарии входа в систему, есть ли какие-либо дыры в безопасности при простом выполнении дополнительного запроса при успешном входе в систему против таблицы "ролей", чтобы обнаружить уровень авторизации пользователя и сохранить его в переменной сеанса? Тогда идея заключалась бы в том, что на любой странице со смешанными полномочиями я мог бы просто запросить переменную сеанса, чтобы открыть уровень авторизации пользователя.

Спасибо.

Ответ 1

Сессии значительно безопаснее, чем, скажем, файлы cookie. Но по-прежнему можно украсть сеанс, и, таким образом, у хакера будет полный доступ к тому, что есть в этом сеансе. Некоторые способы избежать этого - проверка IP (что работает очень хорошо, но очень низкое значение fi и, следовательно, не является надежным само по себе) и использование nonce. Как правило, с помощью nonce у вас есть "токен" для каждой страницы, так что каждая страница проверяет, что последняя страница не совпадает с тем, что она хранила.

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

Но с печеньем, хакер может украсть сеанс, просто используя довольно простые методы XSS. Если вы храните идентификатор сеанса пользователя в качестве файла cookie, они также уязвимы для этого. Таким образом, даже несмотря на то, что сеанс является только проницаемым для тех, кто может выполнять взлома на уровне сервера (для чего требуется гораздо более сложный метод и обычно некоторый объем привилегий, если ваш сервер защищен), вам все равно потребуется некоторый дополнительный уровень проверки при каждом запросе script. Вы не должны использовать файлы cookie и AJAX вместе, так как это облегчает полное переезд в город, если этот cookie украден, так как ваши запросы ajax могут не получить проверки безопасности по каждому запросу. Например, если страница использует nonce, но страница никогда не перезагружается, script может проверять только на это совпадение. И если cookie поддерживает метод аутентификации, я могу теперь пойти в город, делая свое зло, используя украденный файл cookie и отверстие AJAX.

Ответ 2

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

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

Ответ 3

Следует отметить, что в Apache суперкоммутатор PHP $_SESSION доступен через виртуальные хосты. Рассмотрим этот сценарий:

На вашем сервере размещаются два домена, example.com и instance.org. Сессии PHP хранятся в файлах cookie, которые ограничены доменом.
Пользователь регистрируется на example.com и получает идентификатор сеанса. Example.com устанавливает некоторые переменные сеанса (которые хранятся на сервере, а не в файле cookie).
Третья сторона перехватывает файл cookie во время передачи и передает его на instance.org. В Instance.org теперь есть доступ к переменным сеанса example.com.

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

Ответ 4

Если вы полагаетесь на значение, хранящееся внутри переменной сеанса для определения ролей, вы теряете возможность изменять значение в БД и отражать его в отношении текущего сеанса пользователя. Если вы посмотрите на Zend Framework, есть четкое различие между аутентификацией и авторизацией и строго сформулированные предупреждения в руководстве, чтобы хранить только минимальный объем данных в сеансе (т.е. "Yup, пользователь 37 и он вошел в систему" ).

Что касается "безопасности" - если вы не на общем хозяине, вам не о чем беспокоиться. На правильно настроенном общем хосте они также должны быть относительно безопасными.