Умная обработка сессий PHP / Безопасность

Question

Я решил, что лучший способ обработать аутентификацию для моих приложений - написать свой собственный обработчик сеанса с нуля. Как и в «Чужих», это единственный способ убедиться, что все сделано так, как вы хотите.

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

1. Первое, что я делаю, это проверяю IP (или, возможно, даже сеансы), чтобы приманить неавторизованные попытки. Я написал некоторые условия, которые бесполезны во сне. Большая проблема здесь, очевидно, где хранить мой черный список для оптимальной скорости чтения.

2. session_id генерирует, хэширует и сохраняет в $ _SESSION [myid]. Отдельный фрагмент того же токена сохраняется во втором $ _SESSION [mytoken]. Соответствующие данные затем сохраняются в TABLE X , где я не остановился (что является корнем этого вопроса).

3. Каждый последующий запрос затем проверяет, что [myid] & [mytoken] являются тем, что мы ожидаем от них, а затем повторно вводит новые учетные данные для следующего запроса.

4. В зависимости от состояния сеанса могут быть выполнены более очевидные функции ACL.

Итак, это общий обзор моего параноидального обработчика сеанса. Вот вопросы, на которых я действительно застрял:

I. Каков оптимальный способ хранения IP ACL? Должен ли я писать / читать на hosts.deny? Есть ли проблемы с производительностью в моей методологии?

II. Мой метод предотвращения MitM кажется нормальным, или я слишком параноидален при сравнении нескольких индексов? Каков наилучший способ хранения этой информации, чтобы я не сталкивался с кирпичными стенами на 80-100 пользователей?

III. Я излишне забиваю свои серверы постоянной регенерацией сеанса + обратной записью? Есть ли лучший способ?

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

Заранее спасибо!

Answer 1

Запись на hosts.deny

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

Вам также необходимо учесть следующие моменты при использовании hosts.deny:

• Безопасность : Открытие доступа к такому важному файлу, как hosts.deny, для пользователя веб-сервера
• Боль в A : управление несколькими записями из разных процессов (например, denyhosts)
• Боль в A : Безопасное внесение изменений в файл, если вы хотите предоставить доступ к IP-адресу, который был ранее заблокирован позднее

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

Answer 2

I.Оптимальным способом хранения IP ACL будет отправка запрещенных IP-адресов в базу данных SQL, которая не страдает от проблем параллелизма, таких как запись в файлы.Затем внешний сценарий, на регулярной основе или триггер, может генерировать правила IPTABLES.Вам не нужно перечитывать вашу базу данных при каждом доступе, вы пишете только тогда, когда обнаруживаете неправильное поведение.

II.Привязка к IP не является хорошей вещью в общедоступном Интернете, если вы предлагаете услуги клиентам за прозрачными прокси или мобильным устройствам - их IP-адреса меняются.Пусть пользователи выбирают в настройках, если они хотят эту функцию (зависит от вашей аудитории, если они знают, что означает IP ...).Мое решение состоит в том, чтобы генерировать уникальный токен для запроса (страницы), повторно используемого на этой странице AJAX-запросами (не вмешиваясь в проблему с ресурсами - случайные числа, хранилище данных сеанса и т. Д.).Сгенерированные мной токены хранятся в течение сеанса и запоминаются на несколько минут.Это позволяет пользователю открыть несколько вкладок, вернуться и отправить их в ранее открытую вкладку.Я не привязываюсь к IP.

III.Это зависит ... не хватает данных от вас, чтобы ответить.Выше может идеально удовлетворить ваши потребности для ~ 500 пользователей, приходящих на ваш сайт по 5 минут в день, один раз.Или он может подходить даже для 1000 уникальных пользователей в час на сайте / игре чата - это зависит от того, что делает ваше приложение, и от того, насколько хорошо вы кешируете данные, которые можно кэшировать.

Хорошо спроектируйте, протестируйтеэталонный.Проверьте, является ли обработка сеанса проблемой вашего ресурса, а не чем-то другим.Хорошие алгоритмы не должны бросать вас в проблемы с ресурсами.DoS защита включена, и она не должна быть кодом в приложении.Приложения могут подсказывать механизмам предотвращения DoS, что нужно делать, и разрешать защиту с помощью специализированных инструментов (см. Ответ I.).

В любом случае, если в будущем у вас возникнут проблемы с ресурсами, лучший выход - этоновое оборудование.Это может показаться кому-то грубым или даже некомпетентным, но рассчитайте цену нового сервера через 6 месяцев, практически на 30% лучше, чем цена за вашу работу: заплатите 600 долларов за новый сервер и получите дополнительно 130% мощности или платите себе 100 долларов в месяц заулучшение на 5% (хорошо, улучшение на 40%, но если неделя стоит 25 долларов, это может серьезно измениться).

Если вы разрабатываете с нуля, сначала прочитайте https://www.owasp.org/index.php/Session_Management, а затем найдите перехват сеанса, фиксация сессии и подобные строки в Google.