iOS 프록시 브라우저의 IP·DNS 누출, WebKit 우회 경로 3가지

iOS와 macOS의 WebKit 기반 브라우저는 웹 트래픽 전체를 프록시 서버로 우회시키도록 설계할 수 있다. 애플이 iOS 17과 macOS 14에서 도입한 WKWebsiteDataStore.proxyConfigurations API가 그 토대인데, iOS용 Tor 브라우저와 Mysk의 Psylo 같은 프록시 브라우저가 모두 이 방식으로 동작한다. 원칙적으로 웹 페이지가 만드는 모든 네트워크 연결은 이 프록시를 거쳐야 하고, 그 결과 웹사이트는 오직 프록시의 IP 주소만 보게 된다. 그런데 Mysk는 이 규칙을 우회해 트래픽을 기기에서 직접 내보내는 WebKit 기능 세 가지를 발견했다. DNS 프리페칭, WebAuthn의 Related Origin Requests, 그리고 WebTransport다.

조사는 특정 사이트에서만 DNS 누출이 발생한다는 Psylo 사용자의 버그 리포트에서 시작됐다. 모든 트래픽이 프록시로 나가야 하는데 일부 사이트에서만 문제가 생긴다는 점이 이상했고, 파고든 끝에 세 갈래의 누출을 확인했다. 세 가지 모두 WebKit 내부에서 발생하며 프록시 설정을 그냥 건너뛴다. 애플 앱스토어 정책상 iOS의 모든 브라우저는 WebKit을 써야 하므로, 이 API에 의존하는 iOS 브라우저는 원리상 전부 영향을 받는다.

사파리 사용자도 안전하지 않다

주목할 점은 이 누출이 애플의 iCloud 프라이빗 릴레이에도 그대로 나타난다는 것이다. 프라이빗 릴레이는 iCloud+ 구독자를 위한 기능으로, 사파리의 웹 트래픽과 DNS 질의를 2홉 릴레이로 우회시켜 어느 한쪽도, 심지어 애플조차도 '누가' '어떤 사이트를' 보는지 동시에 알 수 없게 설계됐다. 그러나 세 가지 누출 모두 WebKit의 표준 페이지 로딩 과정 바깥에서 일어나기 때문에 프라이빗 릴레이의 보호망을 벗어난다. 반대로 VPN은 기기 전체 트래픽을 시스템 수준에서 터널링하므로 이 문제의 영향을 받지 않는다. 프록시 브라우저와 시스템 VPN의 구조적 차이가 그대로 드러나는 지점이다.

세 가지 누출의 작동 방식

첫째, DNS 프리페칭은 웹페이지가 태그로 브라우저에 미리 호스트명을 해석해 두게 하는 성능 최적화 기능이다. 문제는 WebKit이 브라우저가 지정한 프록시를 무시하고 기기의 일반 DNS 경로로 이 조회를 처리한다는 것이다. 공격자는 방문자별로 고유한 호스트명을 태그에 심어 두고 자신의 권한 DNS 서버로 들어오는 질의를 관찰하면, 프록시가 아닌 방문자의 실제 네트워크를 확인할 수 있다. 프리페치 태그가 있는 사이트에서만 문제가 나타났던 이유가 바로 이것이다. iOS는 iOS 26.0(2025년 9월)부터 이 태그를 처리하기 시작했다.

둘째, WebAuthn의 Related Origin Requests는 하나의 패스키를 조직이 소유한 여러 도메인에서 함께 쓰게 해 주는 기능이다. 페이지가 자기 출처와 다른 rpId로 자격 증명을 요청하면, 클라이언트는 먼저 https:///.well-known/webauthn 파일을 가져와 허용 출처를 확인한다. 그런데 이 검증 요청은 브라우저의 네트워크 스택이 아니라 운영체제의 자격 증명 서비스가 직접 발생시킨다. 앱이 설정한 프록시를 전혀 알지 못한 채 기기에서 곧장 HTTPS 요청이 나가는 것이다. 더구나 mediation: "conditional"을 쓰면 어떤 UI도 뜨지 않고 사용자 상호작용 없이도 조회가 발생한다. 애플은 이 기능을 iOS 18.0·사파리 18.0(2024년 9월)에서 발표했다.

셋째, WebTransport는 HTTP/3과 QUIC 위에서 동작하는 저지연 통신 방식이다. new WebTransport(url) 호출은 기기에서 바로 QUIC 연결을 여는데, WebKit이 자체 네트워크 파라미터로 연결을 구성하면서 세션의 프록시를 넘겨주지 않아 서버가 실제 IP를 보게 된다. 예외적으로 Onion Browser의 'Silver' 보안 등급은 WebKit에 잠금 모드를 적용해 WebTransport를 아예 비활성화하므로 이 누출을 피한다. WebTransport는 iOS 26.4(2026년 3월)에서 공개적으로 출시됐다.

실무적 함의와 한계

Mysk는 세 가지 누출을 Psylo 1.3.1에서 수정했다. dns-prefetch 힌트를 차단하고 WebTransport와 WebAuthn을 기본값으로 비활성화했으며, 이 기능이 실제로 필요한 사이트에서는 사일로별 토글로 사용자가 명시적으로 다시 켤 수 있게 했다. 프라이버시 트레이드오프의 결정권을 사용자에게 넘긴 셈이다. 다만 이는 어디까지나 특정 앱 차원의 완화책이라는 점을 분명히 볼 필요가 있다. 근본 원인은 WebKit과 운영체제 구성요소가 프록시 설정 바깥에서 연결을 만드는 데 있고, 이 설계가 그대로인 한 동일한 API에 의존하는 다른 iOS 프록시 브라우저와 프라이빗 릴레이는 여전히 노출된다. Mysk는 Tor 프로젝트 및 Onion Browser 개발진에게 이 문제를 알렸고, 검증용 사이트(leaks.psylo.app)를 공개했다.

결국 이번 사례가 남기는 교훈은 앱 수준 프록시의 경계가 생각보다 취약하다는 것이다. 브라우저가 명령한 프록시를 성능 최적화나 자격 증명 검증, 새 전송 프로토콜 같은 '표준 로딩 바깥'의 경로들이 조용히 무시할 수 있기 때문이다. 익명성이 실질적으로 중요한 상황이라면, 특정 기능만 막는 방식보다 시스템 전체 트래픽을 터널링하는 VPN이나 여러 계층을 조합한 방어를 함께 고려하는 편이 안전하다. 프라이버시 기능을 도입하거나 평가하는 실무자라면, 겉으로 드러나는 페이지 트래픽뿐 아니라 OS 구성요소가 대신 발생시키는 부수적 연결까지 점검 범위에 넣어야 한다.