Предотвращение массовых отправлений формы $ _SESSION

Question

Если я получаю бомбу от .NET-программы, созданной на C # - бомбардировка, когда пользователь отправляет поля $ _POST в моей форме в массовых количествах ... Это, в частности, моя контактная форма.

Я не уверен, как именно масса $_POST происходит в программе .NET или это может быть программа на C ++, я понятия не имею.Однако у меня была идея противостоять этому.

Моя первая идея требует $_SESSION, но ... Будут ли эти $_POST программы бомбардировки, созданные пользователем, обрабатывать / принимать $_SESSION?Я действительно не хочу это выяснять, но, возможно, кто-то с опытом работы с классом WebClient в C # будет знать, обрабатывает ли он $_SESSION'S или что-то еще, что использует пользователь.Я подумывал об использовании $_SESSION['submitted'] = $count; и другой части $count++;

if($_SESSION['submitted'] > 5) {
    //display captcha or block from site
} else {
    $count++;
}

Если программа пользователя не обработала $ _SESSION, возможно ли в любом случае отключить для них сайт?Значит, они не могут атаковать мою контактную форму?

Answer 1

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

Единственный безопасный способ заблокировать пользователя, такой как это, - начать регулировать его IP-адрес.Ограничьте это определенным количеством попыток подключения в минуту, и они не смогут отправлять больше, чем столько запросов в минуту.Теперь, если они могут прыгать между хостами, тогда у вас есть большая проблема, и вам, вероятно, стоит взглянуть на перемещение вашей формы в другое место, чтобы все, что они получают, это 404 (пока они не заметят, что оно перемещено).если они используют общий прокси-сервер или какой-то другой, например AOL, который проксирует ВСЕ, вы бы заблокировали и других законных пользователей.

Answer 2

А как насчет реализации CAPTCHA?

Answer 3

Кто-то может исправить меня, если я ошибаюсь, но SESSION сохраняет cookie (или каким-либо другим способом) с идентификатором сеанса (очень длинная строка хеша), переменные SESSION хранятся на сервере. Таким образом, даже если бы они обрабатывали SESSION, они не имели бы никакого контроля над сохраненными на сервере переменными SESSION.

На вашем месте я бы поставил CAPTCHA на постоянное включение ...

Answer 4

Ну, вы можете установить некоторые барьеры безопасности, такие как форма входа или другая форма аутентификации (например, проверка браузера или подобное)что опять же не может быть хорошей идеей