Обход защиты от DDOS nginx test-cookie-module

Модуль 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-кода загадки также смысла не имеет, так как для прохождения защиты можно использовать полноценный браузер и назначать тупым ботам скопированные из него куки.