Пост запрос стал получать проверку JS

[Sekotka]

Всем привет! Помогите пожалуйста разобраться, регил аккаунты post запросами на band camp .com / signup (добавил пробелов), админов видимо это достало и теперь когда я делаю пост запрос, мне вываливается ответом, что я не прошел js проверку (js не включен в браузере). Причем можно его успешно пройти в веб, но дальше все равно любой пост запрос закончится js проверкой. Подскажите, может я что-то ключевое не знаю как в таких ситуациях действовать? Данные для запроса и куки все использовал как обычно...

 

[Sekotka]

Никто не сталкивался? Даже если я в инстансе запускаю страницу, получаю все актуальные куки и выполняю js при отправке POST я получаю ответ из разряда "JavaScript is disabled in your browser." Заголовки все копирую под чистую...

 

[profi88]

А ты пробовал эмулировать браузер?


В чем именно цель регистраций?


Пробовал использовать мобильные прокси/ротацию IP?

Почему вы видите «JS проверку»

1. Современные сайты используют проверку на стороне клиента (JavaScript) для:
   • генерирования одноразовых токенов (anti-CSRF / fingerprint tokens),
   • выполнения скриптов для обнаружения ботов (анализ поведения, проверка наличия JS-движка),
   • вызова внешних анти-бот сервисов (Cloudflare, Akamai, PerimeterX и т.д.).
2. Если ваш POST-запрос идёт без выполнения нужного клиентского JS, сервер считает запрос неполным/подозрительным и возвращает страницу «пройдите JS-проверку» или капчу.
3. Веб-интерфейс успешен, потому что браузер выполняет эти скрипты и передаёт нужные параметры/куки/заголовки.

 

[Sekotka]

Да я же говорю, все работало нормально, регистрировал профили для своих задач, но сейчас сделали js защиту. Причем я понимаю когда GET запросы не отдают какие-то данные, но чтобы пост запрос я с таким раньше не сталкивался. Причем нет CF и тд. Заголовки копировал из сниффера, цепочку соблюдал. Даже я говорю, делаю инстанст, который выполняет все js и получает нужные куки, но финальный пост запрос проваливается. Дальнейшее обращение пост запросами также везде провально....

 

[profi88]

1. Причины, почему POST блокируют после успешного JS в браузере: токен/nonce генерируется в рантайме и привязан к сессии/IP/времени; JS делает дополнительные фоновые запросы (XHR/fetch/WebSocket) и только после них сервер считает сессию валидной; сервер ждёт определённого набора куки/localStorage/заголовков и порядка загрузки ресурсов; возможен TLS/J A3 или прокси-фингерпринтинг; есть server-side rate/behavior checks.
2. Что проверить сейчас: сравните полный сетевой лог браузера с вашим автоматом (включая редиректы, third-party запросы, Set-Cookie, localStorage, порядок запросов и timing); убедитесь, что финальный POST идёт с теми же куки, Origin/Referer, Content-Type и телом; проверьте, не зависит ли токен от IP или времени.

 

[Sekotka]

Да в том то и дело, может у меня мало опыта, но все делается в нужный момент. Т.е. даже при полной эмуляции через браузер, введу все данные ручками, а потом вместо условно "зарегистрировать" выполню пост скрипт (который вчера еще работал), получу "У вас не включен js" Аналогичные скрипты дальше все также отвалились. С куками и тд. порядок, заголовки вроде тоже сниффаю 1 в 1... Прям голову сломал...

 

[profi88]

Когда защита сместилась с классической JS/cookie проверки на более сложный сервер-сайд детект.

Даже если вы выполняете JS в браузере, сервер может проверять:

1. Время жизни токена — многие современные системы (DataDome, Akamai, кастомные антиботы) привязывают токены к точной сессии и времени. Если POST идёт с задержкой или через внешний скрипт, сервер считает его недействительным.
2. Вторичные фоновые запросы — страницы часто делают скрытые XHR/fetch-запросы после JS-челленджа, которые формируют серверные флаги. Без их выполнения POST блокируется.
3. Fingerprinting beyond cookies — анализируется TLS JA3, порядок сетевых пакетов, шрифты, canvas/WebGL, размеры окна, движки JS, даже поведение мыши/ввод. Ваш скрипт может не воспроизводить всё это идеально.
4. Связь с IP/гео — токен и JS challenge могут привязываться к IP или сети, и если POST идёт из другого процесса/машины — блок.

Вывод: причина в том, что сервер уже не проверяет только JS/куки — проверка перешла на комплексную сессионную валидацию на стороне сервера.

 

[Sekotka]

Да вроде в Fiddler должны быть видны эти запросы и тд... К тому же из токенов там только капча гугла, остальное в куках передается и вроде как полный набор кук (из инстанса) должен был решить проблему

 

[profi88]

Да вроде в Fiddler должны быть видны эти запросы и тд... К тому же из токенов там только капча гугла, остальное в куках передается и вроде как полный набор кук (из инстанса) должен был решить проблему

Да, всё верно — Fiddler позволяет видеть все запросы, редиректы, заголовки, куки и тело POST, и на первый взгляд кажется, что полный набор куки решает проблему. Но на практике антибот делают шаги, которые не всегда видны на уровне одного POST-запроса:

1. Скрытые фоновые запросы после JS — это могут быть fetch/XHR к другим эндпойнтам, которые формируют серверные «флаги». Даже если у вас все куки, сервер может видеть, что эти запросы не прошли, и блокировать POST.
2. Сессия + fingerprint — токен может быть привязан не только к cookie, но и к конкретной сессии браузера (размер окна, canvas/WebGL, тайминги загрузки JS, последовательность запросов). Даже с правильными куками POST из внешнего скрипта может «не пройти».
3. Время жизни токена — некоторые серверы требуют, чтобы POST был сделан в пределах нескольких секунд после завершения JS. Любая задержка ломает проверку.

Проблема не в куках, а в комплексной проверке сессии и JS-флагов.

 

[Sekotka]

Я не понимаю, вы мне ответы чатГПТ копируете?)))

 

[profi88]

Я не понимаю, вы мне ответы чатГПТ копируете?)))

Нет )

 

[Sekotka]

Так все таки, возможно обычные ПОСТ запросы Зенки палятся (не хватает заголовков)?

 

[profi88]

Так все таки, возможно обычные ПОСТ запросы Зенки палятся (не хватает заголовков)?

Это одна из причин, ответ - только тесты и эксперименты на валид.

 

[Sekotka]

Поменял вариант выполнения http запросов на альтернативный и проблема решилась. Капец.

 

[Sekotka]

ну вот, сегодня и альтернативный метод перестал работать, выполняется js проверка.... Кто может подсказать куда копать?

 

[Jufel]

ну вот, сегодня и альтернативный метод перестал работать, выполняется js проверка.... Кто может подсказать куда копать?

Попробуй выполнить запрос через curl

 

[Sekotka]

Чекнул, там поставили защиту fastly, вероятно ее рук дело... Никто не имел с ней дел?