Пользовательские разрешения

Категория OWASP: MASVS-CODE: Качество кода

Обзор

Риски, связанные с настраиваемыми разрешениями, возникают, когда определение настраиваемых разрешений отсутствует или написано с ошибкой, либо когда соответствующий атрибут android:protectionLevel неправильно используется в манифесте.

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

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

  • Управление межпроцессным взаимодействием (IPC) между двумя или более приложениями.
  • Доступ к сторонним сервисам
  • Ограничение доступа к общим данным приложения

Влияние

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

Риск: опечатки в пользовательских разрешениях

Пользовательское разрешение может быть объявлено в манифесте, но из-за опечатки для защиты экспортированных компонентов Android используется другое пользовательское разрешение. Вредоносное приложение может воспользоваться приложениями, которые неправильно написали разрешение, одним из следующих способов:

  • Сначала зарегистрировать это разрешение
  • Предвидение написания в последующих приложениях

Это может позволить приложению несанкционированный доступ к ресурсам или контроль над приложением-жертвой.

Например, уязвимое приложение хочет защитить компонент с помощью разрешения READ_CONTACTS , но случайно пишет это разрешение с ошибкой как READ_CONACTS . Вредоносное приложение может запросить READ_CONACTS , поскольку оно не принадлежит ни одному приложению (или системе), и получить доступ к защищенному компоненту. Другой распространенный вариант этой уязвимости — android:permission=True . Такие значения, как true и false , независимо от капитализации, являются недопустимыми входными данными для объявления разрешения и обрабатываются аналогично другим опечаткам объявлений пользовательских разрешений. Чтобы это исправить, значение атрибута android:permission следует изменить на действительную строку разрешения. Например, если приложению необходим доступ к контактам пользователя, значение атрибута android:permission должно быть android.permission.READ_CONTACTS .

Смягчения

Проверка Android Lint

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

Соглашение об именах

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

Риск: потерянные разрешения

Разрешения используются для защиты ресурсов приложений. Существует два разных места, где приложение может объявить разрешения, необходимые для доступа к ресурсам:

Однако иногда эти разрешения не определяются соответствующим тегом <permission> в манифесте APK на устройстве. В этом случае они называются потерянными разрешениями . Такая ситуация может возникнуть по ряду причин, таких как:

  • Между обновлениями манифеста и кода с проверкой разрешений может возникнуть рассинхронизация.
  • APK-файл с указанными разрешениями может не быть включен в сборку или может быть включена неправильная версия.
  • Имя разрешения в проверке или манифесте могло быть написано неправильно.

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

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

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

Смягчения

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

Приложение использует специальные разрешения my.app.provider.READ и my.app.provider.WRITE для защиты доступа к поставщику контента:

XML

<provider android:name="my.app.database.CommonContentProvider" android:readPermission="my.app.provider.READ" android:writePermission="my.app.provider.WRITE" android:exported="true" android:process=":myappservice" android:authorities="my.app.database.contentprovider"/>

Приложение также определяет и использует эти пользовательские разрешения, тем самым не позволяя другим вредоносным приложениям делать это:

XML 

<permission android:name="my.app.provider.READ"/>
<permission android:name="my.app.provider.WRITE"/>
<uses-permission android:name="my.app.provider.READ" />
<uses-permission android:name="my.app.provider.WRITE" />

Риск: неправильное использование android:protectionLevel

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

Смягчения

Избегайте нормального или опасного уровня защиты

Использование нормального или опасного protectionLevel для ваших разрешений означает, что большинство приложений могут запрашивать и получать разрешения:

  • «нормальный» требует только объявить об этом
  • «опасно» одобрят многие пользователи

Таким образом, эти protectionLevels обеспечивают небольшую безопасность.

Использовать разрешения для подписи (Android >= 10)

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

Определите в своем манифесте пользовательское разрешение следующим образом:

XML

<permission
    android:name="my.custom.permission.MY_PERMISSION"
    android:protectionLevel="signature"/>

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

XML

<activity android:name=".MyActivity" android:permission="my.custom.permission.MY_PERMISSION"/>

Любое другое приложение, подписанное тем же сертификатом, что и приложение, объявившее это специальное разрешение, затем получит доступ к действию .MyActivity и должно будет объявить его в своем манифесте следующим образом:

XML 

<uses-permission android:name="my.custom.permission.MY_PERMISSION" />

Остерегайтесь подписных пользовательских разрешений (Android < 10)

Если ваше приложение предназначено для Android < 10, то всякий раз, когда пользовательские разрешения вашего приложения удаляются из-за удалений или обновлений, могут быть вредоносные приложения, которые могут по-прежнему использовать эти специальные разрешения и, таким образом, обходить проверки. Это связано с уязвимостью повышения привилегий ( CVE-2019-2200 ), которая была исправлена ​​в Android 10.

Это одна из причин (наряду с риском возникновения гонок), по которой проверки подписей рекомендуются вместо пользовательских разрешений.

Риск: состояние гонки

Если законное приложение A определяет специальное разрешение подписи, которое используется другими приложениями X , но впоследствии удаляется, то вредоносное приложение B может определить то же самое специальное разрешение с другим уровнем protectionLevel , например, Normal . Таким образом, B получает доступ ко всем компонентам, защищенным этим специальным разрешением в приложениях X , без необходимости подписывать тот же сертификат, что и приложение A

То же самое произойдет, если B будет установлен раньше A

Смягчения

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

Ресурсы