클라이언트의 내부 네트워크에 있는 기기와 서버가 웹에 의도치 않게 노출되는 것과 관련된 위험을 완화하세요.
비공개 네트워크에서 호스팅되는 기기와 서버에 요청을 보내는 악성 웹사이트는 오랫동안 위협이었습니다. 예를 들어 공격자는 무선 라우터의 구성을 변경하여 Man-in-the-Middle 공격을 사용 설정할 수 있습니다. CORS-RFC1918은 브라우저에서 이러한 요청을 기본적으로 차단하고 내부 기기가 공개 인터넷의 요청을 선택하도록 요구하는 제안입니다.
이 변경사항이 웹 생태계에 미치는 영향을 파악하기 위해 Chrome팀은 비공개 네트워크용 서버를 빌드하는 개발자의 의견을 기다리고 있습니다.
현 상태의 문제점
많은 웹 서버가 비공개 네트워크 내에서 실행됩니다. 무선 라우터, 프린터, 인트라넷 웹사이트, 엔터프라이즈 서비스, 사물 인터넷 (IoT) 기기는 그중 일부에 불과합니다. 이러한 서버는 공개에 노출된 서버보다 더 안전한 환경에 있는 것처럼 보일 수 있지만 웹페이지를 프록시로 사용하는 공격자가 악용할 수 있습니다. 예를 들어 악성 웹사이트는 피해자가 JavaScript 지원 브라우저에서 단순히 볼 때 피해자의 가정용 광대역 라우터에서 DNS 서버 설정을 변경하려고 시도하는 URL을 삽입할 수 있습니다. 이러한 유형의 공격을 "드라이브 바이 파밍"이라고 하며 2014년에 발생했습니다. 30만 개 이상의 취약한 무선 라우터가 DNS 설정을 변경하고 공격자가 사용자를 악성 서버로 리디렉션하도록 허용하여 악용되었습니다.
CORS-RFC1918
유사한 공격의 위협을 완화하기 위해 웹 커뮤니티는 CORS-RFC1918—교차 출처 리소스 공유 (CORS)에 특화된 RFC1918에 정의된 비공개 네트워크를 도입하고 있습니다.
CORS를 구현하는 브라우저는 대상 리소스가 다른 출처에서 로드되어도 괜찮은지 확인합니다. 이는 복잡성에 따라 액세스를 설명하는 추가 헤더를 인라인으로 사용하거나 실행 전 요청이라는 메커니즘을 사용하여 수행됩니다. 자세한 내용은 교차 출처 리소스 공유 를 참고하세요.
CORS-RFC1918을 사용하면 브라우저가 CORS 및 HTTPS를 사용하여 서버에서 명시적으로 허용하는 리소스를 제외하고 기본적으로 비공개 네트워크를 통해 리소스 로드를 차단합니다. 이러한 리소스에 요청을 보내는 웹사이트는 CORS 헤더를 전송해야 하며 서버는 해당하는 CORS 헤더로 응답하여 교차 출처 요청을 수락한다고 명시적으로 명시해야 합니다. (정확한 CORS 헤더는 아직 개발 중입니다.)
이러한 기기 또는 서버의 개발자는 다음 두 가지 작업을 요청받게 됩니다.
- 비공개 네트워크에 요청을 보내는 웹사이트가 HTTPS를 통해 제공되는지 확인합니다.
- CORS-RFC1918에 대한 서버 지원을 설정하고 예상되는 HTTP 헤더로 응답합니다.
어떤 종류의 요청이 영향을 받나요?
영향을 받는 요청은 다음과 같습니다.
- 공개 네트워크에서 비공개 네트워크로의 요청
- 비공개 네트워크에서 로컬 네트워크로의 요청
- 공개 네트워크에서 로컬 네트워크로의 요청
로컬 네트워크
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)로 확인되는 대상입니다.
공개 네트워크 기타 모든 네트워크입니다.
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에서 구체적인 사용 사례로 문제를 신고해 주세요. crbug.com