Представьте себе кампанию, в которой посетитель с уникальным выигрыш-кодом из пакета продуктов может сразу же выиграть, введя только код. После подтверждения выигрышного кода клиент хочет получить электронную почту и т. д. Это необычно, но гораздо более благосклонно, чем запрашивать электронную почту и личные данные перед проверкой, выиграл ли он i.m.h.o.
Итак, поток для посетителя будет:
[ ENTER CODE ]
!win -> [ TOO BAD ]
win -> [ CONGRATULATIONS ] -> [ ENTER PERSONAL DATA ]
Этот сценарий будет означать, что бот грубой силы может пробовать коды до тех пор, пока ответ не будет отличаться, что подразумевает выигрышный код. Вы бы использовали / построили (пере) капчу?
Как бы вы защитили от наводнения? Злоумышленник может легко подделать IP / UserAgent для каждого запроса.
Можно ли вообще защитить такой механизм в этом потоке?




Общий вопрос, общий ответ ...
Лучше сделать код достаточно длинным, чтобы это стало невозможным.
Рассмотрим модель угроз: зачем кому-то прилагать усилия для этого? Выплаты так высоки?
Злоумышленнику нет смысла подменять IP-адреса, поскольку они никогда не увидят ответы, и они не могут подделать IP-адрес с помощью TLS и HTTP в любом случае (они могут прятаться за прокси, но это не подделка). Пока количество прокси / IP-адресов намного меньше количества возможных кодов, у вас не должно возникнуть проблем с ограничением по IP.
Вы можете сделать запросы дорогими - используйте систему запрос-ответ, чтобы клиенты выполняли огромное количество итераций хеширования для запросов с ограничением скорости (см. Hashcash). Если это занимает 1 секунду, это значительно ограничивает потенциальную частоту запросов, но не сильно наказывает реальных пользователей.