Wyjaśnienie systemu Kasada Anti-Bot: jak działa i jak przejść czysto w 2026

Jeśli jesteś inżynierem scrapingu lub badaczem anti-bot, prawdopodobnie spotkałeś się z błędem 429 z nagłówkiem x-kpsdk-ct i zastanawiałeś się, co dokładnie Kasada sprawdza, zanim w ogóle puści Cię do challenge'u JavaScript. Wyjaśnienie systemu Kasada Anti-Bot wymaga zrozumienia nie tylko samego skryptu ips.js, ale całej warstwy detekcji — od reputacji IP, przez odcisk TLS, aż po zaszyfrowane ładunki z wirtualnej maszyny bytecode. Ten artykuł rozkłada każdy komponent na czynniki pierwsze i pokazuje, jak legalna, autoryzowana automatyzacja może przejść te kontrole czysto, używając proxy rezydencjalnych ProxyHat.

Wyjaśnienie systemu Kasada Anti-Bot: architektura i filozofia

Kasada to platforma anti-bot, która przyjęła odmienną filozofię niż klasyczne WAF-y czy CAPTCHA. Zamiast reagować na znane wzorce ruchu botów, Kasada buduje aktywny challenge już przy pierwszym żądaniu do chronionej strony. Każdy klient — przeglądarka czy automatyzacja — musi wykonać obliczenia po stronie klienta, zanim serwer zweryfikuje token i przyzna dostęp. To podejście „proof-of-work + fingerprinting" sprawia, że proste biblioteki HTTP bez silnika JS są bezużyteczne.

Kluczowe elementy architektury Kasada to:

• Skrypt ips.js — około 449 KB zakodowanego bytecode'u uruchamianego w niestandardowej wirtualnej maszynie (VM) zamiast czystego JavaScriptu.
• Ciasteczko KP_UIDz — token sesyjny wydawany po pomyślnym rozwiązaniu challenge'u, przechowywany w przeglądarce.
• Rodzina nagłówków x-kpsdk-ct, x-kpsdk-cd, x-kpsdk-dv — zaszyfrowane nagłówki HTTP przenoszące wynik challenge'u, dane urządzenia i dynamiczny wektor weryfikacji.
• Wstępne filtrowanie TLS i HTTP/2 — zanim jakikolwiek JS się wykona, Kasada profiluje odcisk TLS (JA3/JA4) i nagłówki HTTP/2.
• System reputacji IP — ASN-y datacenter są pre-blokowane lub ostro obciążone wagą nieufności.

W 2026 roku Kasada jest jednym z najtrudniejszych systemów anti-bot do przejścia, ponieważ łączy cztery warstwy detekcji: reputację IP, odcisk TLS/HTTP2, behavioral fingerprinting w VM oraz integrity checksums na poziomie bytecode. Każda warstwa musi zostać przebyta poprawnie — jedna anomalia wystarczy, by otrzymać 429.

Skrypt ips.js: 449 KB bytecode VM z tabelą stringów i checksums

Najbardziej charakterystycznym elementem platformy jest skrypt ips.js. Zamiast czytelnego JavaScriptu, Kasada dostarcza około 449 KB danych, które są dekodowane do bytecode'u uruchamianego przez własną maszynę wirtualną. Ta VM nie używa standardowych instrukcji JS — ma własny zestaw opcodes, własną stertę i własne tablice stałych. Tabela stringów jest zaszyfrowana i dekodowana w runtime przy użyciu seedów opartych na czasie, co oznacza, że dwa żądania oddalone o kilka sekund mogą korzystać z innych kluczy deszyfrujących.

Jak działa VM w ips.js

Maszyna wirtualna Kasada implementuje typowe operacje stosowe i rejestrowe, ale z dodatkowymi instrukcjami specyficznymi dla fingerprintingu:

• Odczyt właściwości navigator.webdriver, navigator.languages, navigator.platform.
• Pomiar performance.now() i timingów renderowania canvas.
• Hashowanie wyników i porównanie z oczekiwanymi wartościami integrity.
• Zaszyfrowanie całego ładunku i emisja do nagłówków x-kpsdk-ct i x-kpsdk-cd.

Integrity checksums sprawdzają, czy bytecode nie został zmodyfikowany — jeśli badacz zmieni哪怕 jeden opcode, checksum nie pasuje i VM odmawia wykonania lub emituje błędny token. To sprawia, że statyczna analiza i patchowanie ips.js są niepraktyczne bez pełnego zrozumienia protokołu VM.

Ważna uwaga: ips.js jest rotowany regularnie. Nowe wersje mogą zmieniać opcodes, strukturę tabeli stringów i algorytmy hashujące. Każde rozwiązanie „hardcoded" przestaje działać po kilku tygodniach.

Nagłówki x-kpsdk-ct, x-kpsdk-cd i x-kpsdk-dv: co niosą i jak są weryfikowane

Po wykonaniu challenge'u, VM generuje zaszyfrowany ładunek i umieszcza go w nagłówkach HTTP. Oto co każdy z nich oznacza:

Nagłówek	Funkcja	Rotacja
x-kpsdk-ct	Challenge token — główny wynik VM, weryfikowany po stronie serwera. Jeśli nie pasuje, serwer zwraca 429.	Per-request lub per-session
x-kpsdk-cd	Device data — zaszyfrowany odcisk palca urządzenia (canvas, WebGL, czcionki, timing).	Per-request
x-kpsdk-dv	Dynamic verification — wektor weryfikacji zmieniający się na podstawie seedów czasowych.	Per-request, zależny od czasu

Kiedy serwer Kasada otrzymuje żądanie z niepoprawnym lub wygasłym x-kpsdk-ct, odpowiada statusem 429 Too Many Requests i często dołącza nagłówek x-kpsdk-ct z kodem błędu, który informuje, że token nie przeszedł walidacji. To nie jest rate-limiting w klasycznym sensie — to challenge failure. Oznacza to, że albo VM nie wykonała się poprawnie, albo token był powtórzony (replay), albo odcisk urządzenia nie pasuje do poprzednich żądań.

Dlaczego powtórzenie tokenów nie działa

Kasada wiąże x-kpsdk-ct z:

• Sesją (poprzez KP_UIDz cookie).
• Adresem IP klienta.
• Szczegółami TLS z handshake'u.
• Seedem czasowym.

Token wygenerowany dla jednej kombinacji tych czynników nie przejdzie weryfikacji dla innej. Dlatego „token farming" — generowanie tokenów hurtowo i replay ich w innych sesjach — jest nieskuteczne przeciwko Kasada.

TLS JA3/JA4 i HTTP/2 fingerprinting: detekcja zanim JS się wykona

Zanim skrypt ips.js w ogóle zostanie pobrany, Kasada profiluje połączenie na poziomie TLS i HTTP/2. To jest pierwsza linia obrony i często ostatnia, jeśli Twój klient się nie dostosuje.

JA3 i JA4: odcisk palca TLS

JA3 to hash MD5 z parametrów ClientHello TLS: wersji TLS, listy cipher suites, listy rozszerzeń i typów krzywych eliptycznych. JA4 to nowszy format, który używa SHA-256 i jest bardziej odporny na kolizje. Kasada sprawdza, czy odcisk TLS klienta pasuje do znanych przeglądarek.

Na przykład prawdziwy Chrome 120 na Windows generuje JA3 kończący się na ...e4,00-2b,00-ff-01,00,01 z określoną kolejnością cipher suites. Jeśli Twój klient HTTP (np. requests w Pythonie z domyślnym OpenSSL) wysyła inną kolejność cipher suites — Kasada wie, że to nie jest prawdziwa przeglądarka, zanim w ogóle odpowie na żądanie.

Kluczowe sygnały TLS, które Kasada sprawdza:

• Kolejność cipher suites (Chrome, Firefox i Safari mają różne, przewidywalne kolejności).
• Lista i kolejność rozszerzeń TLS (np. ALPN, supported_versions, key_share).
• Obecność specyficznych rozszerzeń jak padding (Chrome dodaje padding do ClientHello).
• Wersja TLS i krzywe eliptyczne.

HTTP/2 fingerprinting

Poza TLS, Kasada analizuje również ustawienia HTTP/2: SETTINGS frame, WINDOW_UPDATE, PRIORITY frames i kolejność nagłówków (HPACK). Każda przeglądarka ma charakterystyczny wzorzec:

• Chrome wysyła SETTINGS z INITIAL_WINDOW_SIZE = 6291456 i MAX_CONCURRENT_STREAMS = 1000.
• Firefox używa innych wartości i innej kolejności.
• curl i biblioteki HTTP mają zupełnie inne sygnatury, które natychmiast zdradzają automatyzację.

To oznacza, że nawet jeśli skopiujesz wszystkie nagłówki HTTP/1.1 z przeglądarki, Twój klient HTTP/2 może zostać rozpoznany po samym handshake'u protokołu.

Reputacja IP: dlaczego Kasada pre-blokuje ASN-y datacenter

Kasada prowadzi własną bazę reputacji IP, która klasyfikuje adresy według ASN, typu sieci i historycznego zachowania. Datacenter ASN-y — AWS, DigitalOcean, OVH, Hetzner, Linode — są traktowane z maksymalnym poziomem nieufności. W wielu wdrożeniach Kasada blokuje je całkowicie na poziomie WAF, zanim w ogóle dotrą do challenge'u JS.

Proxy datacenter są prawie bezużyteczne przeciwko Kasada z trzech powodów:

1. Pre-blokada ASN: ruch z znanych zakresów hostingowych jest odrzucany na poziomie sieci.
2. Waga reputacji: nawet jeśli adres przejdzie, niski trust score IP powoduje trudniejsze challenge'y i szybsze 429.
3. Korelacja: jeśli wiele żądań przychodzi z tej samej podsieci datacenter, Kasada flaguje całą podsieć.

Proxy rezydencjalne są tu kluczowe, ponieważ adresy IP pochodzą od prawdziwych ISP (np. Comcast, Deutsche Telekom, Orange) i mają naturalny trust score. Kasada nie może pre-blokować całych ASN-ów ISP bez odrzucania prawdziwych użytkowników. To właśnie dlatego sieć rezydencjalna ProxyHat jest tak istotna — oferuje wyjścia z realnych ISP w ponad 150 lokalizacjach.

Praktyczne podejście: ProxyHat + realna przeglądarka dla ips.js

Przyjrzyjmy się teraz, jak legalnie i autoryzowanie przejść challenge Kasada, używając proxy rezydencjalnych ProxyHat w parze z realnym silnikiem przeglądarki. Kluczowa zasada: nie omijaj ips.js — pozwól mu się wykonać naturalnie.

Krok 1: Konfiguracja proxy rezydencjalnego ProxyHat

ProxyHat oferuje bramę HTTP na porcie 8080 i SOCKS5 na porcie 1080. Dla automatyzacji przeglądarkowej SOCKS5 jest często lepszy, bo obsługuje DNS przez proxy i jest kompatybilny z narzędziami jak Puppeteer czy Playwright.

# SOCKS5 ProxyHat — proxy rezydencjalne, USA, sesja sticky
socks5://user-country-US-session-mytask01:pass@gate.proxyhat.com:1080

Flagi w username kontrolują geolokalizację i sesję:

• user-country-US — wyjście przez adres rezydencjalny w USA.
• user-country-DE-city-berlin — precyzyjne targetowanie miasta.
• user-session-mytask01 — sticky session utrzymująca ten sam IP przez życie sesji.

Więcej szczegółów znajdziesz w dokumentacji ProxyHat.

Krok 2: Uruchomienie Playwright z proxy i stealth

const { chromium } = require('playwright');

(async () => {
  const proxyOpts = {
    server: 'socks5://gate.proxyhat.com:1080',
    username: 'user-country-US-session-kasada01',
    password: 'pass'
  };

  const browser = await chromium.launch({
    headless: false,
    args: ['--disable-blink-features=AutomationControlled']
  });

  const context = await browser.newContext({ proxy: proxyOpts });

  // Usuń sygnały webdriver
  await context.addInitScript(() => {
    Object.defineProperty(navigator, 'webdriver', { get: () => undefined });
    // Zachowaj naturalne languages
    Object.defineProperty(navigator, 'languages', {
      get: () => ['en-US', 'en']
    });
  });

  const page = await context.newPage();
  await page.goto('https://strona-chroniona-kasada.example', {
    waitUntil: 'networkidle'
  });

  // Poczekaj na KP_UIDz cookie — oznaka, że ips.js przeszedł
  const cookies = await context.cookies();
  const kpUid = cookies.find(c => c.name === 'KP_UIDz');

  if (kpUid) {
    console.log('Challenge Kasada przeszedł. KP_UIDz:', kpUid.value.substring(0, 20) + '...');
  } else {
    console.log('Challenge nie przeszedł — sprawdź proxy i TLS fingerprint.');
  }

  await browser.close();
})();

Krok 3: Weryfikacja w Pythonie z curl

import subprocess
import json

# Najpierw użyj przeglądarki do zdobycia KP_UIDz i nagłówków x-kpsdk
# Następnie możesz wykonać żądania API używając tego samego proxy i ciasteczek

proxy_url = 'socks5://user-country-US-session-kasada01:pass@gate.proxyhat.com:1080'

cmd = [
    'curl', '-s', '-o', '/dev/null', '-w', '%{http_code}',
    '-x', proxy_url,
    '-H', 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
    '-b', 'KP_UIDz=token_z_przegladarki',
    'https://strona-chroniona.example/api/data'
]

result = subprocess.run(cmd, capture_output=True, text=True)
print(f'Status HTTP: {result.stdout}')

Kluczowe zasady czystego przejścia

• Używaj realnego silnika przeglądarki (Chromium, Firefox) — nie bibliotek HTTP bez JS.
• Ukryj navigator.webdriver i inne sygnały automatyzacji.
• Utrzymuj spójność IP — używaj sticky sessions, aby KP_UIDz nie wygasał przy zmianie IP.
• Nie nadużywaj współbieżności — Kasada wykrywa, gdy 100 żądań przychodzi z tego samego IP w 5 sekund. Utrzymuj max 3-5 równoległych sesji na IP.
• Dopasuj TLS — używaj Chromium, nie curl, dla żądań wymagających przejścia challenge'u.

Typowe błędy i przypadki brzegowe

Błąd 1: Używanie bibliotek HTTP bez JS

Narzędzia jak requests, httpx czy axios nie wykonują JavaScriptu. ips.js nigdy się nie uruchomi, więc KP_UIDz nigdy nie zostanie wygenerowany. Kasada odpowie 403 lub 429. Nie ma obejścia bez realnego silnika JS.

Błąd 2: Replaying tokenów

Nawet jeśli zdobędziesz x-kpsdk-ct z jednej sesji, powtórzenie go w innej sesji lub z innego IP nie zadziała. Token jest związany z IP, sesją i seedem czasowym. Kasada sprawdza spójność tych trzech elementów.

Błąd 3: Zbyt duża współbieżność

Wysyłanie 50 żądań/s z jednego IP rezydencjalnego spowoduje, że Kasada podniesie poziom challenge'u lub zablokuje IP. ProxyHat zaleca utrzymanie rozsądnej współbieżności — zobacz plany ProxyHat, aby dopasować limit sesji do potrzeb.

Błąd 4: Niespójny odcisk TLS

Jeśli używasz proxy SOCKS5 z klientem, który ma inny odcisk TLS niż przeglądarka (np. Python httpx z OpenSSL), Kasada wykryje niespójność. Rozwiązanie: używaj proxy wewnątrz silnika przeglądarki (Playwright/Puppeteer), nie w warstwie HTTP aplikacji.

Błąd 5: Rotacja IP w środku sesji

Jeśli proxy rotuje IP podczas aktywnej sesji, KP_UIDz zostaje unieważniony, bo token był związany z poprzednim IP. Używaj user-session-xxx w ProxyHat, aby utrzymać ten sam IP przez całą sesję.

Kasada bypass w 2026: co działa, a co nie

Termin „kasada bypass" jest nieco mylący — nie chodzi o ominięcie Kasada, ale o przejście jej challenge'u w sposób niewyróżniający się od ruchu organicznego. W 2026 roku skuteczne podejścia to:

Podejście	Skuteczność	Trwałość
Headless browser bez stealth	Niska — navigator.webdriver zdradza automatyzację	Krótkoterminowa
Patchowanie ips.js	Bardzo niska — integrity checksums	Dni, nie tygodnie
Token farming + replay	Zerowa — tokeny związane z IP/sesją/czasem	Nie działa
Real browser + stealth + residential proxy	Wysoka — VM wykonuje się naturalnie	Długoterminowa

Jedynym trwałym podejściem jest pozwolenie ips.js na naturalne wykonanie w realnej przeglądarce, połączonej z rezydencjalnym proxy, który nie wzbudza podejrzeń na poziomie reputacji IP.

Etyczne i prawne aspekty: CFAA, GDPR i autoryzowany dostęp

To rozwiązanie jest przeznaczone wyłącznie do autoryzowanego testowania, badań bezpieczeństwa i monitorowania danych publicznych. Nie używaj go do:

• Skalpingu biletów lub limited-edition produktów wbrew regulaminom platform.
• Tworzenia fałszywych kont lub manipulacji cenami.
• Działalności, która narusza Computer Fraud and Abuse Act (CFAA) w USA lub podobne przepisy w innych jurysdykcjach.

W kontekście RODO/GDPR, jeśli zbierasz dane osobowe z chronionych stron, musisz mieć podstawę prawną i przestrzegać zasad minimalizacji danych. Scraping danych publicznych zazwyczaj nie wymaga zgody, ale przetwarzanie danych osobowych wymaga zgodności z GDPR. W USA, CFAA (18 U.S.C. § 1030) karanizuje „nieautoryzowany dostęp" do systemów komputerowych — autoryzowane testy z zgodą właściciela strony są legalne, ale scraping wbrew regulaminowi może być ryzykowny.

Jeśli wykonujesz legalny web scraping lub śledzenie SERP, upewnij się, że masz uprawnienia lub że dane są publicznie dostępne i nie chronione hasłem.

Kluczowe wnioski (Key Takeaways)

• Kasada to cztery warstwy detekcji: reputacja IP → odcisk TLS/HTTP2 → VM challenge ips.js → weryfikacja nagłówków x-kpsdk. Każda musi zostać przebyta.
• ips.js to 449 KB bytecode VM z integrity checksums i tabelą stringów szyfrowaną seedami czasowymi — statyczne patchowanie jest niepraktyczne.
• Nagłówki x-kpsdk-ct, x-kpsdk-cd, x-kpsdk-dv są związane z IP, sesją i czasem — replay tokenów nie działa.
• Proxy rezydencjalne są obowiązkowe — Kasada pre-blokuje ASN-y datacenter i wazuje reputację IP bardzo wysoko.
• Jedynym trwałym podejściem jest realna przeglądarka + stealth + residential proxy (ProxyHat SOCKS5 :1080), pozwalająca ips.js wykonać się naturalnie.
• Używaj odpowiedzialnie — tylko autoryzowane testy i public-data monitoring, z poszanowaniem CFAA i GDPR.

Jeśli planujesz wdrożenie automatyzacji, która musi przejść przez Kasada, zacznij od planu ProxyHat z odpowiednim limitem sesji rezydencjalnych. Połącz go z Playwright lub Puppeteer w trybie stealth i pozwól ips.js wykonać się naturalnie. To nie jest „bypass" — to czyste przejście challenge'u w sposób niezróżnicowany od ruchu organicznego.