TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 26 READS

프록시 뒤에 숨었는데 진짜 IP가 샌다? WebKit에서 발견된 IP·DNS 유출 문제

프록시 뒤에 숨었는데 진짜 IP가 샌다? WebKit에서 발견된 IP·DNS 유출 문제
SOURCE IMAGE · HACKER NEWS
프록시 뒤에 숨었는데 진짜 IP가 샌다? WebKit에서 발견된 IP·DNS 유출 문제

iOS 앱들의 개인정보 문제를 꾸준히 파헤쳐온 보안 연구팀 Mysk가 이번엔 애플 웹 엔진의 문제를 들고 나왔어요. 사파리의 심장인 WebKit에서 일부 네트워크 요청이 프록시 설정을 우회해서 나가고, 그 과정에서 사용자의 실제 IP 주소와 DNS 질의가 노출된다는 내용이에요. 이 문제는 프록시 기능을 내장한 프라이버시 브라우저들, 그리고 애플이 직접 만든 프라이버시 기능인 iCloud Private Relay에까지 영향을 미친다고 해요.

왜 WebKit 문제가 사파리만의 문제가 아닐까요

먼저 배경을 짚고 갈게요. iOS에서는 오랫동안 모든 브라우저가 WebKit 엔진을 쓰도록 강제돼 왔어요. 아이폰의 크롬도, 파이어폭스도 겉모습만 다를 뿐 속은 전부 WebKit이라는 뜻이에요(EU에서는 규제 덕분에 최근에야 다른 엔진이 허용되기 시작했죠). 그래서 WebKit에 구멍이 있으면 사파리 하나가 아니라 iOS 브라우저 생태계 전체가 같은 구멍을 공유하게 돼요. 특히 '모든 트래픽을 프록시로 보내드립니다'라고 광고하는 프라이버시 중심 브라우저들도 결국 WebKit 위에서 돌아가니까, 엔진이 프록시를 우회하면 앱을 아무리 잘 만들어도 막을 방법이 마땅치 않아요.

iCloud Private Relay가 뭐냐면

애플 유료 구독(iCloud+)에 포함된 프라이버시 기능인데요. 사파리 트래픽을 두 개의 중계 서버를 거쳐 보내는 이중 릴레이 구조예요. 첫 번째 릴레이는 애플이 운영하는데 사용자가 누군지는 알지만 어디에 접속하는지는 모르고, 두 번째 릴레이는 제3자 파트너가 운영하는데 목적지는 알지만 사용자가 누군지는 몰라요. 어느 한 쪽도 '누가 어디에 접속했는지'를 온전히 알 수 없게 쪼개놓은 설계죠. 웹사이트 입장에서는 사용자의 실제 IP 대신 릴레이의 IP만 보이게 돼요. VPN과 비슷해 보이지만 애플 생태계에 깊이 통합된 형태라고 이해하시면 돼요.

뭐가 새고 있다는 걸까요

연구팀이 발견한 건, 이런 보호 장치가 켜져 있는데도 일부 요청이 프록시 터널을 타지 않고 기기에서 목적지로 직접 나간다는 거예요. 이러면 두 가지가 노출돼요. 첫째는 실제 IP 주소예요. 접속한 서버가 릴레이 IP가 아닌 진짜 IP를 보게 되니, 위치와 신원을 숨기려던 목적이 무너져요. 둘째는 DNS 질의예요. DNS가 뭐냐면 도메인 이름을 IP 주소로 바꿔주는 인터넷 전화번호부 같은 건데, 이 질의가 프록시 밖에서 이뤄지면 통신사나 같은 네트워크의 관리자가 사용자가 어떤 사이트에 접속하려는지 목록을 훤히 볼 수 있어요. 공용 와이파이에서 프라이버시를 지키려던 사람, 검열이 있는 네트워크에서 프록시에 의존하던 사람에게는 특히 뼈아픈 문제죠.

이런 누수는 왜 생길까요

프록시 누수는 사실 구조적인 문제예요. 앱이 '내 트래픽은 프록시로 보내줘'라고 설정해도, 그 설정이 적용되는 건 특정 네트워킹 계층뿐인 경우가 많거든요. 그런데 브라우저 엔진 같은 거대한 프레임워크는 내부에서 여러 경로로 연결을 열어요. 미디어 재생이나 리소스 미리 가져오기(프리페치) 같은 기능이 별도의 코드 경로로 네트워크에 나가면, 프록시 설정을 물려받지 못한 채 직접 연결이 만들어질 수 있어요. 예전에 VPN을 켜도 WebRTC(브라우저의 실시간 통신 기능)를 통해 실제 IP가 노출되던 유명한 사례와 닮은꼴이에요. 보호 장치는 경로 전체를 다 덮어야 의미가 있는데, 한 군데라도 빠지면 거기로 새는 거죠.

한국 개발자와 사용자에게 주는 시사점

개발자라면, iOS에서 WKWebView나 프록시 API를 쓰는 앱을 만들 때 '설정했으니 다 적용되겠지'라고 가정하면 안 돼요. 프라이버시가 중요한 앱이라면 실제로 패킷을 캡처해서 모든 트래픽이 의도한 경로로 나가는지 검증하는 과정이 필요해요. VPN이나 보안 관련 앱을 만드는 팀이라면 더더욱요. 일반 사용자 입장에서는, 앱 하나에 내장된 프록시보다 시스템 전체를 덮는 VPN이 상대적으로 우회 경로가 적다는 점, 그리고 이런 문제는 결국 애플의 패치로 해결되니 OS 업데이트를 미루지 않는 게 중요하다는 점을 기억하면 좋아요.

정리하면, 프라이버시 보호는 켜두는 것만으로 끝나는 게 아니라 그 보호가 모든 경로를 덮고 있는지가 관건이라는 걸 다시 보여준 사례예요. 여러분은 앱을 만들 때 네트워크 트래픽이 실제로 어디로 나가는지 검증해보신 적 있나요? iOS의 WebKit 강제 정책, 보안 관점에서는 득일까요 실일까요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://mysk.blog/2026/08/04/webkit-proxy-icloud-private-rel...
SHARE
처리 중...