PHP Lang
  1. PHP Lang
  3. Снятие сеансов (PHP)
Intereting Posts
Неустранимая ошибка: вызов неопределенной функции finfo_open () в php Переменная Echo PHP из JavaScript? Получение пользовательского заголовка авторизации из входящего запроса PHP слияние рекурсивных на внутренних массивах многомерного массива php Отправка HTML-кода через JSON Знайте, если электронная почта была ответом, используя IMAP в PHP Существуют ли языки программирования, предназначенные для PHP, помимо Haxe? PHP ereg_replace устарел Как Zend анализирует URL-адрес в переднем контроллере с помощью mod_rewrite? FB Messenger Bot: обновления Webhook не доставляются Какие ситуации требуют использования eval (), потому что альтернатив нет? ereg_replace для preg_replace? заменить английские котировки на немецкие котировки Как обновить базу данных (d2) на основе информации другой базы данных (d1) Xpath-запрос для HTML-таблицы в XML в PHP DOMDocument

Снятие сеансов (PHP)

Я $_SESSION['logged_in'] веб-сайт в PHP, который содержит логическую $_SESSION['logged_in'] . Это значение равно true когда совпадение имени пользователя и пароля присутствует в базе данных.

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

Я понимаю, что пользователю придется манипулировать серверной переменной с клиентской стороны, но мои вопросы в том, насколько легко это было бы, как бы пользователь мог выполнить такую ​​задачу, есть ли какие-либо известные эксплойты и какие лучшие практики / превентивные меры, чтобы избежать такого рода нападений?

Solutions Collecting From Web of "Снятие сеансов (PHP)"

Начнем с хорошей новостью: массив $_SESSION по умолчанию полностью невидим и не поддается клиенту: он существует на сервере и только на сервере, в среде выполнения, которая не открыта для клиента.

Теперь вернемся к земле: довольно легко получить код PHP «почти справа» и таким образом открыть дверь между клиентом и сеансом, как видно на сервере. В дополнение к этому, краже клиентского сеанса (включая файл cookie) довольно просто.

Я рекомендую несколько смягчающих мер, которые оказались достаточно эффективными:

  • Не храните значение «вошедшего в систему», вместо этого сохраните значение «cookie» сеанса и установите cookie клиенту. В запросе клиента сделайте что-то вдоль строк $loggedin=($_SESSION['cookie']==$_COOKIE['session']) . Это делает злоумышленнику обоим: cookie и идентификатор сеанса.
  • Обновите сессионный файл cookie довольно часто, в неправильном файле cookie убейте сеанс. Если черная шляпа украдет файл cookie и сеанс, следующий клик реального пользователя выйдет из системы и создаст регистрируемое событие.
  • Если ваши запросы поступают из JS, подумайте о создании простой функции проверки подлинности: вместо отправки токена аутентификации, солейте его, перепроверьте его меткой времени, а затем сделайте хэш. Отправить соль, метку времени и хэш. Сделайте проверку сервера отметкой времени.

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

Наиболее распространенной проблемой, встречающейся в домене сеансов, является захват сеанса . Это связано с тем, что сеансы связаны с параметром session. Этот параметр должен предоставляться пользователем каждый раз, когда он отправляет запрос на сервер. Как вы можете себе представить, может ли кто-то угадать или получить параметр, они должны «захватить» сеанс.

Изменить: в отношении мер безопасности против него взгляните на должность Юджина Рекка.

Единственный способ увидеть, где эта атака будет возможна, – это если в вашем коде есть какой-то другой эксплойт или если у вас есть доступ к вашему серверу (с помощью других средств). Конечно, если у них есть доступ к вашему серверу, у них есть доступ к вашей базе данных, исходному коду, возможно, к веб-журналам, возможно, к интернет-трафику, включая пароли ….