Обновить

Как мы сделали капчу, когда hCaptcha отказался работать для российских пользователей

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели7.9K
Всего голосов 7: ↑6 и ↓1+8
Комментарии9

Комментарии 9

Мы для форм логина регистрации и тп капчу не используем. Генерим динамические имена параметров для форм, кладем их в сессию на сервере. Так же ставим в формах honeypot-ы для ботов без поддержки js.

Попавшийся бот маркируется как серый, дальше при последующем запросе анализируется соотношение кол-ва запросов к защищаемой части ресурса к общему кол-ву запросов к остальным частям ресурса, для реального посетителя этот параметр плюс/минус всегда одинаковый. Если бот не проходит проверку, он помечается как "черный" с соответствующими последствиями для него. "Белые" боты исключены из проверок.

Пользователь видит капчу, решает ее

Я как пользователь ухожу(за редчайшим исключением) от сервисов с такой политикой.

Замечу, что более продвинутые сервисы(например Cloudflare) умеют отличать человека от бота просто по манере клика по чекбоксу "Я человек".

А сталкивались ли вы с тем, что попадались на нашу капчу? Просто до нее ещё есть автоматический этап валидации, который на моей памяти меня не кидал на страницу прохождения капчи. Несомненно, будут наблюдаться false positive, но это скорее исключение

К сожалению не смогу сказать попадалась ли ваша. Как писал выше мой алгоритм простой: "вижу каптчу, ухожу с ресурса". Тоесть где чья каптча не уточняю и не запоминаю.

Уже и не помню, когда разгадывал эти ребусы (очень напряжно иногда). В последнее время чаще ищем светофоры или переходы на фото.

Уже в 22 разгадывали подобные капчи специальными ocr'ками. Не думаю, что в данный момент есть что-то более удобное, чем скрытые js-капчи.

Помню одним из первых заданий на самой первой работе было что-то сделать с каптчами, тогда тоже хорошо проигрался с дизайном, но генерили мы кодом эти картинки (идеальная задача для джуна – сделать свою капчу, особенно в год появления Stack Overflow, читай - не было)

Сейчас же наблюдаю, как ботики или ресёрчеры спотыкаются на:

  1. просто CSRF токенах

  2. на том, что на каждое поле - свой api endpoint с ключом продолжения в ответе (да, похоже на csrf, но суть во множестве endpoints)

  3. На рандомных задержках

  4. И рейтлимитах

  5. В особых случаях – JavaScript challenge (без UI!)

Тут главное, чтобы интерфейс (пользователь) при том не ждал ответа сервера, если чисто визуально можно продолжать заполнять "форму"

И как заметили выше – рандомные имена параметров тоже неплохой вариант

А вот капчи, которые нужно разгадывать – это ж прошлый век, как впн и кнопочные телефоны (да, они всё ещё есть и используются, но не вы же?)

Чуть идей можно найти тут https://yoursec.substack.com/p/login-page-for-modern-applications

А про 2й пункт можно пример посмотреть? Интересно.

Делал пункт два на time based endpoint name... Ну т.е. шифрованное время по некоторому алгоритму с солью в URL. Если время не расшифровывается или интервал больше N (попытка переиспользования старых endpoint) то запрос отбрасывается. В этом случае вообще статичных endpoint нет. Ну да, токен, но time based. Port knocking, если у вас свой клиент и сервер, тоже неплохо работает.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Информация

Сайт
ddos-guard.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
netguard