в апишке гугла, как работает их рекапча и увидел, что там предусмотрено для других сайтов обращение к апи гугл на проверку g-recaptcha-response, и там требуется secret key, который известен только самому Гуглу
это не из этой темы
берешь отладчик – Хром или Селениум или Фидлер или все вместе,
смотришь что куда приходит уходит,
потом заменяешь в своем скрипте отправку на ручную и вводишь с текущего хоста,
таймауты,
добиваешься проходимости,
потом ручную меняешь на антикапчу,
не забываешь за таймауты,
Фишка гугловской рекапчи, что она сидит в коде на требуемом вам сайте. При прохождении капчи отправляется форма вместе с секретным ключом, который проверяется у гугла, что секретный ключ правильный и после этого идет обычная работа сайта.
Так что скорей всего у вас не получится "на изи", там все же специалисты не за 40к зп сидят.
У меня получалось обойти проверку на Яндексе через правильно подставленные заголовки и подмена куков, может и здесь проканает. Самое главное это ведь максимально притвориться человеком.
ReCaptcha (она же всенародно любимая «капча») — одна из самых болезненных вещей, с которой может столкнуться автоматизатор тестирования на своём пути. В Сети гуляют тысячи разнообразных видео, записанных выходцами из солнечной Индии, касательно того, какими танцами с бубном возможно обмануть этого зверя. Действительно, достаточно сложно пытаться взаимодействовать с помощью запрограммированных скриптов со штукой, основная цель которой — убедиться что «вы не робот».
Очень важный дисклеймер: обмануть капчу невозможно.
Если вы уже столкнулись с этой проблемой, и читаете эту статью, пытаясь нагуглить рецепт панацеи, то знайте, что его не существует. Тем более, в вашей голове уже скорее всего возникли инновационные мысли о том, чтобы сымитировать реалистичное поведение пользователя с помощью WebDriver, путём рандомного mouse overing’а элементов, кликов по инпутам, и бережно расставленных Thread.sleep(). Абсолютно точно известно, что этот подход работать не будет, не тратьте свое время попусту.
Получается, выхода нет?
Не все так пессимистично. Иногда достаточно постараться дать себе наиболее точный ответ на вопрос «Какая задача передо мной стоит?» и посмотреть на ситуацию шире. В большинстве случаев, вы поймете, что ваша цель не обмануть капчу, а обойти её, чтобы протестировать функционал, спрятанный за ней. На примере своего кейса, я поделюсь с вами найденными мною вариантами решения поставленной задачи.
Контекст: мы интегрировали часть своего продукта внутрь стороннего сервиса, и хотели мониторить, все ли в порядке на их стороне, т.к. они не занимаются покрытием third-party частей своей платформы. Чтобы получить доступ к нашему функционалу, сперва необходимо было залогиниться. Тут-то я и встретился с капчей лицом к лицу. Далее привожу все перепробованные мною варианты обхода данной проблемы.
Нерабочие
Залогиниться через Google или Facebook
Помимо классической аутентификации, присутствовали каноничные «Login with Google / Facebook». Само собой, там точно также присутствовали свои «капчи», поэтому этот вариант не помог решить проблему.
Имитация поведения пользователя
Да, я тоже это пробовал. Было забавно, но чересчур наивно.
Рабочие
Chrome / Firefox Profiles
Поговорим о первом «живом» варианте. В драйверах для этих браузеров (chromedriver / geckodriver) реализована возможность загружаться под заранее заготовленным User Profile. Он хранит в себе все сохраненные пароли, куки, сессии, и даже историю браузера и закладки. Т.е. таким образом мы попросту пропускали абсолютно неважный для нашей задачи шаг логина, и таким образом попадали сразу на страницу с объектом тестирования. Реализуется это следующим образом:
- Создаем «чистый» профиль браузера
- Вручную вводим капчу и логинимся на нужный ресурс
- Копируем необходимый профиль в наш проект (HOWTO для Firefox и Chrome)
После чего, нам необходимо сказать драйверу, что грузиться он должен именно с указанного профиля:
Этот подход хорошо показал себя при тестировании на локальной машине с установленным браузером и обычными gecko-/cromedriver’ами, но возникли проблемы при запуске на Jenkins. Мы поднимаем Selenium хаб и ноды внутри Kubernetes кластера, поэтому мы столкнулись с неприятностями в виде слишком долгого по времени маунта директории внутрь контейнера (чистый профиль в среднем весит около 25 MB, что немало), а так же некоторых проблем с CRUD правами браузера, который не мог вносить изменения в профайл в рантайме, и падал с “unknown error: failed to write prefs file” эксепшеном. Ко всему прочему, апдейтить профайл после достижения куками и сессиями своих Expiration Dates достаточно неудобно, да и не хотелось держать в проекте огромную папку с внутренностями профиля, поэтому в конечном итоге окончательным был выбран следующий вариант.
Cookies
“А ларчик просто открывался” — именно так можно было охарактеризовать ситуацию, после того, как мы просто добавили полученные вручную куки в драйвер. Алгоритм действий максимально прост и не зависит от выбранного браузера:
- Логинимся вручную
- Через Network смотрим Request Headers -> Cookie которые посылает наш браузер
Добавляем их в наши тесты следующим образом:
Очевидный минус этого подхода — необходимость вручную менять куки после истечения их срока валидности. Но, в виду того что на тестируемой платформе этот срок составляет 3 месяца — мы и выбрали это решение.
А если мне не нужно логиниться?
А как же ситуация, когда речь идет не о авторизации и сессиях, а о совершении какого-либо одноразового действия (e.g. оформление заказа из корзины, регистрация нового пользователя и т.п.)? Здесь ситуация еще хуже. Два варианта которые я смог обнаружить, это:
- Договориться с вашими разработчиками о предоставлении вам некого workaround’а. Google предоставляет такую возможность, но помните, что вы осознанно делаете небольшую дыру в security.
- Воспользоваться сторонними платными сервисами, которые принимают с вашей стороны скриншот капчи, пытаются его декодировать, и отправляют вам расшифрованное значение. Сам я такой способ не пробовал и полностью рекомендовать его не могу.
Подведем итоги
Как вы могли убедиться — безвыходных ситуаций не бывает. Однако, будет глупо отрицать, что у абсолютно всех вышеперечисленных вариантов есть свои, достаточно весомые, минусы, так что выбор остается за вами.
unCAPTCHA – автоматизированная система, разработанная экспертами Мэрилендского университета, способная обойти reCAPTCHA от Google с точностью до 85 %. Им это удалось благодаря распознаванию аудио-версии подсказки для людей с ограниченными возможностями.
Метод использует уязвимость в звуковой версии reCAPTCHA — в ней произносится числовой код, который затем необходимо ввести в проверочное поле. Алгоритм применяет несколько сервисов, которые помогают определить числа — в том числе сервис Google Cloud Speech Recognition.
Исследователи опубликовали код своего проекта на GitHub. В unCAPTCHA используются такие средства распознавания речи, как Bing Speech Recognition, IBM, Google Cloud, Google Speech Recognition, Sphinx и Wit-AI.
Принцип работы
Формат аудиокоманды представляет собой серию чисел различной длины, произнесенных на разных скоростях, акцентах и через фоновый шум. Чтобы атаковать эту капчу, звуки идентифицируются и автоматически разбиваются по частям.
Каждый бит аудиосигнала каждого числа загружается в 6 различных бесплатных онлайн-сервисов транскрипции аудио (IBM, Google Cloud, Google Recognition, Sphinx, Wit-AI, Bing Speech Recognition), и эти результаты агрегируются. После объединения наиболее вероятная строка выявляется эвристически. После этого числа последовательно набираются в капчу. При тестировании наблюдалась точность от 92% для отдельных чисел и до 85% в распознавании аудиокоманды в полном объеме.
unCAPTCHA является не первой системой подобного рода. В марте текущего года была информация об атаке с использованием ReBreakCaptcha, системы, практически идентичной unCAPTCHA.
Видео-демонстрация работы
Тесты показывают, что unCAPTCHA может решить 450 задач reCAPTCHA с точностью 85,15% за 5,42 секунды. Это меньше, чем требуется человеку для прослушивания одного звукового файла reCAPTCHA.
unCAPTCHA
Код проекта написан на python с использованием популярной библиотеки selenium и FFmpeg — набором библиотек с открытым исходным кодом, которые позволяют записывать, конвертировать и передавать цифровые аудио-сигналы.
→ Исходный код опубликован на github.
По ссылке доступно исследование от создателей утилиты.
Разработчики уведомили о своем исследовании специалистов Google, в результате чего уже добавлены новые меры защиты от подобных атак.
