Рекапча попадает на НАШ сервер с помощью POST-вызова api2/clr (что приводит к ошибке 404)
В последние несколько дней мы наблюдаем растущее число ошибок 404 следующего формата: (некоторые материалы отредактированы)
1.1.1.1 - - [11/Jul/2024:14:00:56 +0000] "POST /recaptcha/api2/clr?k = {our_site_key} HTTP/1.1" 404 5126 "https://{some_url_on_our_site}" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15"
2.2.2.2 - - [11/Jul/2024:14:16:46 +0000] "POST /recaptcha/api2/clr?k = {our_site_key} HTTP/1.1" 404 1698 "https://{some_url_on_our_site}" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 Edg/126.0.0.0"
3.3.3.3 - - [11/Jul/2024:18:08:07 +0000] "POST /recaptcha/api2/clr?k = {our_site_key} HTTP/1.1" 404 1698 "https://{some_url_on_our_site}" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36"
4.4.4.4 - - [11/Jul/2024:18:13:37 +0000] "POST /recaptcha/api2/clr?k = {our_site_key} HTTP/1.1" 404 1698 "https://{some_url_on_our_site}" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Mobile Safari/537.36"
5.5.5.5 - - [11/Jul/2024:19:11:10 +0000] "POST /recaptcha/api2/clr?k = {our_site_key} HTTP/1.1" 404 1698 "https://{some_url_on_our_site}" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
6.6.6.6 - - [11/Jul/2024:19:47:14 +0000] "POST /recaptcha/api2/clr?k = {our_site_key} HTTP/1.1" 404 1150 "https://{some_url_on_our_site}" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36"
Как видите, это широкий спектр машин и браузеров. Этого URL-адреса не существует на НАШЕМ сервере... он должен быть направлен на сервер Google, но по какой-то причине это не так.
Кроме того, мы уже давно не меняли нашу интеграцию Recaptcha v2 Invisible, поэтому это «новое поведение» не является нашей заслугой (насколько нам известно). Я также не могу воспроизвести это сам на своих Mac/ПК, но их количество растет (возможно, в какой-то момент я смогу это воспроизвести).
У кого-нибудь есть идеи, что здесь может происходить?
Обновлено: при захвате тела сообщения (вход php://) данные, которые он пытается отправить на наш сервер, представляют собой зашифрованную кучу. Это большой объем двоичных файлов, для которых нужен ключ (и ни наши открытые, ни секретные ключи Google не работают, как я пробовал).
та же самая проблема здесь
Мы наблюдаем ту же проблему. Скрипт recaptcha отправляет API-запрос из браузера на относительный URL-адрес /recaptcha/api2/clr вместо абсолютного (Google) URL-адреса для некоторых пользователей. В этом случае рекапча НЕ РАБОТАЕТ. JS-скрипт обратного вызова не запускается, и обратная передача нашего сервера не включает токен ответа на рекапчу.
Мы тоже видели это в последние несколько дней, однако, несмотря на тщательное расследование сегодня, у меня сложилось впечатление, что это перестало происходить в течение последних 30-60 минут или около того, поэтому я думаю, что Google выпустил обновление своих скриптов, чтобы это исправить. Ребята, вы тоже это видите?
Ответы 4
Та же ошибка на нашем сайте. POST на <websitedomain.fr>/recaptcha/api2/clr?k= вызывается https://www.gstatic.com/recaptcha/releases//recaptcha__fr.js
У нас 404. Это происходит на 20 сайтах на разных хостингах.
Лучшее, Себ
Как сейчас написано, ваш ответ неясен. Пожалуйста, отредактируйте , чтобы добавить дополнительную информацию, которая поможет другим понять, как это относится к заданному вопросу. Более подробную информацию о том, как писать хорошие ответы, вы можете найти в справочном центре.
Та же ошибка на нашем сайте: брандмауэр блокирует множество людей по следующим причинам: Запрос: POST /recaptcha/api2/clr?k = {наш ключ} Описание действия: Внимание. Обоснование: требуется соответствие «внутри %{tx.allowed_request_content_type}» и «TX:content_type».
Мы временно отключили правило mod_security 920420 (OWASP3) и надеемся, что Google разберется с этим.
Кажется, Google разрешил этот инцидент: status.cloud.google.com/incidents/MzARofVtutSd2HB5vmkT Мы снова включили правило, теперь кажется, что все в порядке.
То же самое происходит и с нами. Мы используем библиотеку react-google-recaptcha-v3, и сначала я продолжал исследовать этот уровень, но эта библиотека никак не может испортить URL-адрес. Должно быть, это проблема непосредственно в библиотеке Google reCaptcha, поэтому я чувствую, что ничего не могу сделать.
открытый инцидент в сервисе Recaptcha Google: https://status.cloud.google.com/incidents/MzARofVtutSd2HB5vmkT
Хорошая находка! Хорошо, этот ответ на самом деле является наиболее точным для ответа на мой вопрос... поскольку он показывает: «Это проблема Google, они знают об этом, они должны это исправить».
У меня нет ответа, но мы тоже с этим сталкивались. Исходный IP-адрес, похоже, является браузером клиента, поэтому я не уверен, что происходит. Похоже, что Recaptcha JS перезванивает на сервер, ожидая, что это действующий URL-адрес.