Pull to refresh

Comments 4

Хочется поднять на обсуждение такой вопрос. А что если не блокировать ботов, а возвращать им некорректную информацию. По крайней мере когда мы более чем на 90% уверены (если уверены на все 100, кидать 403, для имитаций защиты) что это бот, и только в методах которые имеют какую-то ценность для тех, кто их собирает. Например товары в интернет магазине. Можно строить хеш из фингерпринта клиента и использовать его как сид для изменения цен, артикула, наличия и добавления орфографических ошибок в название и описание товара, перемешивать фото, причём не обязательно для всех, а например 50%, и только начиная с 3 страницы выдачи. Вероятнее всего те кто их собирают заметят что их данные испорчены далеко не сразу, а использования хеша сделает запросы детерминированными и усложнит отладку. А прикручивание такой защиты можно реализовать через middleware без изменения какой либо логики методов. Одно дело видеть ошибку и понимать что нужно копать глубже что б обойти защиту, а другое понимать что ты не можешь доверять тем данным которые собираешь

У меня в статье tarpit по сути так и работает, только для чата, а не для товаров. Подозрительный запрос получает правдоподобный фейковый ответ — готовый текст, стрим, задержка, — но LLM не вызывается и баланс не списывается. Бот не понимает, что его отсекли, и не идёт искать обход.

С товарами это жёстче, потому что данные ценнее: подмена цен и наличия бьёт по тому, ради чего вообще собирают. Единственное, о чём бы помнил, — цена ошибки. Ложное срабатывание у меня в худшем случае даёт живому человеку бесполезную реплику, а на товарах это уже неверная цена реальному покупателю или случайно отравленный Googlebot. Поэтому под такое держал бы порог выше и отдельно исключал поисковики.

Ботов разрабатывает человек, и использует для этого обычный браузер, и тестирует на headless chrome через playwright к примеру.

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

А если серьёзно, для таких случаев можно просто поднимать обычный браузер, с экраном, которым управляет бот в песочнице. На одну сигнатуру надеятся нельзя, например google recaptcha enterprise, в дополнение к сигнатуре, сравнивают публичный IP по своим базам, облачные режут, так что даже обычный браузер запущенный в облаке не прокатит.

Всё так — и это ровно то, на что я и рассчитывал. Цель была не «непробиваемо», а поднять цену атаки. Headless дёшев, а реальный браузер с экраном в песочнице на каждый аккаунт — уже совсем другие деньги. Так что «поднять обычный браузер» — это не обход защиты, а её срабатывание: я туда и загонял. Кто тестит руками — заметит и эскалирует до дорогого стека; кто шлёт fire-and-forget скрипты — ест тихий фейк дальше.

Про одну сигнатуру согласен — решает сумма, а не один отпечаток; IP-репутация у меня тоже в score (как и у reCAPTCHA Enterprise). А капчу сознательно не ставлю: это чат-виджет, конверсия решает всё, хард-челлендж режет живых пачками. Поэтому защита невидимая — score, tarpit, PoW.

Sign up to leave a comment.

Articles