캐시를 파티셔닝하여 보안 및 개인 정보 보호 확보

Eiji Kitamura

일반적으로 캐싱은 데이터를 저장하여 향후 동일한 데이터에 대한 요청이 더 빠르게 처리되도록 하여 성능을 개선할 수 있습니다. 예를 들어 네트워크의 캐시된 리소스는 서버 왕복을 방지할 수 있습니다. 캐시된 계산 결과는 동일한 계산을 실행하는 데 걸리는 시간을 생략할 수 있습니다.

Chrome에서는 캐시 메커니즘이 다양한 방식으로 사용되며 HTTP 캐시가 그중 하나입니다.

현재 Chrome의 HTTP 캐시 작동 방식

버전 85부터 Chrome은 각 리소스 URL을 캐시 키로 사용하여 네트워크에서 가져온 리소스를 캐시합니다. 캐시 키는 캐시된 리소스를 식별하는 데 사용됩니다.

다음 예는 단일 이미지가 세 가지 서로 다른 컨텍스트에서 캐시되고 처리되는 방식을 보여줍니다.

사용자가 이미지 (https://x.example/doge.png)를 요청하는 페이지(https://a.example)를 방문합니다. 이미지가 네트워크에서 요청되고 https://x.example/doge.png를 키로 사용하여 캐시됩니다.

동일한 사용자가 동일한 이미지 (https://x.example/doge.png)를 요청하는 다른 페이지 (https://b.example)를 방문합니다. 브라우저는 이미지 URL을 키로 사용하여 HTTP 캐시를 확인하여 이 리소스가 이미 캐시되어 있는지 확인합니다. 브라우저가 캐시에서 일치를 찾으므로 캐시된 버전의 리소스를 사용합니다.

이미지가 iframe 내에서 로드되는지 여부는 중요하지 않습니다. 사용자가 iframe (https://d.example)이 있는 다른 웹사이트(https://c.example)를 방문하고 iframe이 동일한 이미지(https://x.example/doge.png)를 요청하는 경우에도 브라우저는 캐시 키가 모든 페이지에서 동일하므로 캐시에서 이미지를 계속 로드할 수 있습니다.

이 메커니즘은 오랫동안 성능 측면에서 잘 작동해 왔습니다. 그러나 웹사이트가 HTTP 요청에 응답하는 데 걸리는 시간으로 브라우저가 이전에 동일한 리소스에 액세스했음을 알 수 있으므로 다음과 같은 보안 및 개인 정보 보호 공격에 노출될 수 있습니다.

• 사용자가 특정 사이트를 방문했는지 감지: 공격자는 특정 사이트 또는 사이트 사용자 집단에만 해당할 수 있는 리소스가 캐시에 있는지 확인하여 사용자의 탐색 기록을 감지할 수 있습니다.
• 교차 사이트 검색 공격: 공격자는 특정 웹사이트에서 사용하는 '검색 결과 없음' 이미지가 브라우저의 캐시에 있는지 확인하여 임의의 문자열이 사용자의 검색 결과에 있는지 감지할 수 있습니다.
• 크로스 사이트 추적: 캐시를 사용하여 쿠키와 유사한 식별자를 크로스 사이트 추적 메커니즘으로 저장할 수 있습니다.

이러한 위험을 완화하기 위해 Chrome 86부터 Chrome은 HTTP 캐시를 분할합니다.

캐시 파티셔닝은 Chrome의 HTTP 캐시에 어떤 영향을 미치나요?

캐시 파티셔닝에서는 캐시된 리소스를 입력할 때 리소스 URL 외에 새로운 '네트워크 격리 키'도 사용하게 됩니다. 네트워크 격리 키는 최상위 사이트와 현재 프레임 사이트로 구성됩니다.

이전 예시를 다시 살펴보고 캐시 파티셔닝이 다양한 컨텍스트에서 어떻게 작동하는지 알아보세요.

사용자가 이미지 (https://x.example/doge.png)를 요청하는 페이지(https://a.example)를 방문합니다. 이 경우 이미지가 네트워크에서 요청되고 https://a.example (최상위 사이트), https://a.example (현재 프레임 사이트), https://x.example/doge.png (리소스 URL)로 구성된 튜플을 키로 사용하여 캐시됩니다. 리소스 요청이 최상위 -frame에서 발생하는 경우 네트워크 격리 키의 최상위 사이트와 현재 프레임 사이트는 동일합니다.

동일한 사용자가 동일한 이미지 (https://x.example/doge.png)를 요청하는 다른 페이지 (https://b.example)를 방문합니다. 이전 예시에서는 동일한 이미지가 로드되었지만 키가 일치하지 않으므로 캐시가 히트되지 않습니다.

이미지는 네트워크에서 요청되고 https://b.example, https://b.example, https://x.example/doge.png로 구성된 튜플을 키로 사용하여 캐시됩니다.

이제 사용자가 https://a.example로 돌아오지만 이번에는 이미지(https://x.example/doge.png)가 iframe에 삽입됩니다. 이 경우 키는 https://a.example, https://a.example, https://x.example/doge.png가 포함된 튜플이며 캐시 적중이 발생합니다. 최상위 사이트와 iframe이 동일한 사이트인 경우 최상위 프레임으로 캐시된 리소스를 사용할 수 있습니다.

사용자는 https://a.example로 돌아갔지만 이번에는 이미지가 https://c.example의 iframe에 호스팅됩니다.

이 경우 캐시에는 https://a.example, https://c.example, https://x.example/doge.png로 구성된 키와 일치하는 리소스가 없으므로 이미지가 네트워크에서 다운로드됩니다.

도메인에 하위 도메인이나 포트 번호가 포함된 경우 어떻게 해야 하나요? 사용자가 이미지를 요청하는 iframe(https://c.example:8080)을 삽입하는 https://subdomain.a.example를 방문합니다.

키는 'scheme://eTLD+1'을 기반으로 생성되므로 하위 도메인과 포트 번호는 무시됩니다. 따라서 캐시 적중이 발생합니다.

iframe이 여러 번 중첩된 경우 어떻게 해야 하나요? 사용자가 iframe (https://b.example)을 삽입하는 https://a.example를 방문하고, 이 iframe은 또 다른 iframe (https://c.example)을 삽입하며, 이 iframe은 최종적으로 이미지를 요청합니다.

키가 최상위 프레임 (https://a.example)과 리소스를 로드하는 즉시 프레임 (https://c.example)에서 가져오므로 캐시 적중이 발생합니다.

FAQ

Chrome에서 이미 사용 설정되어 있나요? 확인하려면 어떻게 해야 하나요?

이 기능은 2020년 말까지 출시될 예정입니다. Chrome 인스턴스에서 이미 지원하는지 확인하려면 다음 단계를 따르세요.

1. chrome://net-export/를 열고 디스크에 로깅 시작을 누릅니다.
2. 컴퓨터에서 로그 파일을 저장할 위치를 지정합니다.
3. Chrome에서 1분 동안 웹을 탐색합니다.
4. chrome://net-export/로 돌아가서 Stop Logging(로깅 중지)을 누릅니다.
5. https://netlog-viewer.appspot.com/#import 페이지로 이동합니다.
6. 파일 선택을 누르고 저장한 로그 파일을 전달합니다.

로그 파일의 출력이 표시됩니다.

동일한 페이지에서 SplitCacheByNetworkIsolationKey를 찾습니다. 뒤에 Experiment_[****]가 오는 경우 Chrome에서 HTTP 캐시 파티셔닝이 사용 설정된 것입니다. 뒤에 Control_[****] 또는 Default_[****]가 오는 경우 사용 설정되지 않은 것입니다.

Chrome에서 HTTP 캐시 파티셔닝을 테스트하려면 어떻게 해야 하나요?

Chrome에서 HTTP 캐시 파티셔닝을 테스트하려면 명령줄 플래그 --enable-features=SplitCacheByNetworkIsolationKey를 사용하여 Chrome을 실행해야 합니다. 플래그를 사용하여 Chromium 실행의 안내에 따라 플랫폼에서 명령줄 플래그를 사용하여 Chrome을 실행하는 방법을 알아보세요.

웹 개발자로서 이번 변경사항에 따라 취해야 할 조치가 있나요?

이는 중대한 변경사항은 아니지만 일부 웹 서비스의 성능을 고려해야 할 수 있습니다.

예를 들어 글꼴 및 인기 스크립트와 같이 여러 사이트에서 캐시하기 쉬운 리소스를 대량으로 제공하는 사이트의 경우 트래픽이 증가할 수 있습니다. 또한 이러한 서비스를 이용하는 사용자는 이러한 서비스에 대한 의존도가 높아질 수 있습니다.

(개인 정보를 보호하는 방식으로 공유 라이브러리를 사용 설정하기 위한 제안인 웹 공유 라이브러리(프레젠테이션 동영상)가 있지만 아직 검토 중입니다.)

이 동작 변경사항의 영향은 무엇인가요?

전체 캐시 미스율은 약 3.6% 증가하고, FCP (콘텐츠가 포함된 첫 페인트)의 변경사항은 약간 (0.3%) 증가하며, 네트워크에서 로드되는 전체 바이트 비율은 약 4% 증가합니다. 성능에 미치는 영향에 관한 자세한 내용은 HTTP 캐시 파티셔닝 설명을 참고하세요.

표준화되어 있나요? 다른 브라우저에서는 다르게 동작하나요?

'HTTP 캐시 파티션'은 브라우저가 다르게 동작하지만 가져오기 사양에서 표준화됩니다.

• Chrome: 최상위 scheme://eTLD+1 및 프레임 scheme://eTLD+1을 사용합니다.
• Safari: 최상위 eTLD+1을 사용합니다.
• Firefox: 최상위 scheme://eTLD+1로 구현할 계획이며 Chrome과 같은 두 번째 키를 포함하는 것을 고려하고 있습니다.

worker의 가져오기는 어떻게 처리되나요?

전용 작업자는 현재 프레임과 동일한 키를 사용합니다. 서비스 워커와 공유 워커는 여러 최상위 사이트 간에 공유될 수 있으므로 더 복잡합니다. 해결 방법은 현재 논의 중입니다.

리소스

• 스토리지 격리 프로젝트
• 설명 - HTTP 캐시 파티셔닝