У меня есть сценарий входа в систему, который проверяет имя пользователя / пароль на данные в таблице «пользователь». Кроме того, у меня есть таблица «ролей», которая определяет уровень доступа данного пользователя. Предполагая, что я использую безопасные сценарии входа в систему, есть ли какие-либо дыры в безопасности для простого выполнения дополнительного запроса при успешном входе в систему против таблицы «ролей», чтобы обнаружить уровень авторизации пользователя и сохранить его в переменной сеанса? Тогда идея заключалась бы в том, что на любой странице со смешанными полномочиями я мог бы просто запросить переменную сеанса, чтобы открыть уровень авторизации входа в систему.
Благодарю.
Сессии значительно безопаснее, чем, скажем, файлы cookie. Но по-прежнему можно украсть сеанс, и, таким образом, у хакера будет полный доступ к тому, что есть в этом сеансе. Некоторые способы избежать этого – проверка IP (что работает очень хорошо, но очень низкое значение fi и, следовательно, не является надежным само по себе) и использование nonce. Как правило, с помощью nonce у вас есть «токен» для каждой страницы, так что каждая страница проверяет, совпадает ли счетчик последней страницы с тем, что он сохранил.
В любой проверке безопасности происходит потеря удобства использования. Если вы проводите проверку IP-адресов, а пользователь находится за брандмауэром интрасети (или любой другой ситуацией, которая вызывает это), которая не поддерживает постоянный IP-адрес для этого пользователя, им придется повторно аутентифицироваться каждый раз, когда они теряют свой IP-адрес. С помощью nonce вы получаете всегда удовольствие от ситуации «Щелчок назад приведет к тому, что эта страница сломается».
Но с помощью cookie, хакер может украсть сеанс, просто используя довольно простые методы XSS. Если вы храните идентификатор сеанса пользователя в качестве файла cookie, они также уязвимы для этого. Таким образом, даже несмотря на то, что сеанс является только проницаемым для тех, кто может выполнять взлома на уровне сервера (для чего требуется гораздо более сложный метод и обычно некоторый объем привилегий, если ваш сервер защищен), вам все равно потребуется некоторый дополнительный уровень проверки по каждому запросу сценария. Вы не должны использовать файлы cookie и AJAX вместе, так как это облегчает полное переезд в город, если этот cookie украден, так как ваши запросы ajax могут не получить проверки безопасности по каждому запросу. Например, если страница использует nonce, но страница никогда не перезагружается, сценарий может проверять только на это совпадение. И если cookie поддерживает метод аутентификации, я могу теперь пойти в город, делая свое зло, используя украденный файл cookie и отверстие AJAX.
Только скрипты, выполняемые на вашем сервере, имеют доступ к массиву _SESSION. Если вы определяете область действия cookie сеанса, вы можете даже ограничить его конкретным каталогом. Единственный способ, которым кто-то помимо вас мог получить данные сеанса, – это ввести код PHP на одну из ваших страниц.
Что касается используемой вами системы, это приемлемо и является хорошим способом для сохранения вызовов базы данных, но имейте в виду, что пользователю потребуется выйти из системы и снова войти в систему для любых изменений авторизации. Поэтому, если вы хотите заблокировать учетную запись и этот пользователь уже зарегистрирован, вы не сможете.
Следует отметить, что в Apache суперкоммутатор PHP $ _SESSION доступен через виртуальные хосты. Рассмотрим этот сценарий:
Это не такая уж большая проблема, когда вы контролируете все виртуальные хосты на вашем сервере, но если вы находитесь на общей машине, это проблематично.
Если вы полагаетесь на значение, хранящееся внутри переменной сеанса для определения ролей, вы теряете возможность изменять значение в БД и отражать его в текущем сеансе пользователя. Если вы посмотрите на Zend Framework, есть четкое различие между аутентификацией и авторизацией и строго сформулированные предупреждения в руководстве, чтобы хранить только минимальный объем данных в сеансе (т. Е. «Yup, он пользователь № 37 и он вошел в систему») ,
Что касается «безопасности» – если вы не на общем хозяине, вам не о чем беспокоиться. На правильно настроенном общем хосте они также должны быть относительно безопасными.