사이트 감지 카드 제거 방법: 핑거프린트 스크립트 감사

```html

2026년 8월 20일, 개발자 맷 칼라간(블로그 laserphile)은 이상한 버그에 대한 분석을 발표했습니다: 그의 멀티포인트 블루투스 헤드폰이 컴퓨터에서 전화로 전환되지 않았습니다. 매번 AliExpress 탭이 열릴 때마다 발생했습니다. 그는 추측하지 않고 브라우저 API를 도구화하여 페이지 내부에서 무슨 일이 일어나고 있는지 살펴보았습니다. 결과적으로, 알리바바의 안티-사기 스택에서 두 개의 난독화된 스크립트가 오디오 컨텍스트를 통해 장치의 지문을 소리로 캡처하고 있음을 발견했습니다. 아무도 듣지 못하는 소리로 말이죠.

이것은 프로필 설정이나 파서 실행 전에 거의 아무도 하지 않는 일의 완벽한 예시입니다: 사이트의 감지 스택을 읽지 않고 추측한다는 것입니다. 아래는 특정 사이트의 감지 맵을 직접 만드는 실용적인 방법으로, 한 시간 안에, 난독화 리버스 없이, 유료 서비스 없이 가능합니다.

감지 맵을 만드는 이유

전형적인 사이클은 다음과 같습니다: 계정이 차단된다 — 안티-감지 브라우저의 설정을 무작위로 조정한다 — 프록시를 변경한다 — 다시 차단된다. "차단된다"와 "설정" 사이에는 데이터가 없습니다: 사이트가 정확히 무엇을 읽고 어떤 레이어에서 감지하는지 알 수 없습니다.

감지 맵은 이 간극을 메워줍니다. 이는 어떤 보호 공급자가 있는지, 어떤 스크립트가 이를 구현하는지, 어떤 API를 건드리는지, 결과가 어디로 가는지를 나열한 목록입니다. 이후에는 실제로 좁은 지점이 어디인지 — IP, 네트워크 지문 또는 브라우저의 하드웨어 레이어인지 — 알 수 있습니다. 이는 세 가지 청중에게 모두 유용합니다:

멀티 계정 관리 — 프로필이 어떤 신호로 결합되는지 이해합니다. IP는 다르지만 오디오 스택, WebGL 렌더러 및 hardwareConcurrency는 종종 전체 농장에서 동일합니다.
스크래핑 — 브라우저를 실행할 가치가 있는지, 아니면 올바른 TLS 지문을 가진 HTTP 클라이언트로 문제를 해결할 수 있는지를 이해합니다.
프라이버시 — 상점이나 서비스가 쿠키 외에 귀하의 장치에 대해 무엇을 수집하는지 확인합니다.

1단계. 네트워크를 통해 보호 공급자 식별하기

첫 번째로 하는 일은 DevTools를 열고 네트워크 탭에서 페이지를 로드한 후 첫 번째 문서의 헤더와 쿠키를 확인하는 것입니다. 식별자는 알려져 있고 안정적입니다:

CF-RAY 응답 헤더와 쿠키 cf_clearance — Cloudflare.
쿠키 _abck 및 bmak 기능을 가진 스크립트 — Akamai Bot Manager.
_px 접두사가 붙은 변수 및 쿠키 — PerimeterX (HUMAN).
쿠키 datadome 및 공급자 도메인에서 온 별도의 JS — DataDome.
본문이 없는 빈 429 — Kasada의 전형적인 서명입니다.

손으로 하기 귀찮다면, microlinkhq/is-antibot와 같은 공개 감지기(30개 이상의 공급자)와 26개 이상의 공급자를 위한 브라우저 확장 감지기가 있습니다. 이들은 빠른 첫 번째 답변을 제공하지만, 귀하의 브라우저에서 정확히 무엇이 측정되는지는 답하지 않습니다. 이를 위해서는 더 나아가야 합니다.

2단계. 의심스러운 스크립트 목록 추출하기

네트워크를 JS 유형으로 필터링하고 기본 도메인에서 로드되지 않거나 서비스 디렉토리에 있는 모든 것을 기록합니다. AliExpress 사례에서는 명백한 서비스 경로를 가진 두 개의 파일이 있었습니다:

assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

안티-사기 스크립트의 징후: 난독화된 코드, 경로에 버전, 정적 파일을 위한 별도의 서브도메인, 페이지의 시각적 부분과의 연결 부족. 난독화를 열고 읽을 필요는 없습니다 — 다음 단계에서 스크립트가 스스로에 대해 이야기할 것입니다.

3단계. 지문 API 도구화하기

이것이 방법의 핵심이며 칼라간이 한 일입니다: 그는 AudioContext 생성자와 AudioNode.prototype.connect()를 감싸고, 그 후 미디어 요소나 play() 호출 없이 페이지에서 두 개의 활성 오디오 컨텍스트를 보았습니다.

논리는 간단합니다: 관심 있는 메소드를 자신의 래퍼로 대체하여 호출 스택과 함께 로그를 기록하고 원본으로 제어를 전달합니다. 호출 스택은 어떤 스크립트가 API를 호출했는지를 보여줍니다. 이러한 스니펫을 삽입하는 가장 편리한 방법은 DevTools 소스 → 스니펫을 통해 하거나, document-start에서 코드를 실행하는 확장을 통해 하여 안티-사기 스크립트가 로드되기 전에 해야 합니다.

대부분의 신호를 차단하는 최소한의 트랩 세트:

HTMLCanvasElement.prototype.toDataURL 및 getImageData — 캔버스 지문.
WebGLRenderingContext.prototype.getParameter — 그래픽 카드 및 드라이버 모델, 셰이더 정확도.
AudioContext / OfflineAudioContext 및 AudioNode.prototype.connect — 오디오 지문.
게터 navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
RTCPeerConnection — WebRTC 및 로컬 주소.
screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — 화면 및 시간대.
navigator.mediaDevices.enumerateDevices — 오디오 및 비디오 장치 목록.

이 프로세스를 통해 어떤 API가 호출되었는지, 몇 번 호출되었는지, 누가 호출했는지에 대한 목록이 생깁니다. 분석된 사례에서 Alibaba의 스크립트는 캔버스와 toDataURL, WebGL 렌더러와 셰이더 정확도, 오디오를 통해 오실레이터와 분석기, 화면 크기와 devicePixelRatio, hardwareConcurrency 및 deviceMemory, 플러그인, 코덱 지원, WebRTC, 성능 타이밍, 마우스 및 터치 패턴, 장치의 움직임 센서 및 자동화 지표 속성을 건드렸습니다.

오디오 그래프가 무엇을 했는가

측정이 어떻게 이루어지는지 이해하는 것은 다른 곳에서 이를 인식하는 데 유용합니다. 그래프는 다음과 같았습니다: 톱니형 오실레이터 → AnalyserNode → 분석 결과를 읽는 ScriptProcessorNode → 제로 증폭의 GainNode → destination. 소리가 없고 볼륨은 관계가 없습니다 — 단순히 존재하지 않습니다. 그러나 destination에 연결하는 것은 저자의 설명에 따르면 브라우저가 그래프를 적극적으로 처리하게 만듭니다, 비록 최종 볼륨은 제로입니다. 바로 이 활성 오디오 경로가 블루투스 경로를 열어두어 헤드폰의 멀티포인트 전환을 방해했습니다.

이 신호의 처리 차이는 프로세서, 오디오 하드웨어, 운영 체제, 브라우저 및 드라이버에 따라 다릅니다 — 따라서 IP 변경 및 쿠키 정리에도 불구하고 안정적인 식별자가 생성됩니다. 바로 이 레이어에 대한 자세한 분석과 프로필 설정은 오디오 컨텍스트 지문 보호에 관한 기사에서 다루고 있습니다.

4단계. 결과 전송 포착하기

수집 없이 전송은 무의미하므로 다음 단계는 수집된 지문이 어디로 가는지를 찾는 것입니다. 네트워크를 XHR/Fetch로 필터링하고 ping 유형의 요청을 별도로 확인합니다 — 이는 navigator.sendBeacon에 의해 생성되며, 텔레메트리 스크립트에서 자주 사용됩니다. 페이지를 떠날 때도 살아남기 때문입니다.

거의 항상 fetch, XMLHttpRequest.prototype.send 및 navigator.sendBeacon을 추가로 감싸는 것이 유용합니다 — 그러면 요청 본문이 전송되기 전에 볼 수 있습니다. 내용이 직렬화되고 암호화될 준비를 하세요: AliExpress 사례에서는 데이터가 Alibaba의 텔레메트리로 전송되기 전에 암호화되었습니다. 그러나 이렇게 해도 두 가지 사실을 얻습니다: 수신자의 주소와 귀하의 행동에 대한 전송 시점입니다.

사이트가 브라우저뿐만 아니라 모바일 애플리케이션이나 별도의 클라이언트를 통해 작동하는 경우, 같은 질문은 DOM이 아닌 트래픽 수준에서 해결됩니다 — 가로채기 및 분석 방법은 mitmproxy를 통한 트래픽 감사 분석에서 설명되어 있습니다.

5단계. 자신의 프로필과 맵 비교하기

이제 사이트가 실제로 읽는 신호 목록이 있습니다. 남은 것은 이러한 신호에 대해 귀하의 작업 프로필이 어떤 값을 반환하는지를 확인하는 것입니다. 순서는 다음과 같습니다: 일반 브라우저에서 값을 캡처한 후, 각 안티-감지 프로필에서 캡처하고 비교합니다.

동시에 두 가지가 중요합니다: 값은 프로필 간에 달라야 하며 세션 간에 하나의 프로필 내에서 안정적이어야 합니다. 매번 시작할 때 지문이 변동하는 프로필은 안티-사기 시스템에서 동일한 지문을 가진 열 개의 프로필만큼이나 의심스럽게 보입니다.

필요한 레이어에서 대체가 실제로 존재하는지 별도로 확인하세요. 여기에서 브라우저 간의 차이가 두드러집니다: Firefox는 118버전부터 WebAudio의 상수 출력을 제공하며, 분석 데이터에 따르면 99.24%의 사용자가 세 가지 값으로 축소됩니다; Brave는 무작위 데이터를 추가하고 2026년 8월 22일부터는 AliExpress의 특정 스크립트를 차단하여 오디오 지문 보호가 기본적으로 6년 이상 제공되고 있음을 상기시킵니다; Safari는 오디오 버퍼에 오류를 추가합니다; Chrome은 공격적인 보호가 없습니다.

함정

스크립트가 이미 실행되었습니다. 파일 차단은 이미 생성된 오디오 컨텍스트를 제거하지 않습니다 — 저자는 열린 탭을 닫아야 한다고 명시적으로 언급합니다. 귀하의 도구화도 마찬가지입니다: 래퍼가 스크립트보다 늦게 적용되면 아무것도 볼 수 없습니다.
차단이 기능성을 망칩니다. 안티-사기 스택은 종종 합법적인 작업 — 인증, 결제, 실제 남용에 대한 안티봇 보호 — 에도 응답합니다. 감지 맵을 만드는 것과 스크립트를 제거하는 것은 다른 작업입니다; 후자는 사이트를 망가뜨립니다.
감지 버전이 하나가 아닙니다. 스택은 지리적 위치, 장치 유형 및 A/B 그룹에 따라 다를 수 있습니다. 실제로 작업하는 IP와 장치에서 감지 맵을 만드는 것이 의미가 있으며, 그렇지 않으면 타인의 구성을 설명하는 것입니다.
자체 도구화가 감지됩니다. 재정의된 네이티브 메소드는 올바른 toString을 잃고, 연결된 디버거는 흔적을 남깁니다. 정찰에는 중요하지 않지만, 정찰 프로필과 전투 프로필을 혼동하지 마세요 — 자동화 마스킹 기술은 헤드리스 브라우저 마스킹 가이드에서 다루어졌습니다.

결과에 필요한 프록시

이러한 맵에서 얻는 주요 실용적인 결론은 거의 항상 하나입니다: IP는 첫 번째 레이어일 뿐이며, 이는 다른 모든 것보다 먼저 확인됩니다. 안티-사기가 요청 단계에서 호스팅 주소를 이미 감지하면, 오디오 그래프와 캔버스까지는 도달하지 못할 것입니다 — 챌린지를 받거나 빈 결과를 얻고 잘못된 것을 수정하게 될 것입니다.

따라서 선택 논리는 다음과 같습니다. 심각한 스택(Akamai, DataDome, PerimeterX, Alibaba 수준의 자체 개발)을 가진 사이트의 경우, 주거용 프록시가 기본이 됩니다 — 첫 번째 필터에서 차단되지 않는 실제 공급자의 주소입니다. 모바일 애플리케이션 및 주요 청중이 스마트폰을 사용하는 사이트의 경우, 모바일 프록시가 자연스러운 프로필에 더 가깝습니다: 운영자 CGNAT는 주소를 여러 실제 사용자 간에 공유되도록 만듭니다.

반대로, 맵이 사이트가 헤더와 쿠키로 제한되고 무거운 JS 지문이 없음을 보여준다면 — 브라우저 농장은 과도하며, 일반 HTTP 클라이언트와 데이터 센터 주소로 문제를 해결할 수 있습니다.

결론

헤드폰 사례는 오디오 지문 자체의 사실로 인해 가치가 있는 것이 아닙니다 — 이는 수년간 알려져 있습니다. 방법론이 가치가 있습니다: 사람은 추측을 믿지 않고 두 가지 브라우저 API 메소드를 감싸서 저녁 동안 자신에게서 수집되는 모든 것의 전체 목록과 그것이 가는 주소를 얻었습니다. 동일한 기술은 귀하가 작업하는 모든 사이트에서 한 시간 내에 소요되며, 무작위로 설정을 조정하는 데 몇 달을 대체합니다. 차단을 수정하기 전에 감지 맵을 작성하십시오 — 그렇지 않으면 모든 프로필에서 동일한 WebGL 렌더러에 문제가 있었던 곳에서 프록시에 예산을 낭비할 위험이 있습니다.