Последствия для безопасности хранения кодовой фразы на стороне клиента в chrome.storage.local

Я прочитал здесь документацию, которая предупреждает об опасности хранения защищенной информации в chrome.storage.local, поскольку она незашифрована.

Для моего приложения расширение генерирует кодовую фразу для пользователя локально, используя библиотеку Javascript, упакованную с расширением. Эта парольная фраза затем сохраняется в chrome.storage.local и никогда не передается на удаленный сервер через расширение. Я понимаю, что есть последствия для безопасности, потому что это незашифрованное и приложение все еще находится в разработке. Цель этого сообщения - открыть наилучшую схему безопасности.

Конкретные вопросы...

Каковы методы (векторы атаки), которые можно использовать для доступа к chrome.storage.local вне самого расширения?
Помимо риска того, что клиент, выполняющий расширение, подвергается угрозе со стороны вредоносного скрипта или приложения локально, существует ли риск удаленной атаки?

Заранее спасибо за вашу помощь.

Ответ 1

Любой, у кого есть физический доступ, может прочитать содержимое chrome.storage.local, однако по дизайну нет никакого способа ~~для другого расширения для доступа к данным с вашего расширения или~~ для злонамеренного сайта для прямого доступа к данным.

Однако это не невозможно - может быть какая - то нулевая уязвимость, которая позволяет это произойти.

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

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

Ответ 2

Данные, хранящиеся в chrome.storage.local, не шифруются каким-либо образом, поэтому их можно читать как обычный текст.

Существует множество способов доступа к этим данным, будь то через некоторые другие "высокопривилегированные" хромовые расширения (например, те, которые имеют доступ к средствам разработки) или из любого другого процесса (в случае, если они имеют правильное разрешение, которое варьируется в зависимости от разных OS), запущенной на клиентской машине, путем прямого доступа к файлам, где хром хранит эти данные.

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

Я настоятельно рекомендую не хранить какие-либо конфиденциальные данные в клиентском приложении (расширение), а хранить его на стороне сервера, где вероятность того, что эти данные будут скомпрометированы, значительно ниже.
Если вам все еще нужно использовать эти данные на стороне клиента, убедитесь, что:

Передавайте только соответствующие данные каждый раз, когда расширение необходимо использовать. Данные, которые не используются, не должны передаваться.
Передайте данные, зашифрованные ключом, который может быть сохранен в клиентском хранилище. Ключ должен быть произвольно сгенерированным ключом на каждом клиенте, чтобы предотвратить массовое извлечение, когда один клиентский ключ был скомпрометирован. Да, это все еще открыто для целенаправленной атаки на ваше приложение, но покрывает вероятность того, что данные будут украдены с нецелевыми атаками.
Никогда не храните эти зашифрованные или дешифрованные данные в любом виде хранилища на клиентской машине (включая файлы cookie, локальное хранилище, хранилище сеансов, глобальные переменные и т.д.).

Но я бы не предложил передавать данные на клиентскую сторону, если вы опасаетесь, что ваши данные могут быть скомпрометированы, но сделайте все, что вам нужно сделать на стороне сервера. Это может заставить вас перепроектировать приложение, что является единственным вариантом в большинстве случаев.

Удачи!