Пример фиксации сеанса Php и исправления

Мой вопрос касается этого резюме по фиксации сеанса:

  • У Алисы есть счет в банке http://unsafe.com/ . К сожалению, Алиса не очень сообразительна.

  • Мэллори вытащил деньги Алисы из банка.

  • У Алисы разумный уровень доверия к Мэллори, и он посетит ссылки, которые посылает Мэллори.

    1. Мэллори определил, что http://unsafe.com/ принимает любой идентификатор сеанса, принимает идентификаторы сеанса из строк запроса и не имеет проверки безопасности. http://unsafe.com/ не является безопасным.
    2. Мэллори отправляет Алисе по электронной почте: «Эй, проверьте это, в нашем банке есть замечательная новая функция сводки счета, http: //unsafe.com/? SID = I_WILL_KNOW_THE_SID». Мэллори пытается зафиксировать SID на I_WILL_KNOW_THE_SID.
    3. Алиса заинтересована и посещает http://unsafe.com/?SID=I_WILL_KNOW_THE_SID . Появляется обычный экран входа в систему, и Alice входит в систему.
    4. Мэллори посещает http://unsafe.com/?SID=I_WILL_KNOW_THE_SID и теперь имеет неограниченный доступ к учетной записи Алисы. (кредит: RichieHindle)

Вопросов:

Q1 – Есть ли способ явно запретить сайту принимать какой-либо идентификатор сеанса?

Q2 – Я не использую переменную $ _GET на моем сайте, так есть ли способ предотвратить прием идентификаторов сеанса из строк запроса?

  • Примечания. Я использую php 5.4.3 с SSL и также буду использовать session_regenerate_id ..

Вы могли бы указать параметры martinstoeckli, упомянутые в его ответе, но это не помешает фиксации сеанса. Это делает фиксацию сеанса немного сложнее атаковать, но это не мешает.

Как упоминалось в ServerBloke, вы предотвращаете фиксацию сеанса с помощью session_regenerate_id () сразу после проверки пользовательской информации входа и перед тем, как показывать первую страницу, требующую аутентификации.

Сделать его труднее для злоумышленника для использования фиксации сеанса, не препятствует фиксации сеанса. Вы должны создать новый идентификатор сеанса.

Все больше людей используют общественные необеспеченные ненадежные горячие точки Wi-Fi. Сессии можно обнюхивать с воздуха. В физической сети их можно обнюхивать с провода. Они также могут заставить вас посетить любой URL-адрес, используя атаку «человек-в-середине». Таким образом, фиксация сеанса по-прежнему является проблемой, даже если злоумышленник не может отправлять вам URL-адреса.

Зная, что сеансы (и пароли) можно обнюхать, есть еще один шаг, который требуется для предотвращения захвата сеанса. Это HTTPS (TLS / SSL).

Все защищенные страницы, требующие аутентификации, должны быть доступны только через HTTPS. Таким образом, страница входа (тот, где пользователь отправляет свое имя пользователя и пароль) должен быть доступен через HTTP. В этом же скрипте вы должны восстановить новый идентификатор сеанса. Затем все страницы для оставшейся части сеанса должны быть доступны через HTTP для защиты нового идентификатора сеанса.

Вот пример скрипта псевдонимы login.php:

// Force SSL if($_SERVER["HTTPS"] != "on") { die('Must login via HTTPS'); } // Load the current sessionID session_start(); // Validate the login information, being sure to escape the input ... if (! $valid) { die('Invalid login'); } // Start the new session ID to prevent session fixation session_regenerate_id(); // Clear the old session $_SESSION=array(); // Log them in $_SESSION['user_id'] = $userID; 

Если вы используете session_regenerate_id() каждый раз, когда пользователь входит в систему, вы предотвратите фиксацию сеанса. Когда пользователь войдет в систему, их фиксированный идентификатор сеанса будет регенерирован и, таким образом, прекратит атаку.

Вопрос 1) Если вашему приложению требуется сеанс, вам придется отправить какой-либо идентификатор сеанса. Если ваше приложение не использует сеансы, тогда нет необходимости вызывать session_start() , и идентификаторы (отправленные по URL-адресу или файлу cookie) просто не используются.

Вопрос 2) Вы можете настроить PHP, принимать идентификаторы сеанса исключительно из файлов cookie и игнорировать идентификаторы из URL-адреса (см. Session.use_only_cookies ). Если вы это сделаете, вы также должны проверить, что для параметра session.use_trans_sid установлено значение 0 (это значение по умолчанию).

Я не совсем понимаю, действительно ли это проблема?

Q1. Я думаю, вам нужно проверить, есть ли SID, полученный от GET COOKIE в вашем хранилище сеансов уже (например, в базе данных). Если YES – its'okay, если нет, создайте новый на стороне сервера и выполните перенаправление http с новым SID.

Q2. Я не использую php 5.4, но я думаю, что следующий код поможет:

 unset($_GET['sid']) 

Обновление: я думаю, что общее исправление заключается в том, что только сервер базы данных может генерировать идентификаторы SID. Для этого нет пользователей.