업데이트
2023년 3월 23일: 타임라인이 업데이트되었으며 Chrome 117이 될 때까지 지원 중단되지 않습니다.
2023년 1월 19일: 타임라인이 업데이트되었으며 Chrome 114까지는 지원 중단되지 않습니다.
2022년 8월 12일: 타임라인이 업데이트되었으며 Chrome 109까지는 지원 중단되지 않습니다.
2022년 2월 10일: 프라이빗 네트워크 액세스: 사전 비행 소개에 업데이트된 도움말이 게시되었습니다.
2021년 8월 25일: 지원 중단 체험판의 일정 공지 및 소개를 업데이트했습니다.
Chrome은 비공개 네트워크 액세스 사양의 일환으로 안전하지 않은 웹사이트에서 비공개 네트워크 엔드포인트에 액세스하는 기능을 지원 중단합니다. 이는 비공개 네트워크의 라우터 및 기타 기기를 타겟팅하는 크로스 사이트 요청 위조 (CSRF) 공격으로부터 사용자를 보호하기 위한 조치입니다. 이러한 공격으로 수십만 명의 사용자가 영향을 받았으며 공격자가 사용자를 악성 서버로 리디렉션할 수 있었습니다.
Chrome에는 다음과 같은 변경사항이 적용됩니다.
- Chrome 94부터 안전하지 않은 공개 웹사이트에서 비공개 네트워크에 대한 요청을 차단합니다.
- Chrome에서 종료될 지원 중단 기능 트라이얼을 소개합니다.
- 이를 통해 개발자는 선택한 출처의 시간 연장을 요청할 수 있으며, 지원 중단 기능 트라이얼 기간에는 영향을 받지 않습니다.
- 관리 Chrome 배포에서 지원 중단을 영구적으로 우회할 수 있는 Chrome 정책을 도입합니다. Chrome 92에서 사용할 수 있습니다.
지원 중단의 영향을 완화하는 데 더 많은 시간이 필요한 경우 지원 중단 체험판을 등록합니다.
사용자에 대한 관리 권한이 있는 경우 Chrome 정책을 사용하여 이 기능을 다시 사용 설정할 수 있습니다.
새로운 제한의 영향을 완화하려면 다음 전략 중 하나를 사용하세요.
- 웹사이트를 HTTPS로 업그레이드하고 필요한 경우 대상 서버를 업그레이드합니다.
- 웹사이트를 HTTPS로 업그레이드하고 WebTransport 사용
- 삽입 관계를 역순으로 변경합니다.
타임라인
- 2020년 11월: 예정된 변경사항에 관한 의견을 요청하세요.
- 2021년 3월: 의견을 검토하고 연락을 취한 후 예정된 변경사항이 발표되었습니다. 사양의 이름이 CORS-RFC1918에서 비공개 네트워크 액세스로 변경되었습니다.
- 2021년 4월: Chrome 90이 안정화 버전에 출시되어 지원 중단 경고가 표시됩니다.
- 2021년 6월: 안전하지 않은 컨텍스트에서 비공개 네트워크 요청을 금지하는 Chrome 92가 베타 버전으로 출시되었습니다. 조정 기한 연장을 요청하는 개발자의 피드백에 따라 지원 중단은 Chrome 93으로 연기되고 지원 중단 체험판이 함께 제공됩니다.
- 2021년 7월: 개발자의 추가 의견 이후 지원 중단 및 함께 제공되는 체험판은 Chrome 94로 연기됩니다. 또한 비공개 웹사이트는 더 이상 지원 중단의 영향을 받지 않습니다.
- 2021년 8월: Chrome 94가 베타로 출시됩니다. 웹 개발자는 지원 중단 체험판 가입을 시작할 수 있습니다.
- 2021년 9월: Chrome 94가 안정화 버전으로 출시되었습니다. 웹 개발자는 지원 중단 체험판에 가입하고 프로덕션에 체험판 토큰을 배포해야 합니다.
- 2022년 12월: Origin 무료 체험판 설문조사를 보내고 의견을 받았습니다. 지원 중단 기능 트라이얼이 Chrome 113으로 연장됩니다.
- 2023년 3월: 지원 중단 기능 트라이얼이 Chrome 116으로 연장되고 Chrome 117에서 종료되도록 설정됩니다. Chrome 114의 초기 출시를 타겟팅하는 권한 기반 대체 메커니즘이 개발 중입니다.
- 2023년 5월 (예정): Chrome 114에서 권한 기반 메커니즘이 출시됩니다. 웹사이트에서 이를 사용하여 지원 중단 체험판을 종료할 수 있습니다.
- 2023년 9월: Chrome 117이 안정화 버전으로 출시되어 지원 중단 체험이 종료됩니다. Chrome은 안전하지 않은 공개 컨텍스트의 모든 비공개 네트워크 요청을 차단합니다.
비공개 네트워크 액세스란 무엇인가요?
비공개 네트워크 액세스(이전의 CORS-RFC1918)는 비공개 네트워크의 서버에 요청을 보내는 웹사이트의 기능을 제한합니다. 이러한 요청은 안전한 컨텍스트에서만 허용됩니다. 또한 이 사양은 교차 출처 리소스 공유 (CORS) 프로토콜을 확장하여 이제 웹사이트가 임의의 요청을 전송할 수 있게 되기 전에 비공개 네트워크의 서버에서 명시적으로 권한 부여를 요청해야 합니다.
비공개 네트워크 요청은 요청 시작자가 가져온 IP 주소보다 대상 서버의 IP 주소가 더 비공개인 요청입니다. 예를 들어 공개 웹사이트 (https://example.com)에서 비공개 웹사이트(http://router.local)로의 요청 또는 비공개 웹사이트에서 localhost로의 요청이 여기에 해당합니다.
의견 보내기: 사설 네트워크의 CORS (RFC1918)에서 자세히 알아보세요.
지원 중단 기능 트라이얼이란 무엇인가요?
지원 중단 트라이얼 (이전 명칭: 역 오리진 트라이얼)은 웹 기능의 지원 중단을 완화하는 데 사용되는 오리진 트라이얼의 한 형태입니다. 지원 중단 체험판을 통해 Chrome은 특정 웹 기능을 지원 중단하고 웹사이트에서 새로운 종속 항목을 형성하지 못하게 하는 동시에 기존의 종속 웹사이트에 이전할 시간을 추가로 제공할 수 있습니다.
지원 중단 기능 트라이얼 기간에는 기본적으로 모든 웹사이트에서 지원 중단된 기능을 사용할 수 없습니다. 영향을 받는 기능을 계속 사용해야 하는 개발자는 지원 중단 체험판에 가입하고 지정된 웹 출처의 토큰을 획득한 후 HTTP 헤더 또는 메타 태그에 이러한 토큰을 제공하도록 웹사이트를 수정해야 합니다(이 경우 제외). 웹사이트가 출처와 일치하는 유효한 토큰을 제공하는 경우 Chrome에서는 지원 중단된 기능을 제한된 기간 동안 사용할 수 있도록 허용합니다.
자세한 내용은 Chrome의 오리진 트라이얼 시작하기 및 오리진 트라이얼에 관한 웹 개발자 가이드를 참고하세요.
Chrome의 변경사항
Chrome 94
Chrome 94부터 비공개 비보안 컨텍스트 (대략적으로 HTTPS를 통해 제공되지 않거나 비공개 IP 주소에서 제공되지 않는 웹사이트)는 비공개 네트워크에 요청하는 것이 금지됩니다. 이전에는 Chrome 92에서 지원 중단될 예정이었으므로 지원 중단 메시지에 이전 마일스톤이 언급될 수 있습니다.
이 지원 중단에는 지원 중단 체험판이 함께 제공되므로 웹사이트에서 지원 중단된 기능을 사용하는 웹 개발자는 토큰을 등록하여 Chrome 116까지 계속 사용할 수 있습니다. 웹사이트에서 무료 체험판을 등록하고 사용 설정하는 방법은 아래를 참고하세요.
한 쌍의 Chrome 정책을 활용하여 지원 중단을 완전히 또는 특정 출처에서 무기한으로 사용 중지할 수 있습니다. 이렇게 하면 기업 설정의 관리 Chrome 설치와 같이 중단이 발생하지 않습니다.
Chrome 117
지원 중단 체험이 종료됩니다. 모든 웹사이트를 지원 중단된 기능에서 이전하거나 기능을 계속 사용 설정하도록 사용자 정책을 구성해야 합니다.
권장 개발자 조치
영향을 받는 웹사이트의 첫 번째 단계는 지원 중단 체험판에 등록하거나 정책을 사용하여 적절한 수정사항을 배포할 때까지 시간을 벌는 것입니다. 그런 다음 권장되는 조치는 영향을 받는 각 웹사이트의 상황에 따라 다릅니다.
지원 중단 체험판 등록
- 비보안 컨텍스트 오리진 트라이얼의 비공개 네트워크 액세스에 대해 등록을 클릭하여 참여 오리진의 체험판 토큰을 가져옵니다.
- 응답 헤더에 출처별
Origin-Trial: $token를 추가합니다. 이 응답 헤더는 결과 문서에서 지원 중단된 기능을 사용하는 경우에만 기본 리소스 및 탐색 응답에 설정하면 됩니다. 이 헤더를 하위 리소스 응답에 연결하는 것은 무해하지만 쓸모가 없습니다.
문서에서 요청을 실행할 수 있기 전에 이 무료 체험을 사용 설정하거나 사용 중지해야 하므로 <meta> 태그를 통해 사용 설정할 수 없습니다. 이러한 태그는 하위 리소스 요청이 실행된 후에만 응답 본문에서 파싱됩니다. 이는 서드 파티에서 제공하는 github.io 정적 웹사이트와 같이 응답 헤더를 제어할 수 없는 웹사이트에 문제가 됩니다.
자세한 내용은 오리진 트라이얼 웹 개발자 가이드를 참고하세요.
정책 사용 설정
사용자에 대한 관리 권한이 있는 경우 다음 정책 중 하나를 사용하여 지원 중단된 기능을 다시 사용 설정할 수 있습니다.
사용자 정책 관리에 대한 자세한 내용은 고객센터 도움말을 참조하세요.
localhost 액세스
웹사이트에서 localhost에 요청을 보내야 하는 경우 웹사이트를 HTTPS로 업그레이드하기만 하면 됩니다.
http://localhost (또는 http://127.*.*.*, http://[::1])를 타겟팅하는 요청은 안전한 컨텍스트에서 실행되더라도 혼합 콘텐츠에 의해 차단되지 않습니다.
WebKit 엔진 및 이를 기반으로 하는 브라우저 (특히 Safari)는 여기에 나온 W3C 혼합 콘텐츠 사양에서 벗어나 이러한 요청을 혼합 콘텐츠로 금지합니다. 또한 비공개 네트워크 액세스를 구현하지 않으므로 웹사이트에서 이러한 브라우저를 사용하는 클라이언트를 일반 텍스트 HTTP 버전의 웹사이트로 리디렉션하려고 할 수 있습니다. 이러한 브라우저에서는 여전히 localhost에 요청을 보낼 수 있습니다.
비공개 IP 주소 액세스
웹사이트에서 비공개 IP 주소의 대상 서버에 요청을 보내야 하는 경우, 단순히 이니시에이터 웹사이트를 HTTPS로 업그레이드하는 것만으로는 작동하지 않습니다. 혼합 콘텐츠는 보안 컨텍스트가 일반 텍스트 HTTP를 통해 요청하는 것을 방지하므로 새로 보안이 적용된 웹사이트는 여전히 요청을 수행할 수 없습니다. 이 문제를 해결하는 방법에는 몇 가지가 있습니다.
- 양쪽 모두 HTTPS로 업그레이드합니다.
- WebTransport를 사용하여 대상 서버에 안전하게 연결합니다.
- 삽입 관계를 역전시킵니다.
양쪽 모두 HTTPS로 업그레이드
이 솔루션을 사용하려면 사용자의 DNS 확인을 제어해야 합니다. 예를 들어 인트라넷 컨텍스트에서 또는 사용자가 관리하는 DHCP 서버에서 네임서버 주소를 가져오는 경우와 같이 제어해야 합니다. 또한 공개 도메인 이름이 있어야 합니다.
HTTPS를 통해 비공개 웹사이트를 제공할 때 발생하는 주된 문제는 공개 키 인프라 인증 기관 (PKI CA)이 공개 도메인 이름을 사용하는 웹사이트에만 TLS 인증서를 제공한다는 것입니다. 이 문제를 해결하려면 다음 안내를 따르세요.
- 공개 도메인 이름 (예:
intranet.example)을 등록하고 해당 도메인 이름을 선택한 공개 서버로 가리키는 DNS 레코드를 게시합니다. intranet.example의 TLS 인증서를 가져옵니다.- 비공개 네트워크 내에서
intranet.example를 대상 서버의 비공개 IP 주소로 확인하도록 DNS를 구성합니다. intranet.example에 TLS 인증서를 사용하도록 비공개 서버를 구성합니다. 이렇게 하면 사용자가https://intranet.example의 비공개 서버에 액세스할 수 있습니다.
그런 다음 요청을 시작하는 웹사이트를 HTTPS로 업그레이드하고 이전과 같이 요청을 계속할 수 있습니다.
이 솔루션은 미래에 대비하고 네트워크에 대한 신뢰를 줄여 비공개 네트워크 내에서 엔드 투 엔드 암호화를 확장합니다.
WebTransport
이 솔루션은 사용자의 DNS 확인을 제어할 필요가 없습니다. 대상 서버에서 최소 WebTransport 서버 (약간의 수정사항이 적용된 HTTP/3 서버)를 실행해야 합니다.
WebTransport 및 인증서 고정 메커니즘을 사용하여 신뢰할 수 있는 CA가 서명한 유효한 TLS 인증서가 없는 문제를 우회할 수 있습니다. 이렇게 하면 자가 서명된 인증서가 있을 수 있는 비공개 기기에 안전하게 연결할 수 있습니다. WebTransport 연결은 양방향 데이터 전송을 허용하지만 가져오기 요청은 허용하지 않습니다. 이 접근 방식과 서비스 워커를 결합하면 웹 애플리케이션의 관점에서 연결을 통해 HTTP 요청을 투명하게 프록시 처리할 수 있습니다. 서버 측에서 상응하는 번역 레이어가 WebTransport 메시지를 HTTP 요청으로 변환할 수 있습니다.
이 작업에는 상당한 작업이 소요됨을 잘 알고 있지만 WebRTC를 기반으로 빌드하는 것보다 훨씬 쉬울 것입니다. 또한 필요한 투자 중 일부를 재사용 가능한 라이브러리로 구현할 수 있기를 바랍니다. 또한 시간이 지남에 따라 플랫폼에서 HTTPS 사용을 더 적극적으로 장려하는 방향으로 나아가고 있으므로 안전하지 않은 컨텍스트는 점점 더 많은 웹 플랫폼 기능에 액세스하지 못하게 될 가능성이 높다는 점을 고려할 때 특히 유용합니다. 비공개 네트워크 액세스에 관계없이, 이는 어쨌든 현명한 투자일 수 있습니다.
HTTP/3을 통한 WebTransport는 Chrome 96 (출처 트라이얼이 시작됨)에서 다음을 비롯한 키 공유 및 기타 수준 미달 보안 관행으로부터 보호하기 위한 완화 조치와 함께 제공될 예정입니다.
- 고정된 인증서의 짧은 최대 만료 시간입니다.
- 악용된 특정 키를 취소하기 위한 브라우저별 메커니즘입니다.
WebTransport가 완전히 출시된 후 최소 2개의 마일스톤이 될 때까지 보안 컨텍스트 제한을 제공하지 않습니다. 필요한 경우 지원 중단 기능 트라이얼이 연장됩니다.
역임베딩
이 솔루션은 네트워크에 대한 관리 제어가 필요하지 않으며 타겟 서버가 HTTPS를 실행하기에 충분히 강력하지 않은 경우에 사용할 수 있습니다.
공개 웹 앱에서 비공개 하위 리소스를 가져오는 대신 비공개 서버에서 앱의 스켈레톤을 제공할 수 있습니다. 그러면 비공개 서버에서 CDN과 같은 공개 서버에서 모든 하위 리소스 (예: 스크립트 또는 이미지)를 가져옵니다. 그러면 결과 웹 앱은 동일 출처로 간주되므로 비공개 서버에 요청할 수 있습니다. 비공개 IP 주소 (localhost 제외)를 사용하여 다른 서버에 요청할 수도 있지만 이는 장기적으로 변경될 수 있습니다.
비공개 서버에서 스켈레톤만 호스팅하면 공개 웹 앱을 업데이트하는 것처럼 새 리소스를 공개 서버에 푸시하여 웹 앱을 업데이트할 수 있습니다. 반면에 결과 웹 앱은 안전한 컨텍스트가 아니므로 웹의 더 강력한 기능 중 일부에 액세스할 수 없습니다.
미래를 위한 계획
비공개 네트워크 요청을 보안 컨텍스트로 제한하는 것은 비공개 네트워크 액세스를 시작하는 첫 번째 단계에 불과합니다. Chrome은 향후 몇 개월 내에 나머지 사양을 구현하기 위해 노력하고 있습니다. 최신 소식을 계속해서 확인해 주시기 바랍니다.
비공개 웹사이트에서 localhost 액세스 제한
Chrome 94의 변경사항은 비공개 IP 주소 또는 localhost에 액세스하는 공개 웹사이트에만 영향을 미칩니다. 비공개 네트워크 액세스 사양은 비공개 웹사이트에서 localhost로 전송되는 요청도 문제가 있는 것으로 분류합니다. Chrome에서는 이러한 쿠키도 결국 지원 중단될 예정입니다. 하지만 많은 비공개 웹사이트에는 도메인 이름이 없으므로 지원 중단 체험판 토큰을 사용하는 것이 복잡해집니다.
CORS 프리플라이트 요청
비공개 네트워크 액세스의 두 번째 부분은 CORS 프리플라이트 요청을 사용하여 안전한 컨텍스트에서 시작된 비공개 네트워크 요청을 게이트하는 것입니다. 요청이 보안 컨텍스트에서 시작된 경우에도 대상 서버는 시작자에 명시적인 부여를 제공하도록 요청받습니다. 요청은 부여가 성공한 경우에만 전송됩니다.
간단히 말해 CORS 실행 전 요청은 후속 요청의 특성을 나타내는 일부 Access-Control-Request-* 헤더를 포함하는 HTTP OPTIONS 요청입니다. 그러면 서버는 Access-Control-Allow-* 헤더로 200 OK에 응답하여 세분화된 액세스 권한을 부여할지 여부를 결정할 수 있습니다.
자세한 내용은 사양을 참고하세요.
탐색 가져오기 제한
Chrome에서는 비공개 네트워크에 대한 하위 리소스 요청을 지원 중단하고 결국 차단할 예정입니다. 이는 비공개 네트워크 탐색에는 영향을 미치지 않으며, 비공개 네트워크는 CSRF 공격에도 사용될 수 있습니다.
비공개 네트워크 액세스 사양은 두 가지 가져오기 유형을 구분하지 않으며, 결국 동일한 제한사항이 적용됩니다.