Это неизбежно ;) Но даже в данном случае 2 материала — абсолютно разные: на гиктаймсе статья более информационно-направленная, здесь — связана с разработкой, что вполне даже хорошо.
Ранее тоже задавался этим вопросом, поэтому перенес свои ресурсы к рос. провайдеру с ценами в рублях. К сожалению, товарищи из infobox не удержались и 28 ноября текущего года подняли цены на услуги в среднем на 30% (600 => 800 руб / 300 => 400 и т.д.).
При этом цены подняли не только для новых клиентов, а и для тех, кто ранее пользовался услугой, уведомив об этом примерно за ~2 недели.
Натыкался на эту проблему тоже — она возникает когда на 1 странице есть 2 или более капчи и каждая пытается подтянуть гугловский js по калбеку или без него. Подобное так же возникает если попробовать выгрузить капчу по AJAX без использования калбэк-метода.
reCaptcha ведь имеет прямое отношение к веб-разработке и к информационной безопасности(защита от спама, к сожалению у меня нет 5 рейтинга для публикации в хаб Спам/Антиспам) поэтому публикация вполне соответствует тематике ресурса.
Все верно, релиз был где то в ноябре, выше я об этом говорил. Попросту подобной новости не было в просторах интернета, в том числе на хабре и я решил опубликовать материал, который может быть(по моему мнению) полезным для многих кто не знал об этом.
По тому, что мне удалось «раскопать» о дате релиза — он был где-то в ноябре (странички документации созданы/редактированы в середине ноября, на гитхабе php библиотека опубликована неделю назад).
На данный момент попытки эксплуатации описанной уязвимости уже встречаются. Их пока нельзя назвать массовыми – но если у вас старый WordPress, стоит всё-таки обновиться.
Все верно, тест Тьюринга здесь необходим, но отношения к «хешу» он не имеет. И да, для recaptcha есть уйма сервисов по разгадыванию за символичный бакс на тысячу, а с ip могут возникнуть в дальнейшем и проблемы, связанные с увеличением кол-ва пользователей сети (v4 провайдеры смело выдают 1 на всю подсеть) и переходом(в перспективном будущем) к ipv6 ;)
И что бы вы тогда проверяли? )) Как не крути — вам придется передать клиенту данные, на основе которых вы после и будете проверять корректность запроса. Зная алгоритм проверки запроса(или нет) — как не извращайтесь, эти данные легко подделать(даже получив данные как легитимный клиент приложения).
Просто хэш он на то и хэш — если идет где то его проверка и она как-либо связана с клиентскими данными то и на стороне клиента должна быть какая-либо строка, которая позволит в дальнейшем сгенерировать данную хэш-сумму (ведь функция — необратима). Здесь он роль «хэша» не исполняет вовсе — т.к. по сути это строка отданная клиенту и в дальнейшем проверенная на подлинность.
Ну и в чем проблема с этим «хэшем»? Он отображается прямо на странице пользователю и далее передается в js функцию rating() 3-им параметром, после отправляется в $.post {} вместе с остальными хедерами. /servers.php (~156-162)
Открываем нужную страницу, дергаем hash и его же подставляем к выше описанному вами методу как параметр 'hash' (post) и ненужно там ничего генерировать, никакие соли нам не важны.
И после использовать в behaviors -> AccessControl:
Не боясь что в этот же раздел попадет виртуальный Guest ;)
При этом цены подняли не только для новых клиентов, а и для тех, кто ранее пользовался услугой, уведомив об этом примерно за ~2 недели.
Теперь это лишь вопрос времени.
/servers.php (~156-162)Открываем нужную страницу, дергаем hash и его же подставляем к выше описанному вами методу как параметр 'hash' (post) и ненужно там ничего генерировать, никакие соли нам не важны.