▲

사용자가 자신의 로컬 네트워크에 접근하는 사이트를 제한하는 제안

 (github.com/explainers-by-googlers)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 크롬 보안팀이 웹사이트의 로컬 네트워크 접근 문제를 해결하기 위해 새로운 "로컬 네트워크 접근 권한" 제도를 제안함
  • 현재는 공개 웹사이트가 사용자의 프린터 등 로컬 네트워크 장치에 무단 접근·공격 가능성이 있으나, 이 제안은 사용자 허락 없이 로컬 네트워크 요청을 차단하는 것을 목표로 함
  • 기존 Private Network Access(PNA)와 달리, preflight 대신 사용자 권한 동의 기반으로 작동해 사용자 통제권을 강화하며, 장치 변경 없이 사이트 업데이트만으로 대응 가능
  • 구체적으로, 공용 사이트가 로컬 IP, .local 도메인 등에 fetch 요청 시, 권한이 없으면 브라우저가 사용자에게 명시적 동의 요청을 띄움
  • 이 정책으로 보안·프라이버시 강화와 함께, IoT 기기 설정 등 정당한 사용 사례는 사용자 허락 시 정상 작동 보장

제안 개요 및 목적

  • Chrome Secure Web and Network 팀이 공용 웹사이트의 로컬 네트워크 무단 접근 문제 해결을 위해 '로컬 네트워크 접근' 권한 부여 방식 초기 설계안을 공개함
  • 기존에는 방문한 사이트가 사용자의 프린터, 공유기 등 로컬 네트워크 장치로 CSRF, 공격 등을 시도할 수 있었음
  • 앞으로는 공용 IP → 로컬 IP 등 주소 공간 간 경계를 넘는 요청을 브라우저가 차단하고, 사이트별로 명시적 사용자 허락을 받아야만 허용하는 구조를 제안

배경 및 차별점

  • 기존 Private Network Access(PNA) 는 preflight(사전 요청/응답) 기반으로, 장치에도 변경이 필요해 도입이 어려웠음
  • 이번 제안은 사용자 권한 동의만으로 처리할 수 있고, 사이트만 소폭 수정하면 되므로, 실제 적용과 확산이 용이함

목표와 비목표

  • 목표
    • 드라이브-바이 웹 기반의 취약 장치·서버 악용 차단
    • 사용자가 원하고 허용한 경우에만, 공용 웹사이트에서 로컬 장치와 통신 허용
  • 비목표
    • 기존 로컬 장치 설정/제어 등의 합리적 사용 흐름 전체 차단은 지양
    • 로컬 네트워크 HTTPS 문제, 복잡한 인증서 발급 등은 이번 제안 범위에서 제외

사용 사례

  • 1번: 일반 사용자가 원치 않는 경우, example.com이 192.168.0.1 등으로 요청 시 브라우저가 허락 여부를 묻고, 거부 시 요청 차단
  • 2번: IoT, 공유기 등 장치 제조사의 공식 웹 설정 페이지는 처음 접근 시 사용자에게 허락을 받아 통신 허용

구체 설계

  • 주소 공간 분리:
    • loopback(자기 자신 전용), local(로컬 네트워크 내부), public(모두 접근 가능) 세 계층으로 IP 네트워크 계층을 분류함
    • .local 도메인, RFC1918/4193의 프라이빗 IP, RFC6762의 링크로컬 네임 등 다양한 로컬 네트워크 식별 기준을 포함함
  • 로컬 네트워크 요청: public→local, public→loopback, local→loopback 등 상위 공개주소에서 내부 네트워크로 접근 시 권한 요구
    • 공개 네트워크에서 로컬/루프백 네트워크로의 요청부터, 로컬에서 루프백으로의 요청까지를 로컬 네트워크 요청으로 간주함
    • 예외: 로컬→로컬, 루프백→어떤 주소 등은 제한 대상이 아님
  • 권한 프롬프트:
    • 사이트가 로컬 네트워크로 요청 시, 권한이 없다면 브라우저가 사용자에게 허용 여부를 묻는 프롬프트를 띄움
    • 거부 시 요청 차단, 수락 시 요청 진행
  • fetch API 통합: fetch 호출 시 targetAddressSpace: "local" 등 옵션 명시, 명확히 구분 가능
    • Fetch 스펙은 DNS 해석 없이 단순 연결만 정의하므로, 새 연결에서 로컬 네트워크 요청 여부 판단
    • 보안 컨텍스트에서만 로컬 네트워크 요청 허용, 권한 미획득 시 프롬프트, 권한 부여 시 요청 허용
    • fetch()의 options에 targetAddressSpace 파라미터 추가로 개발자가 명시적으로 목적지 주소 공간 지정 가능
    • 실제 연결된 주소가 옵션의 공간과 다르면, 요청 실패로 처리해 혼합 콘텐츠 우회 방지
  • HTML, WebRTC, ServiceWorker 등도 동일 정책 적용
    • HTML 문서/워커에 주소 공간 값을 추가해 출처 기반 공간을 추적함
    • WebRTC 내 ICE Agent의 후보 추가 시, 로컬/루프백 주소는 권한 프롬프트를 사용함
    • 권한은 Permissions API와 연계하여, 사이트가 현재 권한 상태를 쿼리 가능
    • 기본적으로 상위 문서에서만 로컬 네트워크 접근 가능, 필요시 Permissions Policy의 위임 정책으로 하위 프레임에 권한 위임 가능
  • 혼합 컨텐츠(HTTP/HTTPS) 문제:
    • 비보안 컨텍스트에서 로컬 네트워크 접근 시도, HTTP 기반 하위 리소스 로딩, 혼합 콘텐츠 차단 적용 시나리오 등
    • 프라이빗 IP 리터럴, .local 도메인, targetAddressSpace 지정 요청 등은 혼합 콘텐츠 업그레이드 및 차단 단계를 생략하고, 후속 연결 시 권한 미보유 오리진이면 차단
  • 동작방식 예시
    • 예상치 못한 로컬 네트워크 접근 시, 사용자가 권한을 거부해 무단 요청을 차단할 수 있음
    • 제조사가 운영하는 장치 제어 페이지의 경우, 적절한 프로퍼티(예: targetAddressSpace="local")로 호출 시, 사용자 동의가 있을 경우 기존대로 동작 가능함

대안 및 논의

  • PNA 방식:
    • 기존 PNA는 CORS 프리플라이트를 요구했으나 실제 적용 및 배포 어려움이 컸음
    • 일부 구간에서는 권한 프롬프트와 혼합 콘텐츠 예외 허용 방안 제안
    • DNS 문제, 장치별 사양 미지원 등으로 현실적 한계가 존재함
  • 모든 로컬 네트워크 요청 차단: 단순하지만, 사용례 파괴와 우회 비용 증가 우려로 현실적이지 않음
  • 현 상태 유지: OS에서 앱별로 로컬 네트워크 권한을 관리하기 시작하면서, 브라우저 차원의 관리 필요성 강조됨
  • 혼합 콘텐츠 대안:
    • "보안 로컬 네트워크 하위 리소스만 허용" 등 접속 방법의 보안성 평가와 구현 부담이 논의됨
    • 응답 헤더/메타태그로 주소 공간 선언하는 법, HTML 요소 속성 추가 등도 대안으로 논의됨

추가 논점

  • HTML subresource(iframe, img 등)도 주소 공간 속성 추가 가능성 논의
  • 권한 부여 시 과도한 권한 전달(transitivity) 이슈 등 연구 결과 반영
  • 메인 프레임 이동 시 로컬 네트워크 접근 제한하거나 경고 인터스티셜 표시
  • 로컬/루프백 주소 대상 모든 크로스 오리진 요청을 폭넓게 로컬 네트워크 요청으로 간주하는 안도 고려됨
  • 네트워크별로 세분화된 권한 부여 방안 연구, 다른 네트워크 이동(다른 장소 접속) 시 재동의 필요성

보안·프라이버시 고려사항

  • 권한을 받은 사이트는 사용자의 네트워크 전체 장치에 탐색·접속 권한 확대 우려
  • 사용자는 프롬프트 수락 시 의도를 명확히 인지해야 하며, preflight 기반보다 직접적 통제 가능
  • 사전 권한 없이는 어떤 로컬 네트워크 요청도 불가, 프라이버시 보호 측면 강화
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 나는 처음 봤을 때 이 기능이 마음에 드는 감정, 웹사이트가 임의로 로컬 IP(혹은 어떤 IP든)에 HTTP 요청을 날릴 수 있다는 개념 자체가 정말 말도 안 되는 위험이라고 생각, 만약 이로 인해 일부 기업용 앱이나 통합 기능이 깨진다 해도 신경 쓰지 않는 입장, 기업은 관리도구로 이 기능을 다시 활성화하면 되고, 일반 유저는 직접 설정하면 된다는 의견, "이 웹사이트가 로컬 장치를 제어하려 합니다 - 허용/거부"라는 팝업만 띄우면 충분하다고 주장

    • 오해가 있는 시각 제시, 로컬 네트워크 장치는 CORS 덕분에 임의의 웹사이트로부터 보호되고 있다는 설명, 완벽하진 않지만 꽤 효과적인 방식이라는 견해, 문제는 CORS가 오직 타겟 서버의 동의에만 의존한다는 점 강조, 서버가 특정 헤더로 해당 웹사이트의 접근을 허락해야 하기 때문, 이번 제안은 서버와 웹사이트가 모두 통신을 원하더라도 유저 승인을 명확히 받아야만 하도록 더 강화하는 취지, 과거에는 서버-웹사이트 합의만으로 충분하다고 봤지만, 최근 Facebook과 같은 사례에서 웹사이트가 휴대폰 내 앱에 몰래 접근하는 일이 이 원칙을 깨버렸다는 의견, 즉, 웹사이트와 로컬 네트워크 서버가 유저의 이익과 반하게 작동할 수 있게 된 현실 지적

    • "일반 유저는 직접 팝업에서 허용/거부 설정하면 된다"라는 의견에 대해, MacOS가 현재 앱별로 이런 권한 요청을 하고 있는데 대부분의 유저가 별 생각 없이 '허용'을 누른다는 점을 언급, 사이트별로 한다고 해서 경계심이 아주 크게 늘지는 않을 거라는 추측

    • 웹사이트가 왜 로컬 네트워크에 접근해야 하는지 이해가 안 되는 내용, 이건 완전히 새로운 보안 위협 모델을 만들 뿐이라는 주장, 이미 더 나은 해결책이 없는 케이스가 있는지도 의문 제시

  • Apple, Microsoft, Google 등도 USB와 Bluetooth에 대해서도 이와 비슷한 접근을 해주길 바라는 마음, 최근 설치하는 거의 모든 앱이 Bluetooth 접근 권한을 요구하는데 매우 불편하다고 느낌, 앱이 접근 가능한 블루투스 디바이스 ID를 manifest에 명시하고 OS에서 해당 장치로만 접근을 제한해주기를 희망, 예를 들어 Bose 앱은 오직 Bose 기기만 볼 수 있어야 한다는 의견, 앱이 어떤 권한을 요청하길래 거부한 경험, 카메라나 GPS 권한과 비슷하게 기기 ID 등록과 사용자 프롬프트가 있으면 좋겠다는 생각, Bose의 경우 prefix를 bose.xxx로 등록하고 manifest에서 "bose.*" 접근만 요청, OS에서 해당 rule만 허용하는 식, USB, 로컬 네트워크 기기에도 비슷한 ID 체계 적용을 제안, OS가 앱이 네트워크, USB, 블루투스를 탐색하지 못하게 하는 방향 희망

    • 언젠가는 Apple이라도 언젠가 앱에게 '가짜 권한 허용' 옵션을 제공해주길 바라는 기대, 예를 들어 앱이 내 연락처 목록이 꼭 필요하다고 할 때, 진짜와 구분 안 되는 랜덤 목록을 보여주는 방법, GPS 때도 비슷하게 적용, WhatsApp이 연락처를 공유하지 않으면 연락처 이름을 지정할 수 없다는 이야기도 들었다는 경험

    • Github 제3자 앱 통합처럼, "ABC가 내 레포를 조회하고 싶어 함. 어떤 레포를 공유할지?"와 같은 세분화된 선택권 모델 선호

  • Internet Explorer가 예전에는 존(zoning) 시스템으로 이런 문제를 해결했다는 입장, 자세한 정보는 MS 문서 참고 의견

    • 아이러니하게도 Chrome도 Windows에서 부분적으로 IE의 존 보안 체계를 사용했지만, 이에 대한 공식 문서는 거의 없었다는 내용

    • 이런 현대적 대안이 존재하지 않는 게 어이없다는 평가, 로컬 네트워크 접근 또한 카메라, 마이크처럼 특별한 권한으로만 허용해야 한다고 생각

  • 웹 브라우저가 기본적으로 이런 행위를 허용했다는 게 믿기 힘든 현실, 퍼블릭 웹사이트가 내 전체 파일 시스템에 몰래 접근할 수 있다고 생각하면 끔찍한 보안 취약점인데, 로컬 네트워크 서비스에 대해선 XHR로 그냥 사용 가능하고, 보안을 서버 설정에만 맡기는 실태, 개발자라면 본인 개발 PC에서 테스트 용으로 사내 웹앱을 돌릴 때(아주 느슨하거나 없는 보안설정), facebook.com, google.com 등에서 바로 접근 가능, 집에서도 라우터 방화벽을 믿고 인증 없는 서비스를 돌리는 사람들이 많은데 과연 전부 CORS 설정 제대로 해놨을지 확신이 없다는 문제의식

    • 과연 모든 사람들이 CORS 설정을 제대로 해두었을지에 대한 회의감, 실제론 거의 0%에 가깝게 미설정 되어 있을 거라는 주장

  • 이번 제안이 Meta가 자사 SDK를 이용해 네이티브 앱과 웹사이트 사이에 localhost 기반 트릭 방식으로 식별 코드 공유를 하는 걸 막는 데 도움 줄 수 있다는 기대, 특히 Android에서 해당 사례 더 자세히 보기

  • 웹사이트가 로컬 네트워크에 접근할 권한 자체를 갖는 것은 매우 거칠고 불필요하게 광범위한 허용이라는 지적, 실제 권한이 필요한 사이트 대부분은 오직 하나의 로컬 서버에만 접근 필요, 모든 로컬로 허용하는 건 최소 권한 원칙 위반, 대부분 유저가 로컬호스트나 네트워크에 뭐가 뜨는지 알지 못 해 위험성도 제대로 인지 못 한다는 문제 제기

    • 대부분의 사람들은 localhost나 네트워크에 뭔가 뜨는지 알지 못 하므로, 브라우저에서 예를 들어 http://localhost:3146이나 http://localhost:8089 접속 허용 메시지를 보여줘도 무슨 뜻인지 추측조차 못함, 기술 전문 용어가 아닌, "이 사이트가 로컬 네트워크 리소스에 접근하려고 합니다"처럼 직관적인 메시지가 사용자에게 더 낫다는 주관

    • 제대로 구현하려면 사실상 브라우저 내 파이어월 수준 접근 필요, 어떤 CIDR, 포트, 등 세밀하게 제어 가능한 API가 있으면 좋겠다는 의견, 브라우저 확장에서도 이런 firewall API를 쓰거나, 기본 UI로 특정 머신(예: 라우터), LAN, VPN, 윈도우의 private network 등 범위를 명확히 구분해 각각 접근 권한 요청이 가능하도록 만드는 걸 희망

  • 예전에 NPAPI 플러그인이 사라진 후로, 여러 퍼블릭 웹사이트가 로컬 소프트웨어와 연동하려면 로컬호스트에 HTTP 서버를 띄울 수밖에 없는 구조가 됐다는 점, 만약 이 사용성까지 복잡하게 만든다면 엄청나게 불편해질 거라는 우려, 브라우저 개발자들이 NPAPI 이후에 대체 기술을 마련했었어야 했는데 지금은 이미 늦었다는 주장

    • 대부분의 소프트웨어는 OS 단에서 프로토콜 핸들러를 등록해서, 예를 들어 웹사이트가 zoommtg:// 같은 링크를 넘기면 브라우저가 Zoom 등으로 연동하는 방식을 선호, Jupyter Notebook 같이 교차 출처 요청 없이 로컬에서 쓰는 건 영향 없음, OAuth2 로그인 후 localhost URL로 보내는 것도 단순 리디렉트라 문제 없을 것으로 판단

    • 이런 방식(로컬 앱과의 HTTP 서버 통한 통신)이 완전히 사라진다면 오히려 더 좋겠다는 입장, 보안 취약점 원천 제공 역할을 해왔다는 주장

    • Mozilla Native messaging 같은 기술이 이미 존재, 확장 프로그램 설치는 필요하지만 NPAPI와 비교했을 때 공정한 방식이라는 관점

    • 만약 로컬 소프트웨어가 'pull' 방식(앱이 주기적으로 외부에 요청)으로 동작한다면 굳이 서버 띄울 필요 없어지고, 부가적으로 웹사이트가 남의 로컬 네트워크 이곳저곳을 함부로 스캔하는 일도 없어지니 좋을 거라는 의견

  • JavaScript에서 cors 옵션 없이 fetch 또는 POST 요청을 날리면 CORS가 응답을 읽을 수 없게 할 뿐, 실제로 요청 전송 자체는 브라우저가 처리함, 만약 로컬 앱이 서버에서 프록시로 CORS 헤더를 추가하게 만들면 어떤 사이트든 JS fetch/XMLHttpRequest로 접근 가능, 확장 프로그램은 헤더를 수정해 CORS를 우회할 수도 있음, 헤더 만지기로 이런 우회가 너무 쉽고, CSP(Content Security Policy)는 실제로 우회가 매우 어렵거나 거의 불가능, 페이스북 앱은 지금도 자체 cors 프록시 서버 돌리면서 이런 구조 운영, WebSocket도 있으니 Chrome에 localhost 접근 차단 플래그가 있어도 무용지물, localhost 완전 차단은 오히려 해가 크다는 주장, 많은 사용자가 self-hosted 북마크, 노트, 패스워드 관리앱 등 로컬 서버 활용하고 있기 때문에, 이런 케이스를 막는 건 불합리

  • IPv6 환경에서 문제 발생 우려, 실제로 IPv6 주소가 부분적으로 로컬인지 구분할 방법이 있는지 궁금, 없다면 IPv6 only 네트워크에선 이번 제안이 문제될 것으로 판단, IoT 앱에서 이런 문제 겪은 경험, IPv6 주소가 로컬인지 식별 어려워 일단 IPv6는 모두 IPv4 로컬로 리디렉션하는 방식 선택, IPv6 link local도 실상 일반 앱에서 쓸 수 없는 주소라 별 의미 없었음, .local 도메인을 로컬 서버로 인정해주는 건 다루기 나름인데 OS마다 해석이 달라 구현이 일관되지 않다는 문제, 예: Raspberry Pi OS에선 "some_address"는 mDNS로 풀리지만 "someaddress.local"은 안 되고, Ubuntu 24.04에선 "someaddress.local"만 되고 "someaddress"는 안 됨, "someaddress.local." 도 작동하지 않음, 마지막으로, 로컬 네트워크 주소에 대해 프라이빗 인증서를 쓸 수 없다는 점도 답답함, "로컬 주소에 https 제한" 문제도 반드시 해결되어야 한다고 강조

    • IPv6도 여전히 '라우팅 가능' 개념이 남아있어서 논리적으로 라우팅 테이블 단위로 site-local 여부를 정의할 수 있다는 의견, 옛날 IPv4는 2번째 옥텟에 site, 3번째 옥텟에 VLAN 구조였고, IPv6는 옵션 더 많음, 모든 IPv6 기기는 link local 주소를 가지며(로컬 VLAN), .local은 Apple, DNS 등 네임-주소 매핑 관련 용어로 IP 주소와 직접 무관함, 로컬 네트워크에서 https 인증서는 Lets Encrypt의 DNS-01 인증, CNAME 등을 활용해 가능, 꽤 번거롭지만 무료 방법이 존재하고 acme.sh 같은 도구도 추천, IPv4, IPv6, DNS, mDNS, Bonjour 등 컨셉을 더 명확히 정리 필요, 패킷 캡처조차 유료였던 시절을 떠올리며 지금은 훨씬 낫다는 회상

    • IPv6 주소가 "로컬"인지 엔드포인트에서 구분하는 방법이 없다는 주장을 명확히 함, 이는 IPv6의 원리가 글로벌 라우팅이기 때문, 기사에서 Google 역시 "local"의 의미를 논의하다가 중간에 'private' 정의로 바꾸는 등 혼선 있었다는 지적, HTTP 확장으로 비표준적인 CIDR 기반 보안 경계선을 만드는 건 황당한 접근, 앱은 공개 서비스라고 가정하고 보안 모델을 설계하는 게 맞다는 입장, .local은 mDNS 규격에 포함되어 있지만 실제로는 거의 무시됨

  • 이런 방식이 얼른 실현되기를 진심으로 바라는 마음, 특히 HTTPS 도메인에서 HTTP 로컬사이트에 접근할 수 있는 기능이 있길 기대, 스마트홈, 미디어/엔터테인먼트 등 멋진 활용사례가 많다는 언급

답변달기