클라이언트의 내부 네트워크에 있는 장치 및 서버를 웹에 대규모로 노출시키는 것과 관련된 위험을 완화합니다.
사설 네트워크에 호스팅된 기기 및 서버에 요청을 보내는 악성 웹사이트는 오랫동안 위협이 되어 왔습니다. 예를 들어 공격자는 무선 라우터의 구성을 변경하여 Man-in-the-Middle 공격을 지원할 수 있습니다. CORS-RFC1918은 브라우저에서 이러한 요청을 기본적으로 차단하고 내부 기기가 공개 인터넷의 요청을 선택하도록 하는 제안입니다.
이 변경사항이 웹 생태계에 미치는 영향을 이해하기 위해 Chrome팀은 비공개 네트워크용 서버를 빌드하는 개발자의 의견을 기다리고 있습니다.
현 상황에 어떤 문제가 있나요?
많은 웹 서버가 사설 네트워크 내에서 실행됩니다. 무선 라우터, 프린터, 인트라넷 웹사이트, 엔터프라이즈 서비스, 사물 인터넷 (IoT) 기기는 그 일부일 뿐입니다. 공개적으로 노출되는 서버보다 안전한 환경에 있는 것처럼 보일 수 있지만, 이러한 서버는 웹페이지를 프록시로 사용하는 공격자가 악용할 수 있습니다. 예를 들어 악성 웹사이트에는 URL을 삽입할 수 있으며, 이 URL은 피해자가 JavaScript 지원 브라우저에서 볼 때 피해자의 가정용 광대역 라우터에서 DNS 서버 설정을 변경하려고 시도합니다. 이러한 유형의 공격을 'Drive-By Pharming'이라고 하며 2014년에 발생했습니다. DNS 설정을 변경하고 공격자가 사용자를 악성 서버로 리디렉션하도록 허용하여 30만 개 이상의 취약한 무선 라우터가 악용되었습니다.
CORS-RFC1918
유사한 공격의 위협을 완화하기 위해 웹 커뮤니티는 RFC1918에 정의된 비공개 네트워크에 특화된 교차 출처 리소스 공유 (CORS)인 CORS-RFC1918을 도입합니다.
CORS를 구현하는 브라우저는 대상 리소스를 사용하여 다른 출처에서 로드해도 괜찮은지 확인합니다. 이 작업은 복잡도에 따라 액세스를 설명하는 추가 헤더를 인라인으로 사용하거나 실행 전 요청이라는 메커니즘을 사용하여 수행됩니다. 자세한 내용은 교차 출처 리소스 공유를 참조하세요.
CORS-RFC1918을 사용하면 브라우저에서 기본적으로 비공개 네트워크를 통한 리소스 로드를 차단합니다. 단, CORS를 사용하거나 HTTPS를 통해 명시적으로 허용되는 리소스는 제외됩니다. 이러한 리소스에 대해 요청하는 웹사이트는 CORS 헤더를 전송해야 하며 서버는 해당 CORS 헤더로 응답하여 교차 출처 요청을 허용함을 명시적으로 명시해야 합니다. 정확한 CORS 헤더는 아직 개발 중입니다.
이러한 기기 또는 서버의 개발자는 다음 두 가지 조치를 취해야 합니다.
- 비공개 네트워크에 요청하는 웹사이트가 HTTPS를 통해 제공되는지 확인합니다.
- CORS-RFC1918에 대한 서버 지원을 설정하고 예상 HTTP 헤더로 응답합니다.
어떤 종류의 요청이 영향을 받나요?
영향을 받는 요청은 다음과 같습니다.
- 공용 네트워크에서 비공개 네트워크로 요청
- 사설 네트워크에서 로컬 네트워크로 요청
- 공용 네트워크에서 로컬 네트워크로 요청
비공개 네트워크: IPv4에서 RFC1918의 섹션 3에 정의된 비공개 주소 공간으로 확인되는 대상, 매핑된 IPv4 주소 자체가 비공개인 IPv4 매핑 IPv6 주소 또는 ::1/128, 2000::/3, ff00::/8 서브넷 외부의 IPv6 주소입니다.
로컬 네트워크
IPv4의 RFC1122 섹션 3.2.1.3에 정의된 '루프백' 공간(127.0.0.0/8), IPv4의 RFC3927에 정의된 '링크-로컬' 공간(169.254.0.0/16), {.fc00::/7RFC4193fe80::/10RFC4291
공용 네트워크 기타
CORS-RFC1918을 사용 설정하려는 Chrome의 계획
Chrome은 다음 두 단계로 CORS-RFC1918을 가져옵니다.
1단계: HTTPS 웹페이지에서만 비공개 네트워크 리소스에 대한 요청 허용
Chrome 87에는 공개 웹사이트에서 비공개 네트워크 리소스에 대한 요청을 HTTPS를 사용하도록 요구하는 플래그가 추가되었습니다. about://flags#block-insecure-private-network-requests에서 사용 설정할 수 있습니다. 이 플래그를 사용 설정하면 HTTP 웹사이트에서 비공개 네트워크 리소스에 대한 요청이 모두 차단됩니다.
Chrome 88부터 CORS-RFC1918 오류가 콘솔에서 CORS 정책 오류로 보고됩니다.
Chrome DevTools의 네트워크 패널에서 차단된 요청 체크박스를 사용 설정하여 차단된 요청에 집중할 수 있습니다.
Chrome 87에서는 CORS-RFC1918 오류가 DevTools 콘솔에서 대신 ERR_INSECURE_PRIVATE_NETWORK_REQUEST로만 보고됩니다.
이 테스트 웹사이트에서 직접 시험해 볼 수 있습니다.
2단계: 특수 헤더와 함께 프리플라이트 요청 전송
향후 공개 웹사이트가 비공개 또는 로컬 네트워크에서 리소스를 가져오려고 할 때마다 Chrome은 실제 요청 전에 실행 전 요청을 전송합니다.
요청에는 다른 CORS 요청 헤더 외에 Access-Control-Request-Private-Network: true 헤더가 포함됩니다. 무엇보다도 이러한 헤더는 요청을 실행하는 출처를 식별하여 액세스를 세밀하게 제어할 수 있게 해줍니다. 서버는 Access-Control-Allow-Private-Network:
true 헤더로 응답하여 리소스에 대한 액세스 권한을 부여함을 명시적으로 나타낼 수 있습니다.
의견 요청
공개 네트워크의 요청을 기대하는 비공개 네트워크 내에서 웹사이트를 호스팅하는 경우 Chrome팀은 여러분의 의견과 사용 사례에 관심을 가지고 있습니다. 다음과 같은 두 가지 방법이 있습니다.
about://flags#block-insecure-private-network-requests로 이동하여 플래그를 사용 설정하고 웹사이트에서 예상대로 비공개 네트워크 리소스에 요청을 전송하는지 확인합니다.- 문제가 발생하거나 의견이 있으면 crbug.com에서 문제를 신고하고 구성요소를
Blink>SecurityFeature>CORS>RFC1918로 설정하세요.
의견 예시
무선 라우터는 HTTP를 통해 동일한 비공개 네트워크에 관리자 웹사이트를 제공합니다. 관리자 웹사이트를 삽입하는 웹사이트에 HTTPS가 필요한 경우 혼합 콘텐츠가 됩니다. 폐쇄형 네트워크의 관리자 웹사이트에서 HTTPS를 사용 설정해야 하나요?
바로 Chrome이 원하는 피드백 유형입니다. crbug.com에서 구체적인 사용 사례에 관한 문제를 신고해 주세요. Chrome에 의견을 보내주세요.