Firefox IndexedDB 취약점, Tor Browser의 익명성을 무너뜨리다!
Firefox 기반 브라우저의 IndexedDB API에서 고유 식별자(Unique Identifier)가 생성되는 취약점이 발견됨
IndexedDB 데이터베이스의 반환 순서가 브라우저 프로세스 수명 동안 고정되어 추적 가능성(Trackability)을 야기함
Tor Browser의 '새로운 신원(New Identity)' 기능에도 불구하고 세션 간 연결(Session Linking)이 가능해 프라이버시 침해 우려
Mozilla는 Firefox 150 및 ESR 140.10.0에서 패치를 완료했으며, 정렬(Sorting)을 통해 문제를 해결함
IndexedDB의 취약점: 고유 식별자 생성 원리
본 취약점은 Firefox 기반 브라우저의 IndexedDB API가 데이터베이스 메타데이터를 반환하는 순서에 기인한다. 특히, Private Browsing 모드에서 데이터베이스 이름이 UUID로 매핑되고, 해시 테이블의 내부 구조에 따라 반환 순서가 결정된다. 이러한 과정은 브라우저 프로세스 수명 동안 고정되어 추적(Tracking)에 악용될 수 있다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)의 실패를 의미한다.
Tor Browser에서의 심각한 영향
Tor Browser는 사용자의 익명성을 보장하기 위해 설계되었지만, 본 취약점으로 인해 '새로운 신원(New Identity)' 기능을 사용해도 세션 간 연결(Session Linking)이 가능해진다. 이는 사용자가 기대하는 데이터 미저장 정책(Zero-Retention Policy)에 어긋나는 심각한 문제이다. IndexedDB의 내부 동작 방식이 Tor Browser의 익명성 보장 기능을 무력화시키는 결과를 초래한다.
해결 방안: 정렬(Sorting) 기반의 패치
Mozilla는 Firefox 150 및 ESR 140.10.0에서 이 문제를 해결하기 위해 정렬(Sorting) 기반의 패치를 적용했다. 구체적으로, `indexedDB.databases()` API가 메타데이터를 반환하기 전에 사전 정렬(Pre-sorting)을 수행하여 고유 식별자 생성을 방지한다. 이는 API의 유용성을 유지하면서 프라이버시 침해(Privacy Breach)를 막는 효과적인 해결책으로 평가받는다.
개발자 관점에서의 교훈
본 취약점은 사소한 구현 세부 사항(Implementation Details)이 어떻게 심각한 프라이버시 문제를 야기할 수 있는지를 보여준다. 개발자는 API 설계(API Design) 시 내부 동작의 노출이 잠재적인 추적 벡터(Tracking Vector)가 될 수 있음을 인지해야 한다. 특히, 프라이버시(Privacy)에 민감한 기능을 구현할 때는 데이터 격리(Data Isolation) 및 데이터 미저장 정책(Zero-Retention Policy)을 고려해야 한다.
