5.2.2 Правила использования разрешений

При использовании внутренних разрешений необходимо соблюдать следующие правила:

5.2.2.1 Разрешения для опасных операций на Android можно использовать только для защиты активов пользователя (обязательно)

Поскольку не рекомендуется использовать собственные опасные разрешения (см. «5.2.2.2 Не следует использовать собственные опасные разрешения» (обязательно)), мы будем рассматривать использование опасных разрешений операционной системы Android.

В отличие от других типов разрешений, опасные разрешения имеют следующую особенность: пользователь должен дать согласие на предоставление приложению прав доступа. При установке приложения на устройство с включёнными опасными разрешениями появится следующее сообщение: после того как пользователь нажмёт кнопку «Установить», приложение получит необходимые права и установится.

Приложение может обрабатывать активы пользователя, которые разработчик хочет защитить. Мы должны понимать, что опасные разрешения могут защищать только активы пользователя, поскольку пользователь просто даёт разрешение на доступ к ним. С другой стороны, активы, которые разработчики хотят защитить, не могут быть защищены таким образом.

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

5.2.2.2 Нельзя использовать собственные опасные разрешения (обязательно)

Даже при использовании внутренних опасных разрешений в некоторых случаях сообщение «Запрос на разрешение от пользователя» может не отображаться. Это означает, что в определённых ситуациях функция запроса разрешений по решению пользователя может не работать. Поэтому в руководстве указано, что нельзя использовать внутренние опасные разрешения.

Чтобы объяснить это, рассмотрим два типа приложений. Первый тип определяет внутренние опасные разрешения и позволяет компонентам, защищённым этими разрешениями, быть открытыми. Назовём такое приложение ProtectedApp. Второй тип — AttackerApp, который пытается использовать компоненты ProtectedApp. Предположим также, что AttackerApp не только объявляет об использовании своих разрешений, но и определяет те же разрешения.

В следующих случаях AttackerApp может использовать компоненты ProtectedApp без согласия пользователя:

• Когда пользователь устанавливает AttackerApp, установка будет завершена без сообщения, и приложение запросит опасные разрешения пользователя.
• Аналогично, когда пользователь устанавливает ProtectedApp, установка пройдёт без специального предупреждения.
• После запуска AttackerApp он сможет получить доступ к компонентам ProtectedApp незаметно для пользователя, что может привести к потере данных.

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

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

5.2.2.3 Собственные подписи должны использоваться только в приложениях, предоставляемых поставщиком (обязательно)

Как показано в «5.2.1.2 Как использовать внутренние подписи для обмена данными между внутренними приложениями», проверка подписей обеспечивает безопасность при обмене данными между приложениями. При использовании этого механизма уровень безопасности для разрешений с подписью должен быть определён в AndroidManifest.xml приложения поставщика, но не в приложении пользователя.

Это правило также применяется к разрешениям signatureOrSystem. Причина в том, что: Мы предполагаем, что перед приложением поставщика установлено несколько приложений пользователей, и каждое из них требует разрешений, определённых поставщиком, а также определяет те же разрешения самостоятельно. В этих случаях все приложения пользователей смогут получить немедленный доступ к поставщику сразу после его установки, а затем, при удалении ранее установленных приложений пользователей, разрешения будут удалены, и они станут неопределёнными. Следовательно, остальные приложения пользователей больше не смогут получить доступ к поставщику.

Таким образом, когда приложение пользователя определяет собственное разрешение, оно может случайно сделать разрешение неопределённым. Поэтому только приложение поставщика должно определять разрешения, необходимые для защиты компонентов, и избегать определения разрешений пользователем.

Благодаря этому определению пользовательские разрешения становятся неопределёнными при установке приложения поставщика и определёнными при его удалении. Поэтому, поскольку разрешения всегда соответствуют определениям приложения поставщика, компоненты могут быть должным образом защищены. Обратите внимание, что этот аргумент верен, потому что для внутренних подписей пользовательское приложение получает разрешения, независимо от порядка взаимодействия приложений (24).

Если используются обычные/опасные разрешения и пользовательское приложение устанавливается перед приложением поставщика, разрешение не будет предоставлено пользовательскому приложению и останется неопределённым. Таким образом, даже после установки приложения поставщика невозможно получить доступ к компоненту.

(24) Если используются обычные / опасные разрешения и пользовательское приложение установлено до приложения поставщика, разрешение не предоставляется пользовательскому приложению, и оно остаётся неопределённым. Следовательно, компонент не может быть доступен даже после установки приложения поставщика.

5.2.2.4 Убедитесь, что внутренние подписи определены внутренним приложением (обязательно)

Фактически, только путём объявления подписи в AndroidManifest.xml и использования разрешений для защиты компонента можно сказать, что это достаточно безопасно. Для получения подробной информации о проблемах см. раздел «Дополнительные темы» «5.2.3.1 Обход особенностей системы Android, связанных с пользовательскими подписями, и меры противодействия».

Вот шаги для безопасного и правильного использования внутренних подписей:

1. Определите внутреннюю подпись в AndroidManifest.xml поставщика (определение разрешения). Пример: <permission android:name="xxx" android:protectionLevel="signature" />
2. Используйте атрибут разрешения для принудительного применения разрешений к компонентам, которые необходимо защитить, в AndroidManifest.xml поставщика (применение разрешений). Пример: <activity android:permission="xxx" ... >...</activity>
3. Объявите внутреннюю подпись, определённую в uses-permission, чтобы получить доступ к защищаемым компонентам в каждом приложении пользователя (объявление разрешений). Пример: <uses-permission android:name="xxx" />

Затем выполните следующие действия в исходном коде:

1. Перед обработкой запроса на компонент сначала убедитесь, что внутренняя подпись определена внутренним приложением. В противном случае проигнорируйте запрос. (Защита компонентов поставщика)
2. Прежде чем получить доступ к компоненту, сначала убедитесь, что подпись определена внутренним приложением. В противном случае не получайте доступ к компоненту (защита компонентов пользователя).

Наконец, перед использованием функции подписи Android Studio выполните следующие действия:

1. Подпишите APK всех приложений, взаимодействующих друг с другом, одним и тем же ключом разработчика.

Здесь конкретные моменты реализации «Убедитесь, что внутренняя подпись уже определена внутренним приложением» см. в «5.2.1.2 Как использовать внутренние подписи для обмена данными между внутренними приложениями».

Это правило также применимо к signatureOrSystem разрешениям.

5.2.2.5 Не следует использовать собственные обычные разрешения (рекомендуется)

Для использования обычных разрешений приложению достаточно объявить их в AndroidManifest.xml с помощью uses-permission. Поэтому нельзя использовать обычные разрешения для защиты компонентов от вредоносных программ.

Более того, при использовании пользовательских обычных разрешений для обмена данными между приложениями возможность предоставления разрешений зависит от порядка установки. Например, когда вы устанавливаете приложение, которое объявило использование обычных разрешений (пользовательский метод), и оно имеет определённый компонент перед другим приложением (поставщик), приложение пользователя не сможет получить доступ к защищённому компоненту поставщика, даже если оно будет установлено позже.

Одним из способов предотвращения потери обмена данными из-за порядка установки является определение разрешений в каждом приложении обмена данными. Таким образом, все приложения пользователя смогут получить доступ к поставщикам, даже если они установлены раньше. Однако существует риск того, что при удалении первого установленного приложения пользователя разрешения станут неопределёнными, и другие приложения пользователя также не смогут получить доступ к поставщику.

Как упоминалось выше, существует риск ущерба доступности приложения, поэтому не следует использовать собственные обычные разрешения.

5.2.2.6 Строка имени вашего собственного разрешения должна быть расширением имени пакета приложения (рекомендуется)

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

(package name).permission.(identifying string)

Например, предпочтительным именем разрешения для пакета org.jssec.android.sample будет:

org.jssec.android.sample.permission.READ