기여 목록 / 8471067
FSA: Validate OPFS transfer tokens by StorageKey
ContentfixMerged
OPFS 파일 시스템 접근 핸들의 전송 토큰을 사용할 때 출처뿐 아니라 전체 StorageKey가 일치하는지 검사하도록 변경했습니다. 네이티브 파일 핸들의 기존 출처 기준은 유지합니다.
문제 설명
FileSystemAccessManagerImpl의 전송 토큰 검사는 핸들 종류와 출처(origin)를 확인하지만, OPFS 저장소 파티션을 구분하는 전체 StorageKey는 비교하지 않았습니다. 같은 출처의 페이지라도 서로 다른 최상위 사이트에 포함되면 서로 다른 StorageKey와 OPFS 파티션을 가질 수 있습니다.
출처만 확인하면 한 파티션의 OPFS 핸들 토큰을 다른 파티션의 문맥에서 사용할 수 있습니다. 반면 네이티브 파일 핸들의 권한은 출처 기준이므로, 모든 핸들에 전체 StorageKey 일치를 요구하면 기존에 허용되던 네이티브 핸들 전달까지 막게 됩니다.
해결 내용
- 전송 토큰을 사용하는 문맥의
StorageKey를 검증에 전달합니다. 토큰 종류와 출처에 대한 기존 검사도 유지합니다. - 토큰의 파일 시스템 유형이 샌드박스된 OPFS 백엔드인
kFileSystemTypeTemporary이면 토큰과 사용하는 문맥의 전체StorageKey가 일치하는지 확인합니다. 최상위 사이트가 다른 같은 출처의 OPFS 토큰은 거절합니다. - 네이티브 파일 시스템 핸들은 기존의 출처 기준을 유지해, 같은 출처가 다른 최상위 사이트에 포함된 경우에도 기존 허용 범위가 바뀌지 않게 합니다.
테스트 방법
TransferToken_SandboxedDifferentTopLevelSite는 같은 출처의 다른 최상위 사이트에서 OPFS 파일·디렉터리 토큰을 사용할 수 없고, 원래 파티션에서는 사용할 수 있는지 검증합니다. 다른 출처에서도 거절되는지 확인합니다.TransferToken_NativeDifferentTopLevelSite는 같은 출처의 다른 최상위 사이트에서 네이티브 파일·디렉터리 토큰을 계속 사용할 수 있는지 검증합니다.- Gerrit 알림상 Patch Set 4에는 Code-Review +1이 기록됐습니다. 보고서 작성 과정에서 Chromium 테스트를 별도로 실행하지는 않았습니다.
배운 점
origin이 같아도 최상위 사이트가 다르면 OPFS 저장소 파티션이 달라질 수 있습니다. OPFS 핸들 검증에는 전체StorageKey가 필요합니다.- 같은 전송 토큰 API를 사용하더라도 OPFS와 네이티브 파일 핸들의 격리·권한 기준은 다릅니다. 핸들 유형별 정책을 구분해야 합니다.
- 보안 경계 테스트에서는 다른 출처뿐 아니라 같은 출처의 다른 저장소 파티션도 확인해야 합니다.