Безопасность приложений в эпоху агентов

Здравствуйте! Меня зовут Кристина.

Привет, а я Сабс.

и сегодня мы поговорим о безопасности в эпоху агентов.

За последний год мы выплатили более двух миллионов долларов в рамках программы Android Bug Hunters и более 200 тысяч долларов за уязвимости в мобильных приложениях.

В современную эпоху агентов безопасность приложений постоянно развивается.

Итак, давайте поговорим об инструментах, которые помогут нам быстро и эффективно решать эти проблемы.

Чтобы улучшить работу агентов в сфере безопасности Android, недостаточно просто составить более эффективный запрос.

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

Сейчас 16:30.

В четверг.

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

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

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

Каков естественный инстинкт?

Мы передаем это предупреждение агенту и просим его исправить проблему.

Но у агентного инструмента, работающего без контекста проекта, есть три слепых зоны.

Возможно, он не знает, что ваше приложение создано из динамических модулей функций или наборов с несколькими APK.

Она видит файл, а не отправленный артефакт.

Он может не знать или не иметь возможности отследить поток данных от вашего пользовательского интерфейса Kotlin до общей логики KMP и вызовов JNI на C++.

Он видит только один слой.

Наконец, он может не знать о минимальной версии SDK или разновидностях сборки Gradle.

Мы указали агенту на приложение и попросили провести аудит безопасности.

Было получено шесть результатов.

И вот в чём дело.

Каждый из них прав.

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

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

Теперь вы масштабируете это в реальную базу кода с большим количеством предупреждений, и в каждом pull-запросе у вас возникнет соблазн использовать suppress lint.

Вы можете не успеть объединить изменения или даже пропустить уязвимость.

И именно так реальные уязвимости проскальзывают мимо.

Инструмент не был небрежным, он был осторожным, но осторожность – это не то же самое, что полезность.

Давайте рассмотрим конкретный пример.

Например, вы можете попросить агента проверить все экспортированные компоненты в приложении на предмет перенаправления намерений.

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

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

А без инструкций, относящихся к Android, у агента нет стратегии для ответа на этот вопрос.

То есть он подбирает пароли.

Она может считывать модули, которые ничего не экспортируют.

Она может заново вывести из первого принципа, что делает перенаправление намерения уязвимым.

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

Вы платите за исследование, а не за анализ.

Навык – это то, что обеспечивает недостающую стратегию.

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

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

Сейчас мы запустили два навыка безопасности: Intent Security и Permissions.

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

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

Каждый экспортированный компонент и каждый отложенный интент, который вы передаете, – это потенциальный способ для кого-то действовать через вас.

Этот навык помогает защититься от этого.

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

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

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

и запрашивает слишком много разрешений.

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

Используйте его с Android CLI, а затем спросите: "Проверить безопасность намерений".

Нет конфигурации.

Нет настройки правил.

Поэтому в выходных данных не будет стены предупреждений.

Это отзыв.

Вот ошибка, вот почему она важна для вашего приложения, а вот исправление.

И вот совет от профессионалов.

Используйте Android CLI, чтобы легко находить и устанавливать инструменты.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

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

Он учитывает минимальную версию SDK, чтобы исправление компилировалось, а также реальные пути к файлам и номера строк.

Вот какой отзыв вы получите.

Он указывает на точный файл и строку, объясняет реальную угрозу и объяснение изменения, а не просто Lint говорит об этом.

Gemini укажет, какой навык был использован.

Он прочитал конфигурацию сборки, увидел минимальную версию SDK 26 и выбрал ContextCompat, чтобы исправление работало, и передал вам diff, чтобы вы могли его применить.

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

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

Теперь поговорим о соблюдении правил в отношении приложений.

Предположим, вы начинающий разработчик приложений и хотите опубликовать свой продукт в Google Play.

Заполнение формы "Безопасность данных" – важный шаг при запуске приложения. Давайте воспользуемся всеми доступными инструментами, чтобы сделать это правильно перед отправкой приложения.

Навык "Правила Google Play" выполняет статический анализ базы кода.

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

Это поможет вам выявить потенциальные нарушения правил Google Play до отправки приложения на проверку и ускорить ее.

Рабочий процесс аналогичен другим навыкам, которые мы обсуждали: импортируйте его, а затем спросите: "Проверьте это приложение на соответствие правилам Google Play, прежде чем я его отправлю".

Справа вы увидите скриншот примера отчета, а ниже – команды Android CLI для его установки.

android skills list
android skills add play-policy-insights

Итак, все, о чем мы говорили до сих пор, происходит до того, как вы отправляете: аудит намерений, проверка разрешений, проверка соответствия.

Это безопасность во время сборки, и она очень важна.

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

Play Integrity API позволяет во время выполнения получить ответы на три вопроса, на которые ваше приложение не может ответить самостоятельно: "Является ли эта сборка приложения подлинной и неизмененной?",

Запускается ли приложение на немодифицированном устройстве Android?

Это аккаунт пользователя Google Play?

Play Integrity API позволяет получать оценки целостности приложения, устройства и не только.

Мы не только упростили и ускорили публикацию безопасных приложений, но и сделали так, чтобы вам было проще защитить доход и репутацию.

Защитите свой бизнес от мошенничества и злоупотреблений.

На новой панели управления "Защищено Google Play" можно настраивать и отслеживать защиту целостности, распространения и монетизации.

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

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

Сначала рассмотрим защиту одноразовых кодов из SMS.

Допустим, вы хотите реализовать в своем приложении проверку пользователей по SMS и отправлять коды подтверждения.

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

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

SMS Retriever API позволяет приложению автоматически проверять одноразовые коды без широких разрешений на доступ к SMS.

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

Если вы не можете контролировать формат сообщений, используйте API согласия пользователя для SMS.

Система показывает однократную подсказку.

Пользователь нажимает "Разрешить" или "Запретить". Если он разрешает, вы получаете одно сообщение.

Разрешение на доступ к SMS по-прежнему не требуется.

Некоторым приложениям доступ к точному местоположению нужен только один раз.

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

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

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

В июне мы запустили первую альфа-версию библиотеки Jetpack для кнопки геолокации.

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

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

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

Справа показан код Jetpack для реализации.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

Здесь мы создаем кнопку геолокации и инициализируем обратный вызов.

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

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

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

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

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

Ниже мы расскажем, как интегрировать его в приложение.

Вам нужно запросить разрешение, отправить запрос в режим Дополнительной защиты и проверить, включил ли пользователь этот режим, вызвав системный сервис Advanced Protection Mode Manager на устройстве.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

Затем вы можете отслеживать изменения во время выполнения, зарегистрировав обратный вызов.

Сегодня мы обсудили много тем.

Вот ссылки на статьи, в которых вы найдете подробную информацию:

Мы сделаем небольшую паузу, чтобы вы могли записать нужные URL.

Спасибо!

Спасибо!