이 페이지는 Cloud Translation API를 통해 번역되었습니다.

비공개 네트워크 액세스: 프리플라이트 도입

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

업데이트

2022년 7월 7일: 현재 상태가 업데이트되고 IP 주소 공간 정의가 추가되었습니다.
2022년 4월 27일: 타임라인 공지가 업데이트되었습니다.
2022년 3월 7일: Chrome 98

소개

Chrome은 공용에서 비공개 네트워크 엔드포인트에 대한 직접 액세스를 지원 중단합니다 Google Ad Manager에 비공개 네트워크 액세스 (PNA) 지정할 수도 있습니다

Chrome은 하위 리소스의 비공개 네트워크 요청에 앞서 CORS 프리플라이트 요청을 명시적 권한을 요청합니다. 이 프리플라이트 요청은 새 헤더 Access-Control-Request-Private-Network: true를 포함하며 응답에는 상응하는 헤더가 있어야 하는데 Access-Control-Allow-Private-Network: true

목표는 교차 사이트 요청 위조 (CSRF) 공격으로부터 사용자를 보호하는 것입니다. 개인 네트워크의 라우터 및 다른 장치를 표적으로 삼습니다. 이러한 공격은 수십만 명의 사용자에게 영향을 미쳤습니다. 공격자가 악성 서버로 리디렉션할 수 있습니다.

출시 계획

Chrome은 이 변경사항을 2단계에 걸쳐 출시할 예정입니다. 이는 웹사이트가 이를 인지할 수 있도록 합니다. 적절하게 조정합니다.

Chrome 104의 경우:
- 비공개 네트워크에 앞서 프리플라이트 요청을 전송하여 Chrome 실험 하위 리소스 요청을 지원합니다
- 프리플라이트 실패는 달리 없이 DevTools에 경고만 표시합니다. 비공개 네트워크 요청에 영향을 미칩니다.
- Chrome은 호환성 데이터를 수집하여 영향을 받는 가장 큰 있습니다.
- 이 기능은 기존 웹사이트와 광범위하게 호환됩니다.
를 통해 개인정보처리방침을 정의할 수 있습니다.
경고: 프리플라이트를 아직 지원하지 않는 웹사이트에 미치는 영향을 제한하려면 Chrome 104에서는 시간 제한이 200밀리초로 제한됩니다. 이 제한은 적용됩니다. 특별 제한 시간 제한은 '비공개 네트워크의 결과를 존중'으로 전환하여 프리플라이트에 액세스 '사용 설정됨'으로 변경 chrome://flags이며 기본 한도는 5입니다. 합니다
빠르면 Chrome 113에서:
- 이는 호환성 데이터에 안전하며 필요한 경우 Google에서 직접 연락했습니다.
- Chrome은 프리플라이트 요청이 성공해야 하고, 그렇지 않으면 실패하도록 강제합니다. 요청을 처리합니다
- 지원 중단 기능 트라이얼이 시작되는 날짜: 동시에 이 단계의 영향을 받는 웹사이트가 시간 연장입니다. 무료 체험은 6개월 이상 지속됩니다.

를 통해 개인정보처리방침을 정의할 수 있습니다.

비공개 네트워크 액세스 (PNA)란 무엇인가요?

비공개 네트워크 액세스 (이전 명칭: CORS-RFC1918) 웹사이트가 비공개 서버에 요청을 보내는 기능을 제한합니다. 네트워크

Chrome에는 일부 사양이 이미 구현되어 있습니다. Chrome 96부터 비공개 네트워크 요청을 할 수 있습니다. 자세한 내용은 이전 블로그 게시물을 참조하세요.

이 사양은 교차 출처 리소스 공유 (CORS)도 확장합니다. 이제 웹사이트가 서버에서 명시적으로 권한 부여를 요청해야 합니다. 비공개 네트워크에서 임의의 요청을 전송할 수 있어야 합니다.

핵심 용어: 비공개 네트워크 요청은 대상 서버의 IP 주소가 요청 개시자를 가져온 것보다 더 비공개입니다. 예를 들어 공개 웹사이트 (https://example.com)에서 비공개 웹사이트로의 요청 (http://router.local) 또는 비공개 웹사이트에서 로컬 호스트로의 요청을 보낼 수 있습니다.

PNA는 어떻게 IP 주소를 분류하고 비공개 네트워크를 식별하나요?

IP 주소는 세 가지 IP 주소 공간으로 분류됩니다. - public - private - local

로컬 IP 주소 공간에는 IPv4인 IP 주소가 포함됩니다. RFC1122의 섹션 3.2.1.3에 정의된 루프백 주소 (127.0.0.0/8) 또는 RFC4291의 섹션 2.5.3에 정의된 IPv6 루프백 주소 (::1/128)를 사용합니다.

비공개 IP 주소 공간에는 현재 네트워크 내(10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16는 RFC1918에 정의되어 있습니다. RFC3927에 정의된 링크-로컬 주소 169.254.0.0/16 RFC4193에 정의된 고유한 로컬 IPv6 유니캐스트 주소fc00::/7 RFC4291의 섹션 2.5.6에 정의된 링크 로컬 IPv6 유니캐스트 주소fe80::/10 매핑된 IPv4 주소 자체가 비공개인 IPv4 매핑 IPv6 주소입니다.

공개 IP 주소 공간에는 이전에 언급되지 않은 다른 모든 주소가 포함됩니다.

로컬 IP 주소는 비공개 IP 주소보다 더 비공개인 것으로 공개 IP 주소보다 더 비공개인 것으로 간주됩니다.

가용성이 더 높은 네트워크에서
덜 사용할 수 있습니다. — </ph> 사설 네트워크의 공개, 비공개, 로컬 네트워크 간의 관계 액세스 (CORS-RFC1918)

자세한 내용은 의견 요청: 비공개 네트워크용 CORS (RFC1918)를 참고하세요.

프리플라이트 요청

배경

프리플라이트 요청은 사용되는 교차 출처 리소스 공유 (CORS) 표준에서 도입된 메커니즘입니다. HTTP 요청을 보내기 전에 대상 웹사이트에서 권한을 요청 부작용이 있을 수 있습니다 이렇게 하면 대상 서버가 CORS 프로토콜을 사용하여 CSRF 공격의 위험을 크게 줄일 수 있습니다.

권한 요청은 특정 CORS 요청 헤더와 함께 OPTIONS HTTP 요청으로 전송됩니다. HTTP 요청을 설명합니다 응답에는 특정 CORS 응답 헤더가 있어야 합니다. 향후 요청에 명시적으로 동의하는 것으로 간주됩니다.

CORS 프리플라이트를 나타내는 시퀀스 다이어그램 OPTIONS HTTP
요청이 대상으로 전송되고, 이는 200 OK를 반환합니다. 그런 다음 CORS는
요청 헤더가 전송되어 CORS 응답 헤더를 반환합니다.

비공개 네트워크 액세스의 새로운 기능

프리플라이트 요청에 새로운 요청 및 응답 헤더 쌍이 도입되었습니다.

모든 PNA 프리플라이트 요청에 Access-Control-Request-Private-Network: true가 설정됨
모든 PNA 프리플라이트 응답에 Access-Control-Allow-Private-Network: true을(를) 설정해야 합니다.

PNA에 대한 프리플라이트 요청은 모든 비공개 네트워크 요청에 대해 전송됩니다. 요청 메서드 및 모드를 지정합니다. 포드는 cors 모드, no-cors 및 다른 모든 모드에서의 요청보다 앞서고 있습니다. 이 모든 비공개 네트워크 요청이 CSRF 공격에 사용될 수 있기 때문에 요청 모드 및 응답 콘텐츠가 작성되었는지 여부와 상관없이 사용할 수 있게 됩니다

참고: 비공개 네트워크 요청이 cors 모드에서 이루어지면 CORS 헤더는 프리플라이트 응답 외에도 최종 응답에 설정됩니다.

PNA에 대한 프리플라이트 요청도 동일한 출처 요청에 대해 대상 IP 주소가 개시자보다 비공개입니다. 이는 일반적인 CORS: 프리플라이트 요청이 교차 출처 요청 전용임 프리플라이트 동일 출처 요청에 대한 요청은 DNS 리바인딩 공격.

예

관찰 가능한 동작은 요청 모드입니다.

CORS 없음 모드

임베딩 https://foo.example/index.html개 말하기 <img src="https://bar.example/cat.gif" alt="dancing cat"/>, bar.example는 다음에 따른 비공개 IP 주소인 192.168.1.1로 확인됩니다. RFC 1918

Chrome은 먼저 프리플라이트 요청을 보냅니다.

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

이 요청이 성공하려면 서버가 다음과 같이 응답해야 합니다.

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

경고: 서버에서 Access-Control-Allow-Origin: *를 설정할 수 있지만 이는 위험합니다. 이는 권장되지 않습니다. 모든 조직 구성원이 비공개 네트워크 리소스에 따라서 이러한 헤더를 설정할 때 수반되는 위험에 대해 신중하게 생각해야 합니다.

그러면 Chrome에서 실제 요청을 보냅니다.

HTTP/1.1 GET /cat.gif
...

서버가 정상적으로 응답할 수 있습니다.

CORS 모드

https://foo.example/index.html가 다음 코드를 실행한다고 가정해 보겠습니다.

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

다시 말하지만 bar.example가 192.168.1.1로 확인된다고 가정해 보겠습니다.

Chrome은 먼저 프리플라이트 요청을 보냅니다.

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

이 요청이 성공하려면 서버가 다음과 같이 응답해야 합니다.

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

그러면 Chrome에서 실제 요청을 보냅니다.

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

서버가 일반적인 CORS 규칙에 따라 응답할 수 있는 대상은 다음과 같습니다.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

웹사이트가 영향을 받는지 확인하는 방법

Chrome 104부터 비공개 네트워크 요청이 감지되면 프리플라이트가 요청이 미리 전송됩니다 이 프리플라이트 요청이 실패하면 요청은 계속 전송되지만 DevTools에 경고가 표시됨 문제 패널

Devtools 문제 패널에서 프리플라이트 요청 실패 경고가 표시됨 다음과 같이 명시됩니다.
비공개 네트워크 요청이 이를 허용하는 리소스에만 이루어지도록 하고,
특정 요청 및 영향을 받는 리소스에 대한 세부정보와 함께 표시됩니다.

영향을 받는 프리플라이트 요청도 네트워크 패널에서 확인하고 진단할 수 있습니다.

DevTools Network 패널에서 localhost에 대한 실행 전 요청 실패
501 상태가 표시됩니다.

요청이 구성 없이 일반 CORS 프리플라이트를 트리거했다면 비공개 네트워크 액세스 규칙의 경우 두 개의 프리플라이트가 첫 번째 패널은 항상 실패한 것으로 보입니다. 이것은 알려진 버그이므로 무시해도 됩니다.

프리플라이트가 성공적으로 실행되기 전에, 가짜 프리플라이트 요청이 실패하여
DevTools Network 패널

프리플라이트가 성공적으로 적용된 경우 어떻게 되는지 검토하려면 다음을 수행합니다. 다음 명령줄 인수를 전달합니다. Chrome 98부터:

--enable-features=PrivateNetworkAccessRespectPreflightResults

프리플라이트 요청이 실패하면 가져오기가 실패합니다. 이렇게 하면 웹사이트가 정상적으로 작동하는지 출시 계획의 두 번째 단계에 해당합니다. 오류 진단: 경고와 같은 방식으로 경고를 표시합니다.

웹사이트가 영향을 받는 경우 취해야 할 조치

이 변경사항이 Chrome 104에 출시되어도 있습니다. 하지만 영향을 받는 요청 경로를 웹사이트가 정상적으로 운영되는지 확인하세요

다음과 같은 두 가지 솔루션을 사용하실 수 있습니다.

서버 측에서 프리플라이트 요청 처리
엔터프라이즈 정책으로 PNA 검사 사용 중지

서버 측에서 프리플라이트 요청 처리

영향을 받은 모든 가져오기의 대상 서버를 업데이트하여 PNA 프리플라이트 처리 있습니다 먼저, 기본 인프라에서 표준 CORS 프리플라이트 요청에 대한 경로를 보여줍니다. 그런 다음 새로운 응답 헤더 두 개에 대한 지원을 추가합니다.

서버가 프리플라이트 요청 (CORS가 포함된 OPTIONS 요청)을 수신하는 경우 헤더)가 포함된 경우, 서버는 Access-Control-Request-Private-Network: true 헤더. 이 헤더가 서버에서 Origin 헤더를 검사하고 기타 관련 정보 (예: Access-Control-Request-Headers)를 사용하여 요청이 허용해도 안전한지 확인합니다. 일반적으로 사용자가 제어하는 단일 출처에 대한 액세스를 허용해야 합니다.

서버가 요청을 허용하기로 결정하면 필요한 CORS 헤더 및 새 PNA가 있는 204 No Content (또는 200 OK) 헤더를 클릭하세요. 이러한 헤더에는 Access-Control-Allow-Origin 및 Access-Control-Allow-Private-Network: true 등의 기타 필요한 메서드를 지원합니다.

구체적인 시나리오는 예시를 참고하세요.

엔터프라이즈 정책을 사용하여 비공개 네트워크 액세스 검사 사용 중지

사용자에 대한 관리 권한이 있는 경우 비공개 기능을 사용 중지할 수 있습니다. 다음 정책 중 하나를 사용하여 네트워크 액세스를 확인합니다.

자세한 내용은 Chrome 정책 관리 이해하기를 참고하세요.

의견 보내기

다음과 같은 요청이 예상되는 비공개 네트워크 내에서 웹사이트를 호스팅하는 경우 Chrome팀은 여러분의 의견과 사용 사례에 관심이 있습니다. crbug.com에서 Chromium 관련 문제를 신고하고 다음과 같이 설정하세요. 구성요소를 Blink>SecurityFeature>CORS>PrivateNetworkAccess로 설정합니다.

다음 단계

다음으로 Chrome은 비공개 네트워크 액세스 검사를 확장하여 웹 작업자: 공유 작업자, 서비스 워커로 구분됩니다 잠정적으로 Chrome 107이 경고를 표시하기 시작합니다.

그런 다음 Chrome은 비공개 네트워크 액세스 검사를 확장하여 탐색, iframe과 팝업이 포함됩니다. 잠정적으로 Chrome 108을 시작하는 것을 목표로 하고 있습니다. 있습니다.

두 경우 모두 유사한 단계적 출시를 신중하게 진행하겠습니다. 이는 웹 개발자가 호환성 위험을 조정하고 추정할 시간을 제공하기 위해서입니다.

감사의 말씀

Mark Olsen의 표지 사진: 스플래시 해제.