Модуль test-cookie-module github.com/kyprizel/testcookie-nginx-module
Упрощенно, модуль шифрует какую-то строку, идентифицирующую клиента, и клиент должен в браузере их расшифровать и результат кинуть в куки, чтобы последующие запросы начали проходить.
По дефолту это IP-адрес.
В JS коде клиенту приходит ключ, вектор инициализации и строка, которую нужно расшифровать.
Если в качестве источника данных используется IP, достаточно загрузить и решить загадку для каждого бота. Результат назначить им куки, чтобы они могли работать дальше.
В случае использования источников, напрямую контролируемых клиентом (на этом форуме используется User-Agent), достаточно вычислить результат один раз.
С дефолтным ответом модуля извлечение данных для вычисления ответа выглядит так:
my( $key, $iv, $str) = map{ pack "H*", $_ } $html =~ m/"([a-z0-9]{32})"/g;
Да, вот так просто :)
Вычисление ответа:
use Crypt::CBC ;
use Crypt::OpenSSL::AES ;
...
my $cipher = Crypt::CBC->new(
'-key' => $key,
'-cipher' => "Crypt::OpenSSL::AES",
'-keysize' => 16,
'-literal_key' => 1,
'-iv' => $iv ,
'-header' => 'none',
);
my $challenge = unpack( 'H*', $cipher->decrypt( $str ) );
Переменная challenge содержит в себе значение, которое нужно положить в куки, чтобы запросы начали проходить.
Решение не обязательно считать в скрипте, достаточно скопировать его из браузера вместе с остальными заголовками!
Выводы:
Модуль не может обеспечить защиту против ботов, которые умеют устанавливать куки и заголовки.
Использование более сложных механизмов получения данных для загадки не даст значительного выигрыша, так как довольно легко установить, от чего результат зависит и от чего нет, и настроить ботов.
Дальнейшая обфускация JS-кода загадки также смысла не имеет, так как для прохождения защиты можно использовать полноценный браузер и назначать тупым ботам скопированные из него куки.
