Страницы

Поиск по вопросам

вторник, 13 ноября 2018 г.

Применение ContentProvider при разработке “Менеджера паролей”

Какие, на Ваш взгляд, механизмы обеспечения безопасности доступа к данным необходимо использовать при реализации контент-провайдера? А какие вовсе не обязательно, но возможно? Рассматривается сценарий, при котором будут иметься как приложения с предоставляемым им ограниченным доступом(только чтение некоторой части данных), так и основное приложение-менеджер.


Ответ

Поскольку ТС говорил о менеджере паролей, рискну сделать 2 предположения:
Содержимое БД зашифровано Ключ дешифратор генерируется в момент логина юзера в программу
Это общие места при создании менеджера паролей (говорю как человек написавший несколько таковых программ).
Теперь обратимся к ContentProvider - они бывают либо exported либо не exported - разница между ними в том, что exported доступен внешней программе - в этом случае ContentProvider выступает как некий порт высунутый наружу программой. В зависимости от ситуации в порт можно или писать или только читать (полный перечень операций это стандартные CRUD операции).
Рискну опять предположить, что раз ТС интересует способ защиты ContentProvider'а, то очевидно он хочет что провайдер был exported=true - иначе можно его сделать exported=false и забыть о проблеме.
exported=true провайдер нужен в менеджере паролей, если требуется каким-то образом "проникнуть" к БД паролей в обход самой программы и получить оттуда данные (ну например просто количество записей, хэши шифров или что-то подобное относительно безвредное). Рассчитывать на ContentProvider как способ защиты данных - бессмысленно. Любые данные в Android можно получить напрямую - достаточно иметь права superuser'а.
Теперь ближе к делу. Практически все пишется на уровне манифеста (ну кроме кода самого провайдера естественно), примерно так:


>

Здесь все более-менее понятно кроме пункта с android:sharedUserId="ru.mypackage.shared.user.id" это некая альтернатива вместо того, чтобы городить огород с ContentProvider'ом- фактически это декларация того, что доступ к данным приложения открывается для приложения с идентичным sharedUserId и совпадающей подписью - по умолчанию данные приложения в частном каталоге и закрыты для остальных приложений. Так если нужно получить доступ к данным, можно иногда обойтись и без провайдера и тупо открыть данные таким вот образом.
В остальном по сути создается ваш кастомный провайдер, который защищен вашей же подписью. То есть доступ к провайдеру будет иметь только приложение обладающее пермишеном ru.mypackage.MyProvider и имеющее такую же подпись как и ваше приложение.
Далее нужно иметь ввиду, что exported провайдер по сути это отдельный процесс, который запускается в момент установки приложения или в момент запуска системы и живет без вашего приложения. Соответственно, допустим такой момент, что есть обращение к провайдеру, но само приложение еще не запущено. А как мы помним речь идет о менеджере паролей то есть ключ дешифратор генерируется при входе юзера в систему. Что мы имеем? Имеем обращение к провайдеру, а ключа для дешифровки данных нет. Хорошо, если провайдеру не нужен ключ, а если нужен? Если нужен ключ необходимо запускать приложение напрямую из провайдера.
В общем провайдер должен знать запущено ли приложение и если не запущено либо завершать свою работу или запускать через Intent приложение.
Уфф вроде все.
P.S. Я бы считал, что ContentProvider на фиг не нужен в менеджере паролей - столько гемора будет :) - достаточно обойтись sharedUserId

Комментариев нет:

Отправить комментарий