Використання витоку інформації API IndexedDB у Safari 15

Кібербезпека вирішує безліч проблем і водночас необхідна для всіх типів бізнесу: від маленьких стартапів до величезних компаній. Тому на кафедрі Компютерних наук їй приділяється особлива увага.

Зокрема у статті розглядається програмна помилка, що з’явилася в реалізації API IndexedDB у Safari 15, яка дозволяє будь-якому веб-сайту відстежувати вашу інтернет-активність і навіть розкривати вашу особистість.

IndexedDB – це API-інтерфейс браузера, призначений для зберігання значних обсягів даних на стороні клієнта. Він підтримується у всіх основних браузерах та дуже часто використовується. Оскільки IndexedDB – це низькорівневий API, багато розробників вважають за краще використовувати оболонки, які абстрагують більшість технічних аспектів і надають більш простий у використанні та зручний для розробників API.

Як і більшість сучасних технологій веб-браузерів, IndexedDB дотримується політики такого ж походження. Політика того ж таки джерела (Same-origin policy) – це фундаментальний механізм безпеки, який обмежує взаємодію документів або сценаріїв, завантажених з одного джерела, з ресурсами з інших джерел. Джерело визначається схемою (протоколом), ім’ям хоста (доменом) та портом URL-адреси, що використовується для доступу до нього.

Індексовані бази даних пов'язані з певним джерелом. Документи або сценарії, пов'язані з різними джерелами, ніколи не повинні мати можливості взаємодіяти з базами даних, пов'язаними з іншими джерелами.

Якщо ви хочете дізнатися більше про те, як працюють API-інтерфейси IndexedDB, ознайомтесь з веб-документами MDN або специфікацією W3C.

Витік IndexedDB у Safari 15

У Safari 15 на macOS та у всіх браузерах на iOS та iPadOS 15 API IndexedDB порушує політику єдиного джерела. Щоразу, коли веб-сайт взаємодіє з базою даних, створюється нова (порожня) база даних з тим самим ім'ям у всіх інших активних фреймах, вкладках та вікнах в рамках одного сеансу браузера. Вікна та вкладки зазвичай використовують один і той же сеанс, якщо ви не переключитеся на інший профіль, наприклад, у Chrome, або не відкриєте приватне вікно. Для ясності в частині статті ми будемо називати новостворені бази даних «базами даних, дубльованими з різних джерел».

Чим поганий цей витік?

Той факт, що імена баз даних просочуються з різних джерел, є порушенням конфіденційності. Він дозволяє довільним веб-сайтам дізнаватися, які веб-сайти відвідує користувач у різних вкладках або вікнах. Це можливо, оскільки імена баз даних зазвичай є унікальними і залежать від веб-сайту. Більше того, ми помітили, що в деяких випадках веб-сайти використовують унікальні ідентифікатори користувачів в іменах баз даних. Це означає, що автентифіковані користувачі можуть бути точно ідентифіковані. Деякими популярними прикладами можуть бути YouTube, Google Календар або Google Keep. Всі ці веб-сайти створюють бази даних, які включають автентифікований ідентифікатор користувача Google, і якщо користувач увійшов до декількох облікових записів, бази даних створюються для всіх цих облікових записів.

Ідентифікатор користувача Google – це внутрішній ідентифікатор, створений Google. Він однозначно ідентифікує один обліковий запис Google. Його можна використовувати з API Google для отримання загальнодоступної особистої інформації власника облікового запису. Інформація, надана цими API, контролюється багатьма факторами. Як правило, доступне як мінімум зображення профілю користувача. Щоб дізнатися більше, зверніться до документації Google People API.

Це не тільки означає, що ненадійні або шкідливі веб-сайти можуть дізнатися особистість користувача, але також дозволяє зв'язати разом кілька окремих облікових записів, що використовуються одним і тим самим користувачем.

Зауважте, що ці витоки не вимагають будь-яких конкретних дій користувача. Вкладка або вікно, що працює у фоновому режимі і постійно запитує доступні бази даних IndexedDB API, може дізнатися, які інші веб-сайти відвідує користувач у режимі реального часу. Крім того, веб-сайти можуть відкривати будь-який веб-сайт в iframe або спливаючому вікні, щоб викликати витік на основі IndexedDB для цього конкретного сайту.

Відтворення витоку

Щоб самостійно відтворити витік, просто викликайте API indexedDB.databases(). Якщо веб-сайти, відкриті в інших фреймах, вкладках або вікнах, взаємодіють з іншими базами даних, ви побачите бази даних, дубльовані з різних джерел.

Якщо база даних видаляється, всі пов'язані з нею дубльовані бази даних із різних джерел також видаляються. Однак, схоже, виникає проблема, коли інструменти розробника відкриваються та відбувається оновлення сторінки. При кожному оновленні сторінки всі бази даних знову дублюються та стають незалежними від вихідних баз даних. Насправді, неможливо навіть видалити ці дубльовані бази даних за допомогою звичайної функції indexedDB.deleteDatabase().

Така поведінка дуже ускладнює використання інструментів розробника для розуміння того, що відбувається з базами даних, з якими взаємодіє веб-сайт. Тому рекомендується використовувати інші засоби налагодження (наприклад, рендеринг виведення в DOM замість використання журналів консолі або JavaScript) при спробі відтворити витоки, описані в цій статті.

Як захистити себе

На жаль, користувачі Safari, iPadOS та iOS мало що можуть зробити, щоб захистити себе, не вживаючи рішучих заходів. Одним з варіантів може бути блокування JavaScript за замовчуванням і дозвіл його тільки на довірених сайтах. Це робить сучасний перегляд веб-сторінок незручним і, ймовірно, не є гарним рішенням для всіх. Більше того, такі вразливості, як міжсайтовий скриптинг, також дозволяють націлюватися на довірені сайти, хоча ризик набагато менший. Іншою альтернативою для користувачів Safari на комп’ютерах Mac є тимчасове перемикання на інший браузер. На жаль, в iOS та iPadOS це неможливо, оскільки торкається всіх браузерів.

Єдиний реальний захист – оновити браузер або ОС після того, як проблему буде вирішено Apple.