Что было бы наиболее безопасным решением для очень простого пользовательского контроля в PHP?

Question

Мне было интересно, какой будет самый простой, но безопасный метод для следующей логики управления пользователем:

• 1 пользователь / сайт (база данных не задействована)
• Пользователь входит в систему со страницы входа в систему, но не перенаправляется на административную панель, однако при входе в систему пользователь получает некоторые дополнительные права непосредственно на веб-интерфейсе (ссылки удаления / редактирования / и т. Д.)

Вопросы:

• Насколько безопасно хранить имя пользователя и (открытый текст) пароль в файле конфигурации? Я знаю, что это, вероятно, не лучший способ, но в идеале пароль должен быть в виде открытого текста для удобного редактирования на основе файла конфигурации (phpMyAdmin делает то же самое в своем файле config.inc.php, поэтому я предполагаю, что это больше или менее хорошо).
• Какой самый лучший / самый безопасный способ следить за авторизованным пользователем на сайте? Мое текущее решение проверяет статус и IP-адрес пользователя при каждой загрузке страницы (сеанс logged_in равен TRUE, а сеанс IP - это IP-адрес пользователя, оба сгенерированные при первоначальном входе в систему)? Это нормально?
• На что еще я должен следить?

Спасибо за ваш ответ заранее!

Answer 1

Хранение пароля в виде обычного текста в значительной степени нет-нет. Вы должны хешировать его, используя безопасный хеш (например, md5 не является безопасным), и «засолить» его (то есть, добавить или добавить «секретную» строку к паролю перед его хэшированием - в противном случае, поиск пароля из хеша все еще относительно легко, особенно когда пароль является общим). Если вы не хотите создавать полную страницу смены пароля, вы можете создать небольшой вспомогательный скрипт, чтобы хэшировать пароль и не сохранять его на веб-сервере; когда вам нужен новый пароль, вы запускаете его и вставляете его вывод в файл конфигурации.

Другие вещи, на которые следует обратить внимание (обычные атаки):

• SQL-инъекция (значения POST или GET, вставленные в запросы; злонамеренный ввод может нарушить ваши запросы интересными способами). Используйте PDO и параметризуйте все свои входные данные базы данных, и вы должны быть хорошими.
• Обход пути. Если вы читаете имена файлов или части имен файлов из $_POST или $_GET или из любого другого пользовательского ввода, вставка вредоносных значений может отправить клиенту файлы, которые не должны были быть открытыми.
• Сценарий внедрения. Аналогично обходу пути: любой оператор include, require или eval, который принимает динамический ввод, является потенциальным хуком, который злоумышленники могут использовать для внедрения своего собственного кода PHP в ваше приложение (например, если у вас есть include $_GET['page'];, тогда кто-то можете использовать это, чтобы включить скрипт из другого места)
• Межсайтовый скриптинг. Если у вас есть динамический HTML-код на вашей странице, убедитесь, что никто не может злоупотребить этим для размещения сценариев или фреймов на странице; в противном случае кто-то может использовать это для чтения файлов cookie сеанса и передачи сеанса другого пользователя.
• Man-in-the-middle: отправка учетных данных для входа по обычному HTTP означает, что любой, имеющий сетевой анализатор в той же локальной сети, а также любой, имеющий доступ к любому маршрутизатору между клиентом и сервером, могут легко следить за HTTP-разговором. и извлеките учетные данные. Даже если учетные данные защищены, то же самое относится и к куки-файлу сеанса, поэтому лучше всего обслуживать все через HTTPS, когда пользователь вошел в систему.

Answer 2

Поместите файл пароля за пределы веб-корня (например, в /etc), чтобы предотвратить его случайное использование.

Если вы используете хеш, используйте bcrypt . Но помните, что злоумышленник с полным доступом может перехватить страницу входа, чтобы получить пароль при следующем входе в систему.

Защитите страницу входа с помощью SSL, чтобы предотвратить попадание человека в середину.

Answer 3

Единственной альтернативой хранилищу базы данных является хранилище файлов.И самый элегантный способ хранения материала в файле - это использование формата XML, который можно анализировать с помощью запросов XPath.Смотрите пример здесь http://www.w3schools.com/php/func_simplexml_xpath.asp.

Я никогда не работал с XPath на PHP и никогда не работал с ним в сыром виде (использовал методы и объекты, которые его реализовывали).

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

строка может выглядеть следующим образом

<user username="username" password="edf53kqwolebng653fgism33grhloi76">
      <name>John doe</name>
      <rights>
           <module name="one">0010</module>
           <module name="two">1111</module>
      </rights>
</user>

цифры представляют права на создание и удаление для чтения (1 имеет, 0 нет), поэтому, если у пользователя есть только права на чтение, ключ доступа будет 0100 (с учетом порядка CRUD).

В основном все, что вам нужно сделать, это загрузить эту информацию в сеанс после входа в систему.

Надеюсь, это поможет.

Надеюсь, это поможет.

Answer 4

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

Кроме того, я бы порекомендовал хранить хэш вместо открытого текста.

Answer 5

Всегда лучше хранить пароль в виде хэша.Вы никогда не знаете, кто получает доступ к FTP.Или, если сервер PHP выходит из строя, все файлы PHP будут отображаться в виде простого текста.Едва ли это попытка сохранить хеш, но это может спасти вас от многих потенциальных головных болей.

Способ следования за пользователем мне кажется хорошим.