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

Sekotka

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

Sekotka

Client
Регистрация
07.10.2015
Сообщения
81
Благодарностей
23
Баллы
8
Никто не сталкивался? Даже если я в инстансе запускаю страницу, получаю все актуальные куки и выполняю js при отправке POST я получаю ответ из разряда "JavaScript is disabled in your browser." Заголовки все копирую под чистую...
 

profi88

Client
Регистрация
10.09.2018
Сообщения
321
Благодарностей
50
Баллы
28
А ты пробовал эмулировать браузер?


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


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

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

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

Sekotka

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

profi88

Client
Регистрация
10.09.2018
Сообщения
321
Благодарностей
50
Баллы
28
  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

Sekotka

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

profi88

Client
Регистрация
10.09.2018
Сообщения
321
Благодарностей
50
Баллы
28
Когда защита сместилась с классической 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

Client
Регистрация
07.10.2015
Сообщения
81
Благодарностей
23
Баллы
8
Да вроде в Fiddler должны быть видны эти запросы и тд... К тому же из токенов там только капча гугла, остальное в куках передается и вроде как полный набор кук (из инстанса) должен был решить проблему
 

profi88

Client
Регистрация
10.09.2018
Сообщения
321
Благодарностей
50
Баллы
28
Да вроде в Fiddler должны быть видны эти запросы и тд... К тому же из токенов там только капча гугла, остальное в куках передается и вроде как полный набор кук (из инстанса) должен был решить проблему
Да, всё верно — Fiddler позволяет видеть все запросы, редиректы, заголовки, куки и тело POST, и на первый взгляд кажется, что полный набор куки решает проблему. Но на практике антибот делают шаги, которые не всегда видны на уровне одного POST-запроса:

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

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

Sekotka

Client
Регистрация
07.10.2015
Сообщения
81
Благодарностей
23
Баллы
8
Я не понимаю, вы мне ответы чатГПТ копируете?)))
 
  • Спасибо
Реакции: Oleg1987

profi88

Client
Регистрация
10.09.2018
Сообщения
321
Благодарностей
50
Баллы
28

Sekotka

Client
Регистрация
07.10.2015
Сообщения
81
Благодарностей
23
Баллы
8
Так все таки, возможно обычные ПОСТ запросы Зенки палятся (не хватает заголовков)?
 

profi88

Client
Регистрация
10.09.2018
Сообщения
321
Благодарностей
50
Баллы
28

Sekotka

Client
Регистрация
07.10.2015
Сообщения
81
Благодарностей
23
Баллы
8
Поменял вариант выполнения http запросов на альтернативный и проблема решилась. Капец.
 

Sekotka

Client
Регистрация
07.10.2015
Сообщения
81
Благодарностей
23
Баллы
8
ну вот, сегодня и альтернативный метод перестал работать, выполняется js проверка.... Кто может подсказать куда копать?
 

Zedx

Client
Регистрация
12.06.2018
Сообщения
1 504
Благодарностей
1 021
Баллы
113
ну вот, сегодня и альтернативный метод перестал работать, выполняется js проверка.... Кто может подсказать куда копать?
Попробуй выполнить запрос через curl
 
  • Спасибо
Реакции: Sekotka

Sekotka

Client
Регистрация
07.10.2015
Сообщения
81
Благодарностей
23
Баллы
8
Чекнул, там поставили защиту fastly, вероятно ее рук дело... Никто не имел с ней дел?
 

Кто просматривает тему: (Всего: 1, Пользователи: 0, Гости: 1)