M2 Bot Identification & Scoring — 프로토타입

TLS 지문은 클라이언트가 서버에 보내는 ClientHello 메시지의 필드(TLS 버전, 암호화 스위트 순서, 확장 목록, 타원 곡선)를 해시한 값이다. HTTP 레이어가 아니라 TLS 핸드셰이크 레이어에서 결정되므로 User-Agent를 바꿔도 우회되지 않는다.

문제는 이 값이 raw ClientHello 바이트를 TLS 협상이 끝나기 전에 캡처해야 나온다는 점이다. Node.js의 http/https 모듈은 이미 협상이 끝난 소켓만 애플리케이션 코드에 넘겨주므로, 이 프로토타입처럼 앱 서버 레벨에서 동작하는 한 JA3를 관찰할 방법이 없다. 실제로 이걸 관찰하려면 nginx/Envoy/CDN Edge처럼 TLS를 직접 종단하는 레이어가 필요하다 — 원본 리서치 문서가 "TLS/HTTP fingerprint"를 별도 섹션으로 다루는 이유이자, M2가 이 기능을 앱이 아니라 Edge/Proxy에 둬야 하는 이유다.

Edge/Proxy 레이어 구현 옵션 비교

"어디서" 캡처할지는 후보가 여러 개이고, 난이도 차이가 크다. 목적을 "요청 단위로 앱이 읽을 수 있는 HTTP 헤더로 만든다"로 고정하면 비교가 명확해진다.

Go로 구현할 때도 정밀도 2단계

실무 권장 순서: 근사치(표준 라이브러리)로 먼저 신호를 채우고, 공개 JA3 블랙리스트 대조가 실제로 필요해지는 시점에 raw 파싱으로 업그레이드한다.

우회 현실 — JA3는 어렵지 않게 흉내낼 수 있다

JA3를 결정 신호로 쓰면 안 되는 실질적인 이유는, 흉내내는 두 경로가 이미 진입장벽이 낮기 때문이다.

그래서 Akamai/Cloudflare 같은 상용 솔루션도 JA3 단독이 아니라 JA3 + HTTP/2 지문을 같이 본다 — TLS만 흉내낸 라이브러리가 HTTP/2 레이어까지 브라우저와 완전히 똑같이 동작하게 만들기는 훨씬 어렵기 때문이다. "진짜 브라우저 자동화"는 반대로 TLS/HTTP2는 완벽히 통과하지만 JS 레이어(webdriver, WebGL, 행동 패턴)에서 걸린다. 결론적으로 어느 한 카테고리도 단독으로는 못 막고, 여러 카테고리를 합산하는 이 프로토타입의 스코어링 구조가 맞는 방향이다. 원본 문서 2장의 "Advanced Evasion Pressure" 섹션과 같은 결론이다.

puppeteer-extra-plugin-stealth 같은 도구는 navigator.webdriver를 숨기고 일부 속성을 패치할 수 있지만, WebGL이 실제로 소프트웨어 렌더러를 쓰고 있다는 사실 자체는 GPU가 없는 한 바꿀 수 없다. 그래서 이 프로토타입은 여러 지표를 동시에 봐서 하나를 속여도 다른 지표에서 걸리게 설계했다.

쿠키 하나만 ID로 쓰면, 봇 운영자가 차단당할 때마다 쿠키(또는 프로필)를 새로 만들어 우회할 수 있다. 원본 문서 9장(Long-Term Cluster)의 핵심도 "IP/쿠키 단위가 아니라 fingerprint cluster 단위로 정책을 적용하라"는 것이다.

이 프로토타입에서는 메모리 Map으로 구현했지만, 실제 서비스에서는 Redis 등 TTL이 있는 저장소가 필요하다.

Googlebot/Bingbot 같은 "알려진 좋은 봇"은 User-Agent가 아니라 네트워크 신원으로 검증해야 한다. UA 문자열은 누구나 복사할 수 있기 때문이다. Google/Bing이 공식적으로 권장하는 방법은 다음과 같다.

1번만 확인하면 위조된 hostname을 스스로 등록한 공격자에게 속을 수 있어 4번 정방향 재검증이 필수다. Akamai/Cloudflare도 이런 검증을 거친 크롤러만 IP 화이트리스트에 등록해 "Verified Bot"으로 분류하고 TLS/JS 검사를 생략시킨다.

지금까지 다룬 IP평판/TLS/HTTP/브라우저지문/쿠키 5개 카테고리 외에 Akamai Bot Manager 같은 상용 솔루션이 구조적으로 더 갖는 것들이 있다.

그래서 막을 수 있는가

하위~중급 자동화는 막힌다. 단순 스크립트, curl/requests 기반 스크레이퍼, 세션 관리 없는 크리덴셜 스터핑 — 지금 프로토타입 수준의 다중 카테고리 합산 스코어링으로도 충분히 걸러진다. 원본 문서가 처음부터 "완벽한 식별"이 아니라 "저품질 자동화를 낮은 비용으로 거른다"를 목표로 잡은 이유다.

고급/타겟형 자동화는 막히지 않는다. 실제 Chrome + stealth plugin + residential proxy + 사람처럼 짠 행동 스크립트 조합이면, 알고리즘을 아무리 정교하게 짜도 단일 조직 구현으로는 못 막는다. 여기서 진짜 격차는 "알고리즘이 더 똑똑해서"가 아니라 위 표의 크로스 고객사 데이터 — 순수한 관측 규모의 문제다. 그래서 목표를 "차단"이 아니라 "이 타겟을 공격할 가치가 없을 만큼 운영 비용을 올린다"로 잡는 게 현실적이다.

Akamai가 공식 스펙을 공개하지 않아 아래 내용은 보안 리서치 커뮤니티가 리버스엔지니어링으로 관찰·정리한 내용이다. 정확한 암호화 알고리즘·포맷은 Akamai가 주기적으로 바꾸므로 시점에 따라 달라질 수 있다.

전체 흐름

쿠키 값 구조 (커뮤니티 관찰 기준, 비공식)

값 자체는 사람이 읽을 수 없는 불투명한 토큰이지만, 커뮤니티 리서치에서는 ~로 구분된 여러 세그먼트(세션 식별자 성격의 해시, 타임스탬프, 상태 플래그)로 구성되고, 마지막 세그먼트(예: ~-1~, ~0~, ~1~)가 "이 세션이 봇으로 플래그됐는지"를 유추하는 경험적 신호로 관찰돼왔다. Akamai가 공식 문서화한 스펙이 아니므로 언제든 바뀔 수 있다는 점을 감안해야 한다.

왜 단순 쿠키 위조로 안 뚫리는가

• 클라이언트는 암호화 키가 없어 값을 직접 조작할 수 없음
• 리플레이 방지: 이전 유효 토큰/sensor_data를 재사용해도 시간이 지나면 키·포맷이 바뀌어 무효화되거나 서버가 중복 패턴을 탐지
• 센서 스크립트 자체에 안티디버깅/안티변조 체크가 있어 devtools가 열려있거나 스크립트가 수정된 걸 감지하면 동작을 바꾸거나 플래그를 남김

이 프로토타입과의 실질적 차이

우리 Session ID(bm_sid)는 서버가 발급하지만 평문 UUID라 클라이언트가 값을 볼 수 있고(그래도 위조는 못 함, 서버 발급 값이므로), 무엇보다 한 번의 스냅샷이다. _abck는 (1) 클라이언트가 절대 못 읽는 암호화된 내용이고 (2) 세션 내내 계속 갱신되는 연속 관찰이라는 두 가지가 다르다.

KV DB(Redis 등) 도입은 "인메모리 → 영속/공유" 격차만 메운다 — 클라이언트가 {mousemove: 100}처럼 자기신고 값을 그냥 지어내 보내는 스푸핑 문제는 저장소를 바꿔도 그대로 남는다. (1)을 흉내내려면 서버가 독립적으로 검증 가능한 신호(IP/헤더/TLS)의 가중치를 자기신고 행동 신호보다 높게 유지하는 절충이 필요하고, (2)를 흉내내려면 클라이언트가 페이지 로드 시 1회가 아니라 주기적으로(예: 스크롤/클릭 이벤트마다, 또는 15초 간격) 다시 POST하도록 바꿔서 KV DB에 누적해야 한다.

봇 판정 시스템에서 가장 치명적인 버그는 "탐지를 못 하는 것"보다 공격자가 제어하는 입력을 신뢰해서 판정을 통째로 우회당하는 것이다. 이 프로토타입도 코드 리뷰에서 이런 우회 구멍이 발견돼 아래처럼 막았다. 각 신호가 "누가 값을 정하는가"를 기준으로 신뢰 등급을 나누는 게 핵심이다.

신호별 신뢰 등급

구멍 1 — X-Forwarded-For 무검증 신뢰

X-Forwarded-For는 클라이언트가 임의로 넣을 수 있는 헤더다. 이 값을 클라이언트 IP로 그대로 쓰면 두 가지 우회가 동시에 열린다.

방어: 클라이언트 IP의 진실은 위조 불가능한 소켓 peer(req.socket.remoteAddress)뿐이다. XFF는 기본적으로 무시하고, 실제 신뢰 가능한 프록시 뒤에 배포할 때만 TRUST_XFF=1 환경변수로 활성화한다. 이때도 프록시가 XFF를 덮어써야(append가 아니라 replace) 클라이언트가 앞에 위조 값을 끼워넣는 걸 막을 수 있다.

구멍 2 — testIp 데모 파라미터의 verdict 우회

로컬에서 크롤러 검증을 시연하려고 연 ?testIp= 오버라이드가, 아무 가드가 없으면 원격 스크레이퍼가 ?testIp=<크롤러IP>만 붙여 Allow를 얻는 통로가 된다.

방어: testIp는 실제 소켓 peer가 로컬/사설망일 때(=개발자 본인)만 적용한다(XFF가 아니라 소켓 peer로 판정). 응답의 request.testIpApplied로 적용 여부가 노출되고, UI에도 "testIp 오버라이드(로컬 데모)" 배지가 표시된다. 운영에서는 파라미터 자체를 제거하는 게 안전하다.

구멍 3 — 대시보드 XSS (공격자 UA가 화면에서 실행)

이 도구는 적대적 트래픽을 들여다보는 화면이다. 봇이 User-Agent나 WebGL renderer 값에 <img src=x onerror=...> 같은 페이로드를 넣고, 운영자가 그 세션을 대시보드에서 열면 운영자 브라우저에서 스크립트가 실행된다. 관측 대상의 값이 곧 공격 벡터가 되는 구조다.

방어: 서버가 돌려준 모든 클라이언트/외부 유래 문자열을 innerHTML에 넣기 전에 HTML 이스케이프(esc())한다. Session/Cluster ID처럼 서버가 생성한 값은 textContent로 출력한다.

구멍 4 — 자기신고 값에 대한 과신

POST 바디의 행동 카운트(mousemove 등)나 navigator 값은 봇이 얼마든지 지어낼 수 있다. 그래서 서버가 독립적으로 검증 가능한 신호(소켓 IP, 헤더 존재/순서, DNS)의 가중치를 자기신고 신호보다 구조적으로 높게 둬야 한다. 이 프로토타입도 webdriver/WebGL 같은 자기신고 신호 하나만으로 차단하지 않고 여러 카테고리를 합산하는 이유가 여기 있다.

부수적 하드닝

• 요청 바디 1MB 초과 시 스트림을 계속 받지 않고 413 Payload Too Large 반환 — 메모리 고갈 방지.
• 지문 신호가 하나도 없는 요청(빈 바디)은 Cluster ID를 null로 두어, 신호 없는 클라이언트끼리 한 클러스터로 뭉쳐 "reset 패턴" 오탐이 나는 것을 방지.

실제 Playwright(Chromium 149)로 이 배포 페이지에 4가지 상태로 접속해, 페이지가 서버로 보낸 판정을 취합했다. 동일 IP(residential, Korea Telecom)·동일 세션 격리 조건. 재현 스크립트는 저장소의 test/compare-probe.mjs.

결과 요약

신호별 발화 매트릭스

IP/ASN·HTTP·TLS는 4개 모드 공통 0점(residential IP, 정상 헤더, TLS 미관찰)이라 생략.

실측된 headless WebGL renderer 값: ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (LLVM 10.0.0) ...), SwiftShader driver) — GPU 없는 headless의 소프트웨어 렌더러가 그대로 노출됐다.

핵심 발견

• 순수 headless는 확실히 잡힌다(90). webdriver + software GPU + window.chrome 부재 + 행동 부재가 겹쳐 challenge 구간.
• 행동 하나 위조로 −20(70). 마우스/스크롤/키 입력만 넣어도 "행동 부재"가 사라진다 — 행동 신호를 단독 근거로 쓰면 안 되는 이유.
• ⚠️ 실제 창(headful)은 webdriver 하나만 남아 30점 = Allow로 통과. 실제 Chrome 자동화는 GPU·plugins·window.chrome이 전부 정상이라, 남는 navigator.webdriver(+30)만으로는 allow 경계(≤30)를 못 넘는다. 실제 브라우저 자동화 + 약간의 상호작용이면 현재 스코어링을 통과한다.
• stealth는 0점 — 완전 통과. JS 레이어를 위장하면, 이 앱은 TLS/HTTP2를 관찰하지 않고 IP도 깨끗한 residential이라 남는 신호가 없다.

TLS/JA3 프록시(:8443)에서 다시 측정하면?

TLS ClientHello를 직접 종단해 JA3를 관찰하는 별도 엔드포인트(m2-tls-ja3-proxy, :8443)로 같은 실험을 반복한 결과. 실제 방문자 IP(residential) 조건.

핵심: JA3는 UA만 Chrome으로 위조한 비브라우저 클라이언트(curl/Go/Python)를 +25로 적발한다 — JS를 아예 안 돌려 JS 레이어로는 못 잡던 사각지대를 덮는다. 하지만 stealth headless는 :8443에서도 그냥 통과(20점, Allow)한다. 진짜 Chromium이라 TLS도 진짜 Chrome(GREASE 있음) → JA3 +0, JS 신호는 stealth가 전부 가림. 즉 JA3는 JS 레이어를 보완할 뿐, 진짜 브라우저 자동화를 잡지는 못한다.

참고: stealth 세션을 같은 지문으로 연속 접속하면 남는 20점이 Behavior가 아니라 Cookie Continuity(반복 세션 재발급)로 잡히기도 한다 — stealth가 못 가리는 건 지문이 아니라 "반복 운영 흔적"이지만, 그마저도 Allow 구간(≤30)이다.

이것이 말해주는 것

이 실험은 "JS 레이어 신호만으로는 고급 자동화를 못 막는다"는 결론을 숫자로 확인해준다(headful 30·stealth 0이 통과, JA3 추가해도 stealth headless는 20으로 통과). 실제 브라우저 자동화를 잡으려면 이 프로토타입이 관찰하지 않는 신호 — HTTP/2 프레임 지문, 장기 행동 궤적, 크로스 세션·크로스 고객사 클러스터, _abck식 암호화 연속 관찰 — 이 필요하며, 이는 알고리즘 정교함이 아니라 관측 레이어·규모의 문제다. (위 "Akamai급 격차" 섹션 참조.)

아래 순서대로 해보면 Identification과 Scoring 로직이 실제로 반응하는 걸 눈으로 확인할 수 있다.

curl 예시

가중치 상세 표는 docs/bot-identification-scoring-model.md에 있다. 값은 코드(server.js의 scoreRequest)와 항상 동기화되어야 한다.