Правила использования широковещательных сообщений

4.2.2 Правила использования широковещательных сообщений

4.2.2.1 Обязательное использование приватных приёмников для широковещательных сообщений, используемых только в приложении

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

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

Пример кода на AndroidManifest.xml (не рекомендуется):

<!-- Private Broadcast Receiver -->
<!-- *** POINT 1 *** Set the exported attribute to false explicitly. -->
<receiver
    android:name=".PrivateReceiver"
    android:exported="false" >
    <intent-filter>
        <action android:name="org.jssec.android.broadcast.MY_ACTION" />
    </intent-filter>
</receiver>

Пожалуйста, обратитесь к разделу «4.2.3.1 Комбинация экспортированных атрибутов и намерений фильтровать для приёмников».

4.2.2.2 Осторожное и безопасное обращение с полученными намерениями (обязательно)

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

См. раздел «3.2 Безопасная обработка входных данных».

4.2.2.3 Использование внутренних разрешений после проверки подписи, определённой приложением (обязательно)

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

4.2.2.4 Осторожность при возврате результатов из целевого приложения (обязательно)

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

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

4.2.2.5 Ограничение получателей при отправке чувствительных данных (обязательно)

Широковещательная передача — это система, созданная для отправки информации или уведомления о времени в неназванные приложения в большом количестве. Следовательно, чувствительные данные должны быть тщательно разработаны, чтобы предотвратить их незаконное получение вредоносными приложениями. Только надёжные широковещательные приёмники должны иметь возможность принимать чувствительные данные. Другие широковещательные приёмники не должны этого делать. Вот несколько примеров методов отправки чувствительных данных:

• Метод заключается в использовании явного намерения для отправки широковещательной передачи только ожидаемым надёжным широковещательным приёмникам по фиксированному адресу.
  • Когда он отправляется в широковещательный приёмник в том же приложении, используйте Intent#setClass(Context, Class), чтобы указать адрес. Пожалуйста, обратитесь к примеру кода в разделе «4.2.1.1 Частный широковещательный приёмник — приём/отправка широковещательной передачи».
  • При отправке в широковещательный приёмник другого приложения используйте Intent#setClassName(String, String), чтобы указать адрес. Используйте сравнение между подписью разработчика APK пакета и белым списком для подтверждения разрешённых приложений. На практике метод использования неявного намерения более практичен.
• Другой метод заключается в указании receiverPermission как внутренних разрешений, определённых приложением, и объявлении использования этих разрешений надёжными широковещательными приёмниками. Пожалуйста, обратитесь к примеру кода в разделе «4.2.1.3 Внутренний широковещательный приёмчик — приём/передача широковещательной передачи». Кроме того, для реализации этого метода отправки широковещательной передачи необходимо следовать правилу «4.2.2.3 Использовать внутренние разрешения, определённые приложением, после проверки».

4.2.2.6 Запрет на включение чувствительных данных в липкие широковещательные передачи (обязательно)

Обычно широковещательная передача исчезает после её получения доступным широковещательным приёмником. С другой стороны, липкая широковещательная передача (включая липкую упорядоченную широковещательную передачу) не исчезает даже после получения доступным широковещательным приёмником и может быть получена с помощью registerReceiver(). Когда липкая широковещательная передача становится ненужной, её можно удалить в любое время с помощью removeStickyBroadcast().

Поскольку липкая широковещательная передача обычно используется с неявным намерением, она не может отправлять данные, указанные с параметром receiverPermission. По этой причине данные, отправленные с помощью липкой широковещательной передачи, могут быть доступны множеству неназванных приложений, включая вредоносные, поэтому чувствительные данные не должны отправляться таким образом. Обратите внимание, что липкая широковещательная передача была удалена в Android 5.0 (API Level 21).

4.2.2.7 Внимание: упорядоченные широковещательные передачи без указания receiverPermission не могут быть переданы (обязательно)

Упорядоченная широковещательная передача без указания параметра receiverPermission может быть принята неназванными приложениями, включая вредоносные. Упорядоченные широковещательные передачи используются для получения возвращаемых данных от широковещательных приёмников и выполнения нескольких широковещательных приёмов по очереди. Широковещательная передача отправляется упорядоченным широковещательным приёмникам в порядке приоритета. Таким образом, если высокоприоритетное вредоносное программное обеспечение первым принимает широковещательную передачу и выполняет abortBroadcast(), широковещательная передача не будет передана последующим широковещательным приёмникам.

4.2.2.8 Осторожность и безопасность обработки результатов, полученных от широковещательного приёмника (обязательно)

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

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

Обратитесь к разделу «3.2 Безопасное обращение с входными данными».

4.2.2.9 Предоставление вторичных материалов должно осуществляться с тем же уровнем защиты (обязательно)

При предоставлении защищённых информацией или функциональными возможностями материалов другим приложениям необходимо использовать те же разрешения для поддержания уровня защиты. В модели безопасности разрешений Android разрешения управляют только прямым доступом к защищённым материалам из приложения. Из-за этих характеристик полученные материалы могут быть предоставлены другим приложениям без объявления необходимых разрешений. Фактически, это то же самое, что и повторное предоставление разрешений, поскольку оно называется проблемой повторного предоставления разрешений. Обратитесь к разделу «5.2.3.4 Проблема повторного предоставления разрешений».