업데이트
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월: 오리진 트라이얼 설문조사 전송 및 의견 접수됨 지원 중단 체험판이 Chrome 113으로 연장됩니다.
- 2023년 3월: 지원 중단 체험판이 Chrome 116으로 연장되었으며 Chrome 117에서 종료될 예정입니다. Chrome 114의 초기 출시를 타겟팅하는 권한 기반 대체 메커니즘이 개발 중입니다.
- 2023년 5월 (잠정): Chrome 114에서 권한 기반 메커니즘이 출시됩니다. 웹사이트에서 이 API를 사용하여 지원 중단 무료 체험을 종료할 수 있습니다.
- 2023년 9월: Chrome 117이 안정화 버전으로 출시되고 지원 중단 체험판이 종료됩니다. Chrome은 안전하지 않은 공개 컨텍스트의 모든 비공개 네트워크 요청을 차단합니다.
비공개 네트워크 액세스란 무엇인가요?
비공개 네트워크 액세스(이전 명칭: CORS-RFC1918)는 웹사이트가 비공개 네트워크의 서버에 요청을 보내는 기능을 제한합니다. 보안 컨텍스트의 이러한 요청만 허용합니다. 또한 이 사양은 교차 출처 리소스 공유 (CORS) 프로토콜을 확장합니다. 따라서 이제 웹사이트에서 임의의 요청을 전송하기 전에 비공개 네트워크의 서버에 권한 부여를 명시적으로 요청해야 합니다.
비공개 네트워크 요청은 대상 서버의 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로 업그레이드
이 솔루션에는 인트라넷 컨텍스트나 사용자가 제어 중인 DHCP 서버에서 네임서버 주소를 가져오는 경우와 같이 사용자의 DNS 확인을 제어해야 합니다. 또한 공개 도메인 이름이 있어야 합니다.
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과 같은 공개 서버에서 모든 하위 리소스 (예: 스크립트 또는 이미지)를 가져옵니다. 그러면 결과적으로 웹 앱은 동일한 출처로 간주되므로 비공개 서버에 요청할 수 있습니다. localhost가 아닌 비공개 IP로 다른 서버에 요청할 수도 있지만 장기적으로는 변경될 수 있습니다.
비공개 서버에서 스켈레톤만 호스팅하면 공개 웹 앱을 업데이트하는 것처럼 새 리소스를 공개 서버에 푸시하여 웹 앱을 업데이트할 수 있습니다. 반면에 결과 웹 앱은 보안 컨텍스트가 아니므로 웹의 강력한 일부 기능에 액세스할 수 없습니다.
미래를 위한 계획
비공개 네트워크 요청을 안전한 컨텍스트로 제한하는 것은 비공개 네트워크 액세스를 시작하는 첫 번째 단계일 뿐입니다. Chrome은 향후 몇 달 안에 나머지 사양을 구현하기 위해 노력하고 있습니다 새로운 소식을 기대해 주세요.
비공개 웹사이트에서 localhost 액세스 제한
Chrome 94의 변경사항은 비공개 IP 주소 또는 localhost에 액세스하는 공개 웹사이트에만 영향을 미칩니다. 또한 비공개 네트워크 액세스 사양은 localhost에 대한 비공개 웹사이트의 요청을 문제가 있는 것으로 분류합니다. Chrome에서는 최종적으로 이들 역시 지원 중단될 예정입니다. 하지만 도메인 이름이 없는 비공개 웹사이트가 많아 지원 중단 체험판 토큰을 사용하기가 까다롭기 때문에 약간 다른 문제가 발생합니다.
CORS 프리플라이트 요청
비공개 네트워크 액세스의 두 번째 부분은 CORS 실행 전 요청을 사용하여 보안 컨텍스트에서 시작된 비공개 네트워크 요청을 제어하는 것입니다. 요청이 보안 컨텍스트에서 시작된 경우에도 대상 서버에 시작자에게 명시적인 권한을 제공하도록 요청한다는 개념입니다. 요청은 권한 부여에 성공한 경우에만 전송됩니다.
간단히 말해 CORS 프리플라이트 요청은 후속 요청의 특성을 나타내는 Access-Control-Request-* 헤더를 전달하는 HTTP OPTIONS 요청입니다. 그러면 서버는 Access-Control-Allow-* 헤더로 200 OK에 응답하여 세분화된 액세스 권한을 부여할지 결정할 수 있습니다.
자세한 내용은 사양을 참조하세요.
탐색 가져오기 제한
Chrome에서는 비공개 네트워크에 대한 하위 리소스 요청을 지원 중단하고 최종적으로 차단합니다. 이는 CSRF 공격에도 사용될 수 있는 비공개 네트워크 탐색에는 영향을 미치지 않습니다.
비공개 네트워크 액세스 사양은 두 종류의 가져오기를 구분하지 않으며, 결과적으로 동일한 제한사항이 적용됩니다.