Насколько безопасный переменные сеанса PHP?
Мне нравится тот факт, что я могу использовать LINQ для объектов в старой версии .NET 2.0 (т. Е. Не требовать повсеместной установки .NET 3.5). Все, что вам нужно, это реализация всех методов расширения оператора запроса - см. LINQBridge
.
4 ответа
Сеансы значительно безопаснее, чем, скажем, файлы cookie. Но по-прежнему можно украсть сеанс, и, таким образом, хакер будет иметь полный доступ ко всему, что находится в этом сеансе. Некоторые способы избежать этого - это проверка IP (которая работает довольно хорошо, но с очень низким значением fi и, следовательно, сама по себе ненадежна) и использование одноразового номера. Обычно при использовании одноразового номера у вас есть «токен» для каждой страницы, чтобы каждая страница проверяла соответствие одноразового номера последней страницы тому, что она хранит.
Любая проверка безопасности приводит к потере удобства использования. Если вы выполняете проверку IP, а пользователь находится за брандмауэром интрасети (или в любой другой ситуации, которая вызывает это), которая не имеет постоянного IP-адреса для этого пользователя, ему придется повторно аутентифицироваться каждый раз, когда они теряют свой IP. Используя одноразовый номер, вы всегда получаете удовольствие: «Если щелкнуть назад, эта страница сломается».
Но с помощью cookie хакер может украсть сеанс, просто используя довольно простые методы XSS. Если вы сохраняете идентификатор сеанса пользователя в виде файла cookie, они также уязвимы для этого. Таким образом, даже несмотря на то, что сеанс доступен только для тех, кто может выполнить взлом на уровне сервера (что требует гораздо более сложных методов и, как правило, определенных привилегий, если ваш сервер безопасен), вам все равно понадобится дополнительный уровень проверки. при каждом запросе скрипта. Вы не должны использовать файлы cookie и AJAX вместе, так как это немного упрощает полный переход в город, если этот файл cookie украден, поскольку ваши запросы ajax могут не проходить проверки безопасности для каждого запроса. Например, если на странице используется одноразовый номер, но страница никогда не перезагружается, сценарий может проверять только это соответствие. И если файл cookie содержит метод аутентификации,
Если вы полагаетесь на значение, хранящееся внутри переменной сеанса, для определения ролей тогда вы теряете возможность изменять значение в БД и отражать его в текущем сеансе пользователя. Если вы посмотрите на Zend Framework, вы увидите четкое различие между аутентификацией и авторизацией, а также четко сформулированные предупреждения в руководстве, чтобы хранить только минимальный объем данных в сеансе (например, «Ага, он пользователь № 37, и он вошел в систему») .
Насколько ' безопасность - если вы не используете общий хост, беспокоиться не о чем. На правильно настроенном общем хосте они также должны быть относительно безопасными.
Только скрипты, выполняемые на вашем сервере, имеют доступ к массиву _SESSION. Если вы определяете объем файла cookie сеанса, вы даже можете ограничить его определенным каталогом. Единственный способ получить данные сеанса кем-то, кроме вас, - это внедрить некоторый PHP-код на одну из ваших страниц.
Что касается системы, которую вы используете, это приемлемо и является хорошим способом сохранить вызовы базы данных, но сохранить помните, что для применения любых изменений авторизации пользователю потребуется выйти и снова войти в систему. Поэтому, если вы хотите заблокировать учетную запись, а этот пользователь уже вошел в систему, вы не сможете.
Единственный способ получить данные сеанса кем-то, кроме вас, - это внедрить некоторый PHP-код на одну из ваших страниц.Что касается системы, которую вы используете, это приемлемо и является хорошим способом сохранить вызовы базы данных, но сохранить Помните, что для применения любых изменений авторизации пользователю потребуется выйти и снова войти в систему. Поэтому, если вы хотите заблокировать учетную запись, а этот пользователь уже вошел в систему, вы не сможете.
Единственный способ получить данные сеанса кем-то, кроме вас, - это внедрить некоторый PHP-код на одну из ваших страниц.Что касается системы, которую вы используете, это приемлемо и является хорошим способом сохранить вызовы базы данных, но сохранить помните, что для применения любых изменений авторизации пользователю потребуется выйти и снова войти в систему. Поэтому, если вы хотите заблокировать учетную запись, а этот пользователь уже вошел в систему, вы не сможете.
Следует отметить, что в Apache суперглобальный сервер PHP $ _SESSION доступен через виртуальные хосты. Рассмотрим следующий сценарий:
- На вашем сервере размещены два домена, example.com и instance.org. Сеансы PHP хранятся в файлах cookie, которые ограничены доменом.
- Пользователь входит в систему example.com и получает идентификатор сеанса. Example.com устанавливает некоторые переменные сеанса (которые хранятся на сервере, а не в cookie).
- Третья сторона перехватывает cookie во время передачи и передает его instance.org. Instance.org теперь имеет доступ к переменным сеанса example.com.
Это не такая уж большая проблема, когда вы контролируете все виртуальные хосты на своем сервере, но если вы находитесь на общей машине, это проблематично.