저장용량 파티셔닝

특정 유형의 사이드 채널 크로스 사이트 추적을 방지하기 위해 Chrome은 서드 파티 컨텍스트에서 대부분의 스토리지 및 커뮤니케이션 API를 파티션으로 나누었습니다.

구현 상태

이 기능은 Chrome 115 이상에서 모든 사용자에게 사용 설정되었습니다. 저장용량 파티션 나누기 제안서는 추가 논의를 위해 열려 있습니다.

스토리지 파티셔닝이란 무엇인가요?

특정 유형의 사이드 채널 교차 사이트 추적을 방지하기 위해 Chrome은 서드 파티 컨텍스트에서 스토리지 및 커뮤니케이션 API를 파티션으로 나눕니다.

스토리지 파티셔닝을 사용하지 않으면 사이트에서 여러 사이트의 데이터를 조인하여 웹에서 사용자를 추적할 수 있습니다. 또한 삽입된 사이트가 타이밍 공격, XS-Leaks, COSI와 같은 부채널 기법을 사용하여 최상위 사이트의 사용자에 관한 특정 상태를 추론할 수 있습니다.

이전에는 저장소가 출처로만 키가 지정되었습니다. 즉, example.com의 iframe이 a.com 및 b.com에 삽입된 경우 저장소에 ID를 저장하고 성공적으로 검색하여 두 사이트의 탐색 습관을 파악할 수 있습니다. 서드 파티 저장용량 파티셔닝을 사용 설정하면 example.com의 저장용량이 a.com용과 b.com용의 두 가지 파티션에 존재합니다.

일반적으로 파티셔닝은 로컬 스토리지 및 iframe의 IndexedDB와 같은 스토리지 API에 의해 저장된 데이터에 더 이상 동일한 출처의 모든 컨텍스트에서 액세스할 수 없다는 것을 의미합니다. 대신 데이터는 출처와 최상위 사이트가 동일한 컨텍스트에서만 사용할 수 있습니다.

이전

파티션을 사용하지 않는 스토리지 API 다이어그램
저장소 파티셔닝 전에 example.com은 a.com에 삽입될 때 데이터를 쓰고 b.com에 삽입될 때 데이터를 읽을 수 있습니다.

이후

파티션이 있는 스토리지 API 다이어그램
스토리지 파티셔닝 후 b.com에 삽입된 example.com은 a.com에 삽입된 경우 example.com의 스토리지에 액세스할 수 없습니다.

체이닝된 iframe의 스토리지 파티셔닝

iframe에 iframe이 포함되면 더 복잡해집니다. 이는 체인의 두 개 이상의 위치에 동일한 출처가 있는 경우에 특히 그렇습니다.

예를 들어 A1에는 A2의 iframe이 포함된 B의 iframe이 포함되어 있고 A1과 A2가 모두 동일한 사이트에 있습니다. 파티셔닝 시 최상위 수준 및 현재 수준 컨텍스트만 고려하는 경우 iframe A2는 중간에 서드 파티 iframe (B)가 있음에도 불구하고 최상위 수준 (A1)과 동일한 사이트에 있으므로 퍼스트 파티로 간주될 수 있습니다. A2가 기본적으로 파티션되지 않은 저장소에 액세스할 수 있는 경우 클릭재킹과 같은 보안 위험에 노출될 수 있습니다.

이를 해결하기 위해 Chrome은 스토리지 파티션 키의 일부로 추가 '상위 비트'를 포함합니다. 이 비트는 현재 컨텍스트와 최상위 컨텍스트 간의 문서가 현재 컨텍스트와 크로스 사이트인 경우 설정됩니다. 이 경우 사이트 B는 교차 사이트이므로 비트가 A2에 설정되고 저장소가 A1에서 파티션됩니다.

체인에 크로스 사이트 컨텍스트가 없으면 스토리지가 파티션되지 않습니다. 예를 들어 A3의 iframe이 포함된 A2의 iframe이 포함된 사이트 A1은 모두 동일한 사이트에 있으므로 A1, A2, A3에 대해 파티션되지 않습니다.

체이닝된 iframe 전체에 걸쳐 파티션되지 않은 액세스가 필요한 사이트의 경우 Chrome에서는 이러한 사용 사례를 지원하기 위해 Storage Access API 확장을 실험하고 있습니다. Storage Access API는 프레임된 사이트에서 API를 명시적으로 호출해야 하므로 클릭재킹 위험을 완화합니다.

업데이트된 API

파티셔닝의 영향을 받는 API는 다음과 같은 그룹으로 나눌 수 있습니다.

Storage API

  • 할당량 시스템
    할당량 시스템은 저장소에 할당되는 디스크 공간의 양을 결정하는 데 사용됩니다. 할당량 시스템은 각 파티션을 별도의 버킷으로 관리하여 허용되는 공간의 양과 삭제 시기를 결정합니다.
    navigator.storage.estimate()는 파티션의 정보를 반환합니다. window.webkitStorageInfo 및 navigator.webkitTemporaryStorage와 같은 Chrome 전용 API는 지원 중단됩니다.
    IndexedDB 및 캐시 저장소는 새 파티션 할당량 시스템을 사용합니다.
  • Web Storage API
    Web Storage API는 브라우저가 키-값 쌍을 저장할 수 있는 메커니즘을 제공합니다. 로컬 스토리지와 세션 스토리지라는 두 가지 메커니즘이 있습니다. 현재 할당량이 관리되지는 않지만 여전히 파티션이 생성됩니다.
  • Origin 비공개 파일 시스템
    File System Access API를 사용하면 사용자가 액세스 권한을 부여한 후 사이트에서 기기의 파일 및 폴더에 변경사항을 직접 읽거나 저장할 수 있습니다. 출처 비공개 파일 시스템을 사용하면 출처가 사용자가 쉽게 액세스할 수 있고 파티션된 비공개 콘텐츠를 디스크에 저장할 수 있습니다.
  • Storage Bucket API
    Storage Bucket API는 버킷이라는 새로운 개념을 사용하여 IndexedDB 및 localStorage와 같은 다양한 저장소 API를 통합하는 Storage 표준용으로 개발되고 있습니다. 버킷에 저장된 데이터와 버킷과 연결된 메타데이터가 분할됩니다.
  • Clear-Site-Data 헤더
    응답에 Clear-Site-Data 헤더를 포함하면 서버가 사용자의 브라우저에 저장된 데이터를 삭제하도록 요청할 수 있습니다. 캐시, 쿠키, DOM 스토리지를 삭제할 수 있습니다. 헤더를 사용하면 한 파티션 내의 저장소만 지워집니다.
  • Blob URL 저장소
    blob은 처리할 원시 데이터가 포함된 객체이며 리소스에 액세스하기 위해 blob URL을 생성할 수 있습니다. Blob URL 저장소는 파티셔닝되지 않습니다. 최상위 컨텍스트에서 blob URL로 이동하는 사용 사례 (대화)를 지원하기 위해 blob URL 저장소는 최상위 사이트 대신 상담사 클러스터에 의해 분할될 수 있습니다. 이 기능은 아직 테스트할 수 없으며 향후 파티셔닝 메커니즘이 변경될 수 있습니다.

커뮤니케이션 API

스토리지 API와 함께 한 컨텍스트가 출처 경계를 넘어 통신할 수 있는 커뮤니케이션 API도 분할됩니다. 이 변경사항은 주로 브로드캐스트 또는 동일 출처 런던디를 통해 다른 컨텍스트를 검색할 수 있는 API에 영향을 미칩니다.

다음 커뮤니케이션 API의 경우 서드 파티 iframe이 더 이상 동일 출처 컨텍스트와 통신할 수 없습니다.

  • 방송 채널
    Broadcast Channel API를 사용하면 브라우징 컨텍스트(창, 탭 또는 iframe)와 동일한 출처의 작업자 간에 통신할 수 있습니다.
    컨텍스트 간의 관계가 명확하게 정의된 교차 사이트 iframe postMessage()은 변경되지 않을 예정입니다.
  • SharedWorker
    SharedWorker API는 동일한 출처의 여러 브라우징 컨텍스트에서 액세스할 수 있는 작업자를 제공합니다.
  • 웹 잠금
    Web Locks API를 사용하면 동일한 출처의 한 탭 또는 작업자에서 실행되는 코드가 일부 작업이 실행되는 동안 공유 리소스의 잠금을 획득할 수 있습니다.

Service Worker API

Service Worker API는 백그라운드에서 작업을 실행하기 위한 인터페이스를 제공합니다. 사이트는 이벤트에 응답하는 새 작업자 컨텍스트를 만드는 영구 등록을 만들며, 이 작업자는 동일한 출처 컨텍스트와 통신할 수 있습니다. 또한 Service Worker API는 탐색 요청의 시점을 변경할 수 있으므로 기록 스니핑과 같은 교차 사이트 정보 유출이 발생할 수 있습니다.

따라서 서드 파티 컨텍스트에서 등록된 서비스 워커는 파티션됩니다.

확장 프로그램 API

확장 프로그램은 사용자가 탐색 환경을 맞춤설정할 수 있는 프로그램입니다.

확장 프로그램 페이지 (chrome-extension:// 스키마가 있는 페이지)는 웹의 여러 사이트에 삽입될 수 있으며, 이 경우 최상위 파티션에 계속 액세스할 수 있습니다. 이러한 페이지는 다른 사이트를 삽입할 수도 있습니다. 이 경우 확장 프로그램에 해당 사이트에 대한 호스트 권한이 있는 한 해당 사이트는 최상위 파티션에 액세스할 수 있습니다.

자세한 내용은 확장 프로그램 문서를 참고하세요.

데모: 스토리지 파티셔닝 테스트

데모 사이트: https://storage-partitioning-demo-site-a.glitch.me/

각 테스트에 대해 왼쪽에 녹색 체크표시, 오른쪽에 빨간색 십자가가 표시된 데모 사이트의 스크린샷
스토리지 파티셔닝이 적용된 브라우저의 출력(왼쪽)과 스토리지 파티셔닝이 적용되지 않은 브라우저의 출력(오른쪽)을 보여주는 데모의 스크린샷입니다.

이 데모에서는 사이트 A와 사이트 B라는 두 개의 사이트를 사용합니다.

  • 최상위 컨텍스트에서 사이트 A를 방문하면 다양한 저장소 메서드를 사용하여 데이터가 설정됩니다.
  • 사이트 B가 사이트 A의 페이지를 삽입하고 이 삽입이 이전에 설정된 저장소 옵션을 읽으려고 시도합니다.
  • 사이트 A가 사이트 B에 삽입된 경우 스토리지가 파티션된 경우 해당 데이터에 액세스할 수 없으므로 읽기에 실패합니다.
  • 이 데모에서는 각 읽기의 성공 또는 실패를 사용하여 데이터가 파티션된지 여부를 보여줍니다.

현재는 --disable-features=ThirdPartyStoragePartitioning 명령줄 스위치를 사용하여 Chrome에서 스토리지 파티셔닝을 사용 중지할 수 있습니다.

같은 방식으로 다른 브라우저를 테스트하여 파티셔닝 상태를 확인할 수도 있습니다.

참여 및 의견 공유