클라이언트의 내부 네트워크에 있는 기기와 서버가 의도치 않게 웹에 노출되는 것과 관련된 위험을 완화합니다.
비공개 네트워크에 호스팅된 기기와 서버에 요청하는 악성 웹사이트는 오랫동안 위협이 되어 왔습니다. 예를 들어 공격자는 Man-in-the-Middle을 사용 설정하기 위해 무선 라우터의 구성을 변경할 수 있습니다. CORS-RFC1918은 브라우저에서 기본적으로 이러한 요청을 차단하고 내부 기기가 공개 인터넷의 요청을 선택하도록 요구하는 제안입니다.
이 변경사항이 웹 생태계에 미치는 영향을 파악하기 위해 Chrome팀에서는 비공개 네트워크용 서버를 빌드하는 개발자의 의견을 모으고 있습니다.
현상 유지에 어떤 문제가 있나요?
많은 웹 서버가 비공개 네트워크 내에서 실행됩니다. 무선 라우터, 프린터, 인트라넷 웹사이트, 엔터프라이즈 서비스, 사물 인터넷 (IoT) 기기가 그중 일부입니다. 이러한 서버는 공개적으로 노출된 서버보다 더 안전한 환경에 있는 것처럼 보일 수 있지만 웹페이지를 프록시로 사용하는 공격자가 이러한 서버를 악용할 수 있습니다. 예를 들어 악성 웹사이트는 피해자가 JavaScript 지원 브라우저에서 단순히 조회하면 피해자의 홈 브로드밴드 라우터에서 DNS 서버 설정을 변경하려고 시도하는 URL을 삽입할 수 있습니다. 이러한 유형의 공격을 '드라이브 바이 파밍'이라고 하며 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), IPv6의 RFC4193 3절에 정의된 '고유 로컬 주소' 접두사 (fc00::/7) 또는 IPv6의 RFC4291 2.5.6절에 정의된 '링크-로컬' 접두사 (fe80::/10)로 확인되는 대상입니다.
공용 네트워크 기타 모든 네트워크
Chrome의 CORS-RFC1918 사용 설정 계획
Chrome은 CORS-RFC1918을 두 단계로 도입합니다.
1단계: 비공개 네트워크 리소스에 대한 요청은 HTTPS 웹페이지에서만 허용됩니다.
Chrome 87에서는 비공개 네트워크 리소스를 요청하는 공개 웹사이트가 HTTPS를 사용하도록 지정하는 플래그를 추가합니다. about://flags#block-insecure-private-network-requests로 이동하여 사용 설정할 수 있습니다. 이 플래그를 사용 설정하면 HTTP 웹사이트에서 비공개 네트워크 리소스에 대한 모든 요청이 차단됩니다.
Chrome 88부터 CORS-RFC1918 오류가 콘솔에서 CORS 정책 오류로 보고됩니다.
Chrome DevTools의 Network 패널에서 Blocked Requests 체크박스를 사용 설정하여 차단된 요청에 집중할 수 있습니다.
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에서 의견을 기다리고 있습니다.