Каковы лучшие практики для безопасного входа в веб-приложение PHP?

Question

Я хотел бы получить разъяснения о том, каковы некоторые рекомендации по безопасному входу в сеть и, кроме того, постоянному входу в систему для приложения PHP, которое проходит аутентификацию в Active Directory.

1. Имеет ли смысл при входе в систему реализовать модель Post-Redirect-Get? Хранение пароля в $_SESSION, вероятно, не очень хорошая идея.

2. После проверки подлинности проверяется, установлено ли в конкретном поле $_SESSION допустимый и безопасный способ проверки того, вошел ли пользователь в систему?

Answer 1

Не рекомендуется хранить пароль в виде простого текста в любой момент времени.

1) Я не рекомендую модель PRG для страницы входа в систему.Худшее, что может случиться, это то, что человек вошел в систему дважды.Это не так уж и плохо.

Данные, хранящиеся в $ _SESSION, обычно не могут быть прочитаны клиентом.Они хранятся на сервере, где злоумышленник или хакер могут получить к ним доступ.

2) После аутентификации можно проверить сеанс, чтобы убедиться, что кто-то вошел в систему. Кто-то может подделать идентификатор сеанса другого человекано вероятность этого минимальна, если вы используете SSL.Я рекомендую хранить IP-адрес, пользовательский агент и другую информацию, которую вы можете легко получить в переменной $ _SERVER, и сравнивать ее время от времени или каждый раз.Чтобы уменьшить вероятность того, что кто-то взломал идентификатор сеанса другого человека.

Восстановление идентификатора сеанса при входе в систему не имеет большого смысла для меня, хотя я не знаю ваш конкретный сценарий.Мое предложение состоит в том, чтобы просто восстановить его при выходе.Кроме того, вы можете добавить функцию тайм-аута в сеанс, если хотите.

Answer 2

Вы должны хранить что-то только для разграничения анонимных пользователей и пользователей, вошедших в систему, например ключевое слово is_valid в сеансе.

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

Способ защитить вас от этого - обработать все страницы подключенных пользователей в HTTPS, когда они вошли в систему ... или попытаться сделать так, чтобы никто не предпринял XSS-атаку или взломал вашу точку доступа wifi для получения сеанса. ID.

Ну, на самом деле это несколько других способов, таких как хранение какой-либо сигнатуры браузера клиента (пользовательский агент, может быть, IP-адрес может быть проблематичным с перемещением прокси, списком установленных плагинов и т. Д.) И хороший хэш этого. Сохраните это в куки и проверяйте это иногда. Редактировать: Вы можете проверить мой ответ на этот вопрос , а также узнать о некоторых способах отслеживания и идентификации одного пользовательского браузера, чтобы убедиться, что сеанс все еще используется тем же пользователем.

Никогда не сохраняет пароль в файле сеанса, никогда не хранит пароль нигде.