2026년 8월 4일, Mysk 연구원들은 설정된 프록시를 우회하여 장치에서 직접 트래픽을 전송하는 WebKit의 세 가지 메커니즘에 대한 분석을 발표했습니다. 공격의 대상이 된 것은 Tor 브라우저를 포함한 모든 iOS 브라우저와 Apple의 자체 서비스인 iCloud Private Relay입니다. 프록시가 활성화되어 있고 인터페이스가 다른 국가를 표시하고 있지만, 사이트는 사용자의 실제 IP와 집의 DNS 리졸버를 인식합니다.
이것은 편집증자들을 위한 이국적인 취약점이 아닙니다. 이는 프록시를 통해 작업하는 모든 사람들이 배워야 할 아키텍처 규칙을 명확히 보여주는 사례입니다: 애플리케이션 수준의 프록시는 해당 애플리케이션의 네트워크 스택을 통과하는 트래픽만 보호합니다. 운영 체제나 개별 시스템 서비스가 생성하는 모든 것은 우회됩니다.
무엇이 유출되는가
조사는 일상적인 상황에서 시작되었습니다: 프록시 브라우저 Psylo의 사용자가 DNS 유출에 대해 개발자에게 불만을 제기했습니다. 불만을 분석한 결과, 세 가지 독립적인 유출 경로가 드러났습니다. 이들은 모두 특정 애플리케이션이 아닌 WebKit 자체에 존재합니다.
1. DNS 프리패칭 — 가장 간단하고 불쾌한 방법
메커니즘: 태그 <link rel="dns-prefetch">는 브라우저에게 호스트 이름을 미리 해결하여 향후 로딩 속도를 높이도록 요청합니다. 문제는 iOS의 WebKit이 이러한 이름을 프록시가 아닌 장치의 일반 DNS 경로를 통해 해결한다는 것입니다.
데스크탑 Safari는 Safari 5 이후로 dns-prefetch를 지원하지만, iOS는 이 태그를 무시했습니다 — iOS 26.0(2025년 9월)까지. 그때 WebKit은 오래된 암묵적 추측 DNS 프리패칭(bug 285744)을 제거하는 변경의 일환으로 이를 포함시켰습니다.
어떻게 악용되는가: 페이지는 각 방문자에게 고유한 호스트 이름을 이러한 태그에 삽입하고, 그 후 요청이 자신의 권위 있는 DNS 서버로 오는 것을 단순히 지켜봅니다 — 방문자의 실제 네트워크 주소에서. 자바스크립트나 사용자와의 상호작용은 필요 없습니다. 페이지를 여는 것만으로 충분합니다.
2. WebAuthn 관련 출처 요청 — 패스키로 인한 유출
이 경로는 iOS 18.0에서 나타났습니다. 사이트가 WebAuthn 자격 증명(즉, 패스키)을 요청하면 시스템은 https://<rpId>/.well-known/webauthn 파일을 확인하여 도메인이 지정된 의존 파티와 실제로 연결되어 있는지 확인합니다.
핵심 사항: 이 확인 요청은 브라우저의 네트워크 스택에서 발생하지 않습니다. 이는 운영 체제의 자격 증명 서비스가 수행하며, 해당 서비스는 장치에서 직접 HTTPS 요청을 보냅니다. 브라우저 내에서 설정된 프록시는 이를 전혀 알지 못합니다(bug 268426).
즉, 페이지가 패스키 요청을 시작하기만 하면 공격자의 서버는 사용자의 실제 IP로 연결을 받게 됩니다.
3. WebTransport — 장치에서 직접 QUIC
가장 최신의 경로입니다. new WebTransport(url) 호출은 프록시 구성을 우회하여 장치에서 직접 QUIC 연결을 엽니다. WebTransport는 WebKit에서 오랫동안 비활성 상태였으며, 2026년 3월 iOS 26.4에서 공개적으로 활성화되었습니다(bugs 260810 및 303453).
누가 영향을 받는가
Apple은 모든 iPhone 브라우저가 WebKit을 사용해야 한다고 요구합니다. 따라서 WebKit의 프록시 API에 의존하는 모든 iOS 브라우저가 영향을 받습니다 — 모든 iOS 버전의 Tor 브라우저와 조사 시작점인 Psylo를 포함하여. Safari와 iCloud Private Relay도 포함됩니다.
영향을 받지 않는 것: VPN 애플리케이션. 이들은 시스템 수준에서 작동하며 장치의 모든 트래픽을 완전히 감싸며, 시스템 서비스에서 생성된 트래픽도 포함됩니다. 이것이 차이의 본질입니다: 시스템 터널에는 "우회"가 없습니다. 별도의 예외는 보안 수준 Silver의 Onion Browser로, Lockdown 모드가 활성화되어 있는 경우 WebTransport를 통한 유출에 저항력이 있습니다.
개발자 측의 반응이 이미 있습니다. Psylo 1.3.1에서는 세 가지 경로가 모두 차단되었습니다: 애플리케이션은 dns-prefetch 힌트를 차단하고(페이지는 더 이상 공격자가 제어하는 이름을 해결하도록 장치를 강제할 수 없습니다), WebTransport와 WebAuthn은 기본적으로 비활성화되었습니다 — 개별 토글로 활성화할 수 있습니다. Apple은 발표 시점 기준으로 향후 업데이트에서 문제를 해결할 예정이며, 구체적인 일정은 공개하지 않았습니다.
왜 지금에서야 드러났는가
여기서의 연대기는 주목할 만하며, 별도로 분석할 가치가 있습니다 — 이는 왜 문제가 이전에 발견되지 않았는지를 설명합니다.
- 2024년 9월, iOS 18.0 — WebAuthn 관련 출처 요청 메커니즘이 등장합니다. 유출 경로는 거의 2년 동안 존재했으며 그동안 아무도 논의하지 않았습니다: 패스키에 대한 도메인 검사는 보안 요소로 보이며, 주소를 드러내는 방법으로 보이지 않았습니다.
- 2025년 9월, iOS 26.0 — WebKit이 모바일 장치에서 dns-prefetch 지원을 포함합니다. 형식적으로는 로딩 속도 최적화입니다; 사실상 페이지는 프록시를 우회하여 임의의 DNS 이름에 접근할 수 있는 능력을 갖게 됩니다.
- 2026년 3월, iOS 26.4 — WebTransport가 공개적으로 활성화됩니다. 세 번째 경로입니다.
- 2026년 8월 — 한 사용자의 DNS 유출에 대한 불만이 조사로 이어져 세 가지 경로가 동시에 드러납니다.
공통점: 이러한 기능 중 어느 것도 비식별화 채널로 설계되지 않았습니다. 이 세 가지는 모두 플랫폼의 일반적인 기능입니다: 리졸브 속도 향상, 패스키 검증, 현대적인 전송. 이들은 애플리케이션 수준의 프록시 모드와 결합될 때만 유출이 되며, 그렇기 때문에 수년 동안 아무도 이 특성으로 검증하지 않았습니다.
실제적인 결론은 간단하고 불쾌합니다: 유출에 대한 뉴스가 없다고 해서 유출이 없다는 의미는 아닙니다. 스스로 정기적으로 확인해야 하며, 누군가 분석을 발표할 때까지 기다려서는 안 됩니다.
자신을 확인하는 방법
연구원들은 공개 테스트 사이트를 공개했습니다 — leaks.psylo.app. 이 사이트는 세 가지를 확인합니다: 일반 HTTPS 트래픽(서버가 어떤 IP와 어떤 DNS 리졸버를 보는지), WebTransport 및 WebAuthn + dns-prefetch 조합. 프록시가 활성화된 상태에서 열고 예상되는 주소와 결과를 비교합니다.
기본적인 위생 상태도 별도로 확인해야 합니다 — 작업 조합에서 IP, DNS 및 WebRTC 주소가 일치하는지 확인합니다. 이전에 체계적으로 다루지 않았다면, 우리의 분석부터 시작하세요: 프록시의 DNS 유출을 확인하는 방법.
실용적인 결론: 레이어가 중요하다
WebKit의 이야기는 프록시를 통해 작업할 때 모든 플랫폼에서 염두에 두어야 할 일반 규칙의 특정 사례입니다.
- 브라우저의 프록시 ≠ 장치의 프록시. 애플리케이션 내 설정은 애플리케이션이 스스로 전송하는 트래픽만을 커버합니다. 시스템 서비스, 백그라운드 프로세스, 업데이트, 푸시 연결 및, 밝혀진 바와 같이, 내장된 패스키 서비스는 모두 별도의 경로로 진행됩니다.
- 유출은 "알려진" 장소에서만 발생하지 않습니다. WebRTC는 이미 잘 알려져 있으며, 이를 차단하는 방법이 개발되었습니다. DNS 프리패칭과 WebAuthn 검증은 성능 및 보안 기능으로, 그 누구도 이를 비식별화 채널로 고려하지 않았습니다. 브라우저의 새로운 기능은 정기적으로 새로운 우회 경로를 생성합니다.
- 플랫폼 업데이트는 조용히 당신의 보호를 무너뜨릴 수 있습니다. 여기서는 날짜를 통해 명확히 볼 수 있습니다: DNS 프리패칭은 iOS 26.0에서 "활성화"되었고, WebTransport는 iOS 26.4에서 활성화되었습니다. 사용자는 아무것도 변경하지 않았지만, 유출 표면이 스스로 증가했습니다.
이것이 멀티 계정 및 자동화에 미치는 의미
여러 계정을 운영하거나 데이터를 수집하는 사람들에게 이 위험은 추상적인 개인 정보 보호가 아니라 상당히 재정적인 것입니다. 플랫폼의 반사 시스템은 신호를 비교합니다: 세션이 하나의 IP를 주장하고, 관련 요청이 다른 주소와 집 리졸버에서 오는 경우, 이는 계정을 서로 연결하거나 세션을 의심스럽게 표시할 수 있는 충분한 이유입니다.
실용적인 결과:
- 모바일 브라우저에서 프록시 모드로 작업하는 멀티 계정 세션을 운영하지 마십시오. 플랫폼이 구멍을 막기 전까지는 iOS의 애플리케이션 레이어는 본질적으로 신뢰할 수 없습니다.
- 트래픽을 시스템적으로 감싸십시오. 작업이 모바일 환경이라면, 장치 수준에서 프록시를 설정하거나 별도의 게이트웨이를 통해 라우팅하는 것이 더 합리적입니다. 브라우저 내부 설정에 의존해서는 안 됩니다.
- OS 및 브라우저의 주요 업데이트 후에는 조합을 확인하십시오. 최소 분기마다 한 번. 이를 체크리스트에 추가하고 "무언가 잘못될 때"까지 기다리지 마십시오.
- 사용하지 않는 것은 비활성화하십시오. WebTransport와 WebAuthn은 파싱이나 SMM을 위한 작업 프로필에서 거의 필요하지 않습니다 — 이들을 비활성화하면 세 가지 유출 경로 중 두 가지를 제거할 수 있습니다.
이때 IP의 품질은 별도의 변수로 남아 있습니다: 밀폐된 데이터 센터 구성에서도 데이터 센터 주소는 ASN에 따라 자신을 드러냅니다. 일반 사용자처럼 보이는 것이 중요한 시나리오에서는 주거용 프록시가 작동하며, 가장 강력한 반사 시스템을 가진 모바일 애플리케이션 및 플랫폼에서는 실제 이동통신 사업자의 IP를 가진 모바일 프록시가 필요합니다. 그러나 트래픽의 일부가 물리적으로 프록시를 우회한다면 어떤 프록시 클래스도 구제할 수 없습니다 — 먼저 밀폐성을 확보한 후에 주소의 품질을 고려해야 합니다.
결론
WebKit의 세 가지 버그 — DNS 프리패칭, WebAuthn 관련 출처 요청 및 WebTransport — 는 "프록시가 활성화되어 있다"와 "모든 트래픽이 프록시를 통해 간다"는 두 가지 다른 주장이란 것을 보여주었습니다. iOS에서는 이들 사이의 간극이 충분히 넓어 일반 웹 페이지가 단 한 줄의 자바스크립트 없이도 Tor 브라우저 방문자의 실제 주소를 알 수 있었습니다.
Apple이 수정 작업을 준비하는 동안, 유일한 실용적인 전략은 추측하지 말고 확인하는 것입니다. 테스트 사이트를 열고 주소를 비교하며, 불필요한 API를 비활성화하십시오. 그리고 OS의 모든 주요 업데이트를 사건으로 간주하여 구성 검증을 다시 수행해야 합니다. 개인 정보 보호와 그 환상 사이의 차이는 종종 제때에 묻지 않은 한 가지 질문에 달려 있습니다: "모든 트래픽이 정말로 그렇습니까?". 또한 주소 외에 어떤 신호가 당신을 드러내는지 이해하는 것도 유용합니다 — 이에 대해서는 브라우저 지문 방지에 관한 자료에서 다루었습니다.
```