Предотвращение D / DoS атак PHP / Redis Session

Question

Я реализовал свой собственный SessionHandlerInterface, который читает / записывает пользовательские сессии и постоянные сессии на сервер Redis.Срок действия файла cookie сеанса пользователя истекает в момент закрытия браузера, поэтому необходимо очистить связанный сеанс Redis.Я могу очистить это, установив срок действия, например, 30 минут, что приведет к тому, что пользователь получит новый сеанс за 30 минут без сбоев из-за наличия постоянного сеанса.Когда пользователь входит в систему, я автоматически выдаю постоянный файл cookie, который позволяет им оставаться в системе в течение нескольких месяцев.

Как предотвратить D / DoS-атаку, когда пользователь программно получает файл cookie сеанса пользователя и /или постоянный файл cookie, удаляет его и продолжает запрашивать и удалять файл cookie на неопределенный срок?По сути, создание в Redis бесконечного числа осиротевших пользователей или постоянных сеансов, которые в конечном итоге будут очищены.Даже если я уменьшу срок действия файла cookie сеанса до 1 минуты, чтобы немного снизить риск, он все равно оставит постоянную проблему с файлом cookie, для которой не истекают месяцы.Это может легко привести к сбою моего менеджера сеансов и помешать всем пользователям войти в систему.

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

Эта проблема поднималась раньше: Потерянные записи управления сеансами в базе данных.Как решить проблему?Риск стабильности БД

Answer 1

Я полагаю, что у меня есть решение, определенное за пределами использования брандмауэра.

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

Это должно гарантировать, что для пользователя не может существовать более одного сеанса пользователя или постоянного сеанса, что должно аннулировать любую атаку DoS-сессии..