카사다 안티봇 심층 분석: ips.js VM부터 x-kpsdk-ct까지 (2026)

카사다 안티봇(Kasada Anti-Bot)이란? 2026년 관점

카사다(Kasada) 안티봇은 클라이언트 사이드 가상머신 챌린지와 서버 사이드 행동 분석을 결합한 엔터프라이즈급 봇 탐지 플랫폼입니다. 2026년 현재 Akamai Bot Manager, DataDome, Imperva와 함께 최상위 티어 안티봇 솔루션으로 분류되며, 항공사, 티켓팅, 대형 이커머스, 금융 도메인에서 광범위하게 배포되어 있습니다. 카사다 안티봇의 핵심 차별점은 단순한 헤더 검사나 JavaScript 퍼즐을 넘어, 약 449KB 크기의 난독화된 커스텀 바이트코드 가상머신(VM)을 통해 브라우저 환경의 진위를 검증한다는 점입니다.

스크래핑 엔지니어와 안티봇 연구자에게 카사다는 특히 까다로운 대상입니다. User-Agent를 변경하거나 IP를 순환하는 것만으로는 통과할 수 없으며, TLS 지문, HTTP/2 프레임 시그니처, IP 평판, 그리고 JS VM 챌린지가 모두 통합된 다층 방어 체계를 구축하기 때문입니다. 이 글에서는 카사다의 기술 아키텍처를 심층 분석하고, 합법적인 자동화 및 보안 연구 맥락에서 kasada bypass 접근 방식을 어떻게 구현할 수 있는지 실질적으로 다룹니다.

카사다 아키텍처 심층 분석: ips.js 가상머신과 챌린지 흐름

카사다의 방어 체계는 여러 계층으로 구성됩니다. 요청이 들어오면 서버는 먼저 네트워크 계층 신호(TLS 지문, IP 평판)를 평가하고, 통과한 요청에 대해 JavaScript 챌린지를 내립니다. 이 챌린지의 핵심이 바로 ips.js kasada 챌린지 스크립트입니다.

ips.js: 449KB 커스텀 바이트코드 VM

ips.js는 카사다가 배포하는 메인 챌린지 스크립트로, 약 449KB의 난독화된 JavaScript로 구성됩니다. 단순한 난독화가 아니라, 스크립트 내부에 커스텀 바이트코드 인터프리터(VM)를 포함하고 있습니다. 이 VM의 주요 특성은 다음과 같습니다:

• 인코딩된 문자열 테이블: VM 내부의 문자열은 XOR/Base64/커스텀 인코딩으로 보호되어 있어, 정적 분석 시 실제 로직을 파악하기 어렵습니다.
• 시간 기반 시드(time-based seeds): 챌린지 생성 시 서버 타임스탬프와 클라이언트 실행 시간을 기반으로 시드 값을 생성하여, 동일한 챌린지를 재사용하거나 리플레이 공격을 방지합니다.
• 무결성 체크섬(integrity checksums): VM은 자체 코드와 실행 환경의 무결성을 검증합니다. DevTools가 열려 있거나, DOM 프로퍼티가 변조되었거나, 예상치 못한 API 후킹이 감지되면 챌린지 실패로 처리합니다.

이 VM은 브라우저의 다양한 API를 호출하여 디바이스 지문을 수집하고, 수집된 데이터를 암호화하여 서버로 전송합니다. VM 기반 접근의 이점은 분석자가 JavaScript 코드를 읽더라도 실제 로직이 바이트코드로 컴파일되어 있어 역공학이 매우 어렵다는 것입니다.

KP_UIDz 쿠키: 세션 토큰의 핵심

ips.js VM이 챌린지를 성공적으로 완료하면, 서버는 KP_UIDz 쿠키를 발급합니다. 이 쿠키는 카사다가 해당 세션을 '인간으로 검증된' 것으로 식별하는 핵심 토큰입니다. 이후 요청에서 KP_UIDz가 유효하면 챌린지 없이 통과할 수 있지만, 만료되거나 변조되면 다시 챌린지가 트리거됩니다.

KP_UIDz의 수명은 사이트 설정에 따라 다르지만, 일반적으로 30분에서 24시간 사이입니다. 세션 스티키 프록시를 사용하여 동일한 IP에서 KP_UIDz를 발급받고 유지하는 것이 안정적인 자동화의 핵심입니다.

x-kpsdk-ct / x-kpsdk-cd / x-kpsdk-dv 헤더 패밀리

카사다 챌린지가 완료된 후, 클라이언트는 후속 요청에 x-kpsdk-ct, x-kpsdk-cd, x-kpsdk-dv 헤더를 포함합니다. 각 헤더의 역할은 다음과 같습니다:

429 응답에 x-kpsdk-ct 헤더가 포함된 경우, 이는 제출된 토큰이 검증에 실패했음을 의미합니다. 일반적인 원인은 다음과 같습니다:

• 토큰이 만료되었거나 다른 IP에서 생성된 토큰을 재사용한 경우
• VM 실행 환경이 실제 브라우저가 아닌 경우(예: headless 브라우저의 누락된 API)
• 시간 기반 시드가 서버 기준과 너무 많이 어긋난 경우

브라우저 지문 수집과 암호화된 페이로드 생성

ips.js VM이 실행되면, 다음과 같은 브라우저 및 디바이스 신호를 수집합니다. 이 과정은 Mozilla의 브라우저 지문 문서에서 설명하는 일반적인 지문 기법을 훨씬 넘어서는 정밀도로 이루어집니다.

수집되는 주요 지문 신호

• Canvas 지문: WebGL 렌더링 결과의 픽셀 데이터를 해시화. GPU 모델, 드라이버, 안티앨리어싱 설정에 따라 고유한 값 생성.
• AudioContext 지문: Web Audio API의 오실레이터 출력을 분석하여 오디오 하드웨어 지문 생성.
• Navigator 프로퍼티: userAgent, platform, hardwareConcurrency, deviceMemory, languages, plugins. 단일 프로퍼티가 아닌 프로퍼티 간 일관성을 교차 검증.
• 화면 메트릭: screen.width, screen.height, colorDepth, pixelDepth, devicePixelRatio. 창 크기와 화면 해상도의 관계 검증.
• WebGL 파라미터: GPU 벤더 문자열(VENDOR/RENDERER), 확장 기능 목록, 셰이더 정밀도 포맷.
• 행동 신호: 마우스 이동 궤도, 키보드 입력 타이밍, 스크롤 패턴. VM은 챌린지 해결 과정에서 이벤트를 수집하여 기계적 입력과 인간 입력을 구분.

수집된 지문 데이터는 VM 내부에서 암호화되어 회전하는 페이로드(rotating payloads)로 생성됩니다. 매 요청마다 페이로드 구조와 암호화 키가 변경되므로, 정해진 페이로드를 재사용하는 것은 불가능합니다. 이것이 단순히 x-kpsdk-ct 헤더를 캡처하여 재사용하는 kasada bypass 시도가 실패하는 근본적인 이유입니다.

TLS(JA3/JA4) 및 HTTP/2 지문과 IP 평판

카사다는 JavaScript 챌린지 이전에 이미 네트워크 계층에서 강력한 사전 필터링을 수행합니다. 이 단계에서 걸러진 요청은 챌린지조차 받지 못하고 차단됩니다.

JA3/JA4 TLS 지문

JA3는 TLS ClientHello 메시지의 특정 필드(버전, 암호화 스위트 목록, 확장 기능, 타원 곡선, 타원 곡선 포인트 포맷)를 해시화한 값입니다. TLS 지문에 대한 Wikipedia 문서에 설명된 대로, 각 브라우저와 HTTP 클라이언트는 고유한 JA3/JA4 해시를 생성합니다.

카사다는 알려진 자동화 도구의 JA3 해시를 데이터베이스로 관리합니다. 예를 들어:

• Python requests 라이브러리는 OpenSSL 기반의 일관된 JA3 해시를 생성하여 즉시 식별 가능.
• Node.js axios / node-fetch 역시 고유한 JA3 패턴을 가짐.
• 실제 Chrome 브라우저는 Chrome 버전별로 특정 암호화 스위트 순서를 사용하며, 이 순서가 다르면 의심으로 분류.

JA4는 JA3의 개선된 버전으로, 더 세분화된 필드를 사용하고 포맷이 더 구조화되어 있습니다. 2026년 기준, 주요 안티봇 벤더들이 JA4를 적극적으로 채택하고 있습니다.

HTTP/2 프레임 지문

카사다는 RFC 7540에 정의된 HTTP/2 프로토콜의 프레임 순서와 설정값도 지문화합니다. 클라이언트가 전송하는 SETTINGS 프레임의 파라미터(HEADER_TABLE_SIZE, INITIAL_WINDOW_SIZE, MAX_CONCURRENT_STREAMS 등)와 프레임 순서는 클라이언트 구현마다 다릅니다. Python httpx와 Chrome의 HTTP/2 설정값이 다르면, TLS 지문이 정상이어도 이 단계에서 탐지됩니다.

IP 평판과 ASN 사전 차단

카사다는 요청 IP의 ASN(Autonomous System Number)을 기반으로 신뢰도 점수를 부여합니다. 데이터센터 ASN(AWS, Google Cloud, Azure, DigitalOcean, OVH 등)에서 오는 요청은 기본 신뢰도가 매우 낮으며, 많은 경우 JavaScript 챌린지 이전에 이미 차단됩니다. 이는 kasada bypass 시도에서 데이터센터 프록시가 거의 항상 실패하는 핵심 이유입니다.

IP 평판 시스템은 다음 요소를 종합적으로 평가합니다:

• ASN 유형: ISP(레지덴셜) vs 데이터센터 vs 모바일 통신사
• IP 이력: 해당 IP에서 과거 봇 활동이 감지되었는지
• 지리적 일관성: IP 지리적 위치와 브라우저 timezone/locale이 일치하는지
• IP 회전 빈도: 짧은 시간 내 동일 세션이 여러 IP에서 오는 경우

레지덴셜 프록시가 필수인 이유

카사다의 IP 평판 시스템에서 데이터센터 IP는 사실상 '사형 선고'입니다. AWS us-east-1 IP 대역에서 오는 요청이 항공사 웹사이트에 접근하면, 카사다는 챌린지를 내리기 전에 403 또는 챌린지 루프로 직행시킵니다.

레지덴셜 프록시는 실제 ISP에서 할당받은 IP 주소를 사용하므로, 카사다의 ASN 필터를 자연스럽게 통과합니다. Comcast, AT&T, Verizon, Deutsche Telekom 등의 IP 대역은 일반 사용자 트래픽으로 분류되어 신뢰도 점수가 높습니다.

모바일 프록시는 레지덴셜보다 신뢰도가 더 높지만, 대역폭 비용이 상대적으로 높고 속도가 느릴 수 있습니다. 대부분의 kasada bypass 시나리오에서 레지덴셜 프록시가 비용과 성능의 최적 균형점입니다. ProxyHat의 레지덴셜 프록시 풀은 전 세계 195개 이상의 국가를 커버하며, 도시 단위 지역 타겟팅을 지원합니다.

ProxyHat 레지덴셜 프록시와 실제 브라우저 연동

카사다 안티봇을 통과하는 핵심 원칙은 간단합니다: 실제 브라우저 런타임에서 ips.js를 실행시키고, 레지덴셜 IP를 통해 요청을 보낸다. 이를 통해 VM이 정상적으로 실행되어 유효한 KP_UIDz를 발급받고, x-kpsdk-ct 헤더가 자연스럽게 생성됩니다.

SOCKS5 프록시 설정 (Python + Playwright)

다음 예제는 ProxyHat 레지덴셜 프록시를 SOCKS5로 설정하고 Playwright를 통해 실제 Chromium 브라우저를 구동하는 방법을 보여줍니다. 세션 스티키 모드를 사용하여 KP_UIDz 발급 후 동일한 IP를 유지합니다.

from playwright.sync_api import sync_playwright

PROXY = {
    'server': 'socks5://gate.proxyhat.com:1080',
    'username': 'user-session-kasada01-country-US',
    'password': 'YOUR_PASSWORD'
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # 디버깅 시 False, 프로덕션에서는 stealth 모드 적용
        proxy=PROXY,
        args=['--disable-blink-features=AutomationControlled']
    )
    context = browser.new_context(
        viewport={'width': 1920, 'height': 1080},
        locale='en-US',
        timezone_id='America/New_York'
    )
    page = context.new_page()

    # 카사다 보호 사이트 접속
    page.goto('https://target-site.com', wait_until='networkidle')

    # ips.js 챌린지 자동 해결 대기
    # VM이 실행되어 KP_UIDz 쿠키 발급을 기다림
    page.wait_for_cookie('KP_UIDz', timeout=30000)

    # 이후 페이지에서 데이터 추출
    content = page.content()
    print(content[:500])

    browser.close()

위 코드에서 user-session-kasada01-country-US 사용자명은 미국 레지덴셜 IP를 고정 세션으로 할당합니다. KP_UIDz 쿠키가 발급되면, 동일한 세션 ID를 사용하는 한 동일한 IP가 유지되어 쿠키가 유효합니다.

curl을 통한 빠른 연결 테스트

프록시 연결과 IP 신뢰도를 빠르게 검증하려면 curl로 테스트합니다:

# HTTP 프록시로 IP 확인
curl -x http://user-country-US:pass@gate.proxyhat.com:8080 \
  https://httpbin.org/ip

# SOCKS5 프록시로 IP 확인
curl -x socks5://user-country-US:pass@gate.proxyhat.com:1080 \
  https://httpbin.org/ip

반환된 IP가 데이터센터가 아닌 ISP IP인지 확인하려면, IP 정보 서비스에서 ASN을 조회해 봅니다. AS7922(Comcast)나 AS7018(AT&T) 같은 ISP ASN이 표시되어야 합니다.

세션 관리 전략

KP_UIDz 쿠키가 발급된 후에는 세션을 효율적으로 관리하는 것이 중요합니다:

1. 세션 스티키 모드 사용: user-session-{고유ID} 형식으로 동일한 IP를 유지. KP_UIDz 만료 전까지 재사용.
2. 쿠키 저장 및 재사용: Playwright의 context.storage_state()를 사용하여 쿠키를 저장하고, 후속 실행에서 로드.
3. 적절한 요청 간격: 인간 탐색 패턴을 모방. 페이지 간 2-5초 대기, 급격한 다중 요청 방지.
4. 지역 일관성 유지: 미국 IP를 사용하면 timezone을 America/New_York로, locale을 en-US로 설정. 일본 IP에 en-US locale을 사용하면 지리적 불일치로 탐지됨.

ProxyHat의 세션 스티키 모드는 최대 30분까지 동일한 IP를 유지할 수 있으며, 필요에 따라 더 긴 세션도 설정 가능합니다. 자세한 가격 정보는 프록시 가격 페이지를 참조하세요.

흔한 실수와 엣지 케이스

1. Headless 브라우저의 누락된 API

Headless Chrome은 일부 브라우저 API가 누락되어 있거나 다르게 동작합니다. 예를 들어 navigator.webdriver가 true로 설정되거나, window.chrome 객체가 누락될 수 있습니다. 카사다 VM은 이러한 신호를 적극적으로 검사합니다. 해결책:

• Playwright의 stealth 플러그인 사용 또는 수동으로 navigator.webdriver 삭제
• --disable-blink-features=AutomationControlled 플래그 추가
• Headed 모드(headless=False) 사용 — Xvfb와 함께 가상 디스플레이에서 실행

2. IP-지역 불일치

독일 IP를 사용하면서 브라우저 timezone을 America/Los_Angeles로 설정하면, 카사다는 즉시 탐지합니다. 항상 프록시 IP의 국가와 일치하는 timezone, locale, Accept-Language 헤더를 설정하세요.

3. 과도한 동시 요청

동일한 KP_UIDz로 100개 이상의 동시 요청을 보내면 행동 분석 엔진이 봇으로 판단합니다. 인간 사용자는 한 번에 하나의 페이지를 로드합니다. 동시성을 3-5개로 제한하고, 요청 간 적절한 지연을 두세요.

4. 만료된 KP_UIDz 재사용

세션 쿠키가 만료된 후에도 계속 사용하면 429 응답이 반환됩니다. x-kpsdk-ct 헤더의 실패 코드를 모니터링하고, 429가 발생하면 즉시 새 세션으로 챌린지를 재실행해야 합니다.

5. TLS 지문 불일치

실제 브라우저를 사용하면 TLS 지문은 자연스럽게 일치합니다. 하지만 Python requests나 httpx로 쿠키를 재사용하여 직접 요청을 보내면, 브라우저의 JA3/JA4 해시와 Python의 해시가 달라 탐지됩니다. 쿠키 기반 직접 요청은 피하고, 항상 브라우저 런타임 내에서 요청을 수행하세요.

적절한 사용과 법적 고려사항

이 기술 정보는 합법적인 보안 연구, 인가된 침투 테스트, 공개 데이터 모니터링 목적으로만 사용해야 합니다. 카사다가 보호하는 사이트의 서비스 약관(ToS)을 준수하고, robots.txt를 존중하며, 대상 시스템에 부하를 가하지 않는 것이 필수적입니다.

미국 컴퓨터 사기 및 남용법(CFAA)은 승인 없는 시스템 접근을 금지하며, EU의 GDPR은 개인 데이터 수집 시 명시적 동의를 요구합니다. 웹 스크래핑의 합법성은 관할권, 데이터 유형, 접근 방식에 따라 다르므로, 프로덕션 환경에서는 반드시 법무팀의 검토를 받아야 합니다.

ProxyHat은 스크래핑 합법성에 대한 법률 자문을 제공하지 않습니다. 모든 사용자는 자신의 사용 사례가 해당 관할권의 법률을 준수하는지 독자적으로 확인해야 합니다. 자세한 사용 사례는 웹 스크래핑 사용 사례와 SERP 추적 사용 사례를 참조하세요.

핵심 요약 (Key Takeaways)

카사다 안티봇은 ips.js VM(449KB), TLS/JA3 지문, HTTP/2 프레임 분석, IP 평판을 결합한 다층 방어 체계입니다. kasada bypass의 핵심은 실제 브라우저 런타임 + 레지덴셜 프록시 조합으로, VM이 정상 실행되어 유효한 KP_UIDz와 x-kpsdk-ct 토큰을 자연스럽게 발급받는 것입니다.

• ips.js VM은 커스텀 바이트코드 인터프리터로, 시간 기반 시드와 무결성 체크섬을 사용하여 리플레이 및 정적 분석을 방어합니다.
• x-kpsdk-ct 헤더가 429와 함께 반환되면 토큰 검증 실패를 의미합니다. 새 세션에서 챌린지를 재실행해야 합니다.
• 데이터센터 IP는 사전 차단됩니다. 레지덴셜 프록시(또는 모바일 프록시)만이 카사다 IP 평판을 통과할 수 있습니다.
• 실제 브라우저 런타임 사용이 필수입니다. Python requests/httpx로 쿠키를 재사용하면 TLS 지문 불일치로 탐지됩니다.
• 지역 일관성을 유지하세요. IP 국가, timezone, locale, Accept-Language 헤더가 모두 일치해야 합니다.
• 합법적 목적(보안 연구, 인가된 테스트, 공개 데이터 모니터링)으로만 사용하고, CFAA/GDPR을 준수하세요.

ProxyHat 레지덴셜 프록시로 시작하려면 가격 페이지에서 플랜을 확인하거나, ProxyHat 문서에서 설정 가이드를 참조하세요.