Защита личных данных пользователя в браузерах

Проблема — это не проблема, пока её никто не увидел.

Firefox, Chromium, explorer, safari, opera-vivaldi, yandex browser — Это лишь только самые популярные браузеры, а есть еще целая куча других и форков этих. Не известно зачем так много их нужно, но каждый из них что-то делает лучше, хотя бы выглядят по-разному, и как-то по своему интерпретирует стандарты web. В плане безопасности все они решают одну проблему — сделать так, чтобы какой-то сторонний сайт не получил контроль над вашим компьютером через браузер. С другой же стороны, иногда необходимо дать некоторые права до реальной операционной системы или железа web-приложениям, например до камеры, gps и т.д.

Балансируя на разрешениях/ограничениях все вендоры решают только эту сторону безопасности браузеров, игнорируя защиту локальных данных пользователя. Я решил изучить этот вопрос и узнать, что происходит именно в этой области безопасности современных браузеров.

Все браузеры хранят пользовательские закладки, историю посещений, кэш, пароли, кукис, файлы web-sql, indexedDB и прочее. Где же именно хранятся эти данные?

  • Chromium(Windows): C:\Users\%username%\AppData\Local\Google\Chrome\UserData\Default
  • Chromium(Linux): /home/%username%/.config/google-chrome/Default
  • Firefox(Windows): C:\Users\%username%\AppData\Roaming\Mozilla\Firefox\Profiles\$hash.default
  • Firefox(Linux): /home/%username%/.mozilla/firefox/$hash.default/

Критично важно хранить в защищенном месте по крайней мере пароли и кукисы. В действительности же браузеры защищают только пароли и то не всегда.

Хранение паролей

Для справки IE использует методы WinAPI CryptProtectData и CredentialManager. Благодаря этому методу файл с паролями хоть и хранится в определенном месте, но сами пароли там зашифрованы средствами ОС. CryptProtectData использует сведения о сессии Logon, поэтому только данный пользователь сможет расшифровать данные. К сожалению, если вирус уже окажется на компьютере, то он сам сможет распаковать от имени этого пользователя все файлы паролей и увезти их с собой.

Chromium хранит все пароли в каталоге %PROFILE%/Login Data — это файл sqlite базы данных. В этой БД хранятся адреса сайтов, соответственно логин-пароли, дата их создания и модификации, количество использований, url аватарки и так далее. Для шифрования паролей и только паролей в Windows используется CryptProtectData. А в Linux они по-умолчанию хранятся в открытом виде. И только если включен gnome keyring или kwallet, то все данные из Login Data будут зашифрованы их средствами.

Интереснее обстоят дела с firefox. Там по умолчанию пароли шифруются алгоритмом 3des. В качестве ключа используются случайно сгененрированный файл key3.db, а сами пароли хранятся как blob объекты в logins.json или signons.sqlite. Злоумышленнику придется получить все эти файлы и знать как именно расшифровывать файл-паролей, но это конечно же не проблема. Но зато в firefox есть мастер-ключ, при установке которого добавляется соль в key3.db и тогда уже расшифровать без знания мастер пароля не получится ничего. По умолчанию мастер пароль просто равен пустой строке.

Угрозы безопасности

Для того чтобы оценить, какой из подходов защищает лучше всего, определим то от чего мы защищаемся. Я выделю следующие угрозы:

  1. Вредоносное ПО может получить всю папку с данными пользователя браузера. Похитить пароли, куки и файлы баз данных web-api. Проанализировать и скомпрометировать пользователя по истории браузера, кэшу и БД.
  2. Любой пользователь ОС имея доступ к одной сессии может забрать весь каталог профиля и запустить у себя браузер от имени жертвы. Особенно актуально на рабочих местах, когда по политике безопасности предприятия на всех машинах строго определенные пароли и все их знают. Тогда средства шифрования, основанные на сессии строго говоря бессмысленны.

Учитывая эти угрозы, можно считать наиболее защищенным от кражи паролей только cromium в linux/macOs с включенными менеджерами ключей, так как они всегда требуют пароль, независимо от сессии. А так же firefox с мастер паролем.

Решение проблемы

Итак, проблема — каталоги с пользовательскими данными во всех браузерах хранятся в строго определенных местах и не защищаются шифрованием. Самое простое, но далеко не изящное решение — это шифровать только эту папку средствами ОС или какими-то сторонними программами. Например, cryptkeeper или EFS в windows. В принципе, именно так я и решил проблему на текущий момент на своем рабочем компьютере. Также можно запускать хром внутри docker или виртуальном контейнере, в котором сама файловая система будет зашифрована. Эти методы защищают от второго типа угрозы, но к сожалению не от первого, так как расшифрованная папка существует как обычная примонтированная директория, т. е. ВПО так или иначе получит доступ к вашим файлам.

Если бы браузеры сами прозрачно для себя шифровали все файлы с которыми работали, тогда на ФС хранились бы только зашифрованные данные и не было бы момента времени, когда они существуют в открытом виде. Использование браузера и дополнительно программы для шифрования не так удобно для пользователя, как единый мастер пароль в браузере. Т.е. решение проблемы — это использовать профили браузера, а не операционной системы, прозрачно шифровать данные методами самого браузера, а не ОС. Такой подход, может несколько снизить производительность, а именно скорость работы IO браузера, но зато даст требуемый уровень защищенности.

Зачем?

Какие бонусы мы получим?

  1. Полную защищенность данных, начиная от истории браузера, заканчивая паролями и данными web-sql.
  2. Можно будет использовать один браузер разным пользователям из-под одной сессии ОС.
  3. Все куки будут привязаны к профилю браузера и не надо будет каждый раз при запуске браузера вводить пароли, как например в подходе с мастер ключом по паролю не зависимо от исполнения(ff, gnome-keyring, kde-wallet, osX keystore и др..), т.е. будет сохранённое зашифрованное состояние браузера.

Возникает закономерный вопрос, почему же мейтнеры ни одного браузера не добавили такой функциональности? После некоторого исследования вопроса, я нашел рубрику вопросов-ответов по поводу безопасности в chromium. В основном там описываются вопросы безопасности со стороны веба. Но есть один интересный пункт: «Why aren’t physically-local attacks in Chrome’s threat model?»— почему не рассматриваются физические атаки на хром в его модели безопасности. Далее привожу мой перевод с пояснениями этого раздела.

Пользователи иногда жалуются, что они могут компрометировать Chromium если установят вредоносное ПО или dll, или используют уязвимости в api. Мы(мейтнеры) считаем, что все эти уязвимости вне компетенции хромиума, мы не можем защищаться от вредоносного ПО, которое уже есть на вашем компьютере. Так как если кто-то уже получил доступ к вашему компьютеру и вашей сессии, то он сможет так же подменить dll у других приложений и вообще получить всю информацию, хранящуюся у вас на компьютере. Это не проблема хрома — в общем приложения должны доверять локальному пользователю. Чтобы уменьшить риск сторонними пользователями получить физический доступ к вашему компьютеру следуйте этим рекомендациям:

Используйте FDE — full disk encryption(полное шифрование диска). Используйте пароли и usb-ключи для расшифровывания диска. ChromeOS шифрует домашнюю директорию. Так же в своей ОС шифровать отдельные ресурсы.

Если вы разделяете компьютер с несколькими людьми, то пользуйтесь средствами ОС, такими как сессии и шифрование домашнего каталога.

Используйте блокировку экрана. (Очевидно)

Вы можете отключить сохранение пароля хромиумом, удалять все куки и чистить историю при выходе из хромиума.

Заметим, что невозможно избежать рисков на общедоступных компьютерах. Всё что хранится на таких компьютерах становится автоматически общедоступным. Используйте режим инкогнито на таких компьютерах.

Исходя из политики хромиума, желаемой функции у них не появится никогда. И они действительно не считают это уязвимостью.

Fork it

А как тогда можно решить эту проблему, кроме описанных ранее интуитивно понятных способов? Единственным решением будет сделать форк браузера, хромиума или фаерфокса, и написать специальный патч, добавляющий такой функционал. Скорее всего его не подтвердят мейтнеры, так как он может усложнить интуитивность интерфейса браузера, но тем не менее можно распространять это решение как та же самая подключаемая библиотека dll с необходимым функционалом. Интересно рассмотреть tor-browser, он позиционируется как защищенный форк фаерфокса, так что в него могут включить этот патч.

Интерфейс браузера не сильно изменится, но появится менеджер сессии, как в ОС. При запуске браузера, пользователя попросят выбрать профиль, ввести мастер-пароль или подключить usb-ключ. Далее браузер построит ключ расшифрования и будет работать в прежнем режиме, думая что шифрования и нет. Таким образом предполагается патч подсистемы ввода-вывода браузера и добавление новых меню в UI.

В качестве целевого браузера, для которого я буду делать патч, я выбрал chromium. В принципе нет никакой разницы между firefox и chromium, но решающим фактором для выбора стало наличие исчерпывающей документации по исходному коду и проекту в целом у chromium. В любом случае подход, который я применю в одном браузере достаточно просто можно будет перенести на любой другой, так как в целом архитектура у них схожая.