Перейти к содержанию

Возможность создания резервной копии приложения

Критичность: СРЕДНИЙ
Способ обнаружения: SAST, APK

Описание

Приложение Android, собранное с включенной опцией создания резервной копии (флаг android:allowBackup="true" в AndroidManifest.xml), разрешает системе включать данные приложения в механизмы резервного копирования. В этом случае содержимое внутренней директории приложения (базы данных, SharedPreferences, файлы) может покинуть «песочницу» приложения: попасть в облачный бэкап, быть скопированным на другое устройство или, при определённых условиях, извлечённым локально. Помимо чтения данных злоумышленник потенциально может изменить содержимое файлов и восстановить приложение из модифицированного бэкапа, что в ряде случаев приводит к компрометации пользовательских данных и обходу клиентской логики.

Важно: по умолчанию (если атрибут не задан явно) allowBackup считается включённым.

Пример уязвимого кода (файл AndroidManifest.xml):

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.appsec.android.activity.privateactivity">
    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name">
        <activity
            android:name=".PrivateActivity"
            android:label="@string/app_name"
            android:exported="false" />
    </application>
</manifest>

Современные механизмы резервного копирования

При включённом allowBackup данные приложения попадают в один или несколько штатных механизмов Android:

  • Auto Backup for Apps (с Android 6.0 / API 23) — автоматическое резервное копирование до 25 МБ данных приложения в облако (Google Drive пользователя). Это основной актуальный канал утечки при allowBackup="true".
  • Key/Value Backup (Android Backup Service) — устаревший механизм на базе BackupAgent, требует регистрации ключа Backup API.
  • Device-to-Device (D2D) transfer — прямой перенос данных при настройке нового устройства; данные приложения переносятся, даже если облачный бэкап отключён.

Устаревший вектор: adb backup / adb restore

Исторически данные извлекались локально командой adb backup:

adb backup -f mybackup.ab com.appsec.android

с последующим преобразованием в обычный архив (утилита android-backup-extractor или dd+openssl) и обратной упаковкой/восстановлением через adb restore.

Механизм adb backup/adb restore фактически прекращён

Транспорт adb backup/adb restore для данных приложений перестал работать начиная с Android 12 (API 31): даже при android:allowBackup="true" пользовательские данные приложения в архив adb backup больше не включаются (в архиве остаются по сути только APK при соответствующих флагах). Поэтому adb backup следует рассматривать как legacy-вектор, актуальный лишь для устройств с Android 11 и ниже либо для отладочных (debuggable) сборок.

Это не снимает дефект: при allowBackup="true" на актуальных версиях ОС данные по-прежнему утекают через Auto Backup (в облако) и D2D-перенос. Поэтому акцент при оценке риска смещается с adb backup на облачное резервное копирование и перенос на новое устройство.

Рекомендации

  1. Явно отключите резервное копирование, если приложение хранит чувствительные данные. Установите android:allowBackup="false" (а также android:fullBackupContent="false" для совместимости со старыми API). Это закрывает и Auto Backup, и D2D-перенос, и legacy-каналы.

    <?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.appsec.android.activity.privateactivity">
    <application
        android:allowBackup="false"
        android:fullBackupContent="false"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name">
        <activity
            android:name=".PrivateActivity"
            android:label="@string/app_name"
            android:exported="false" />
    </application>
</manifest>

  2. Если резервное копирование нужно для UX — используйте allow-list через правила бэкапа, а не отключайте всё подряд. Начиная с Android 12 (API 31) задавайте отдельные правила для облачного бэкапа и для D2D-переноса через атрибуты android:dataExtractionRules; для API 23–30 — android:fullBackupContent. Исключайте из бэкапа всё чувствительное (токены, ключи, БД с ПДн):

    <!-- res/xml/data_extraction_rules.xml (API 31+) -->
<data-extraction-rules>
    <cloud-backup>
        <exclude domain="sharedpref" path="auth_tokens.xml" />
        <exclude domain="database" path="secrets.db" />
    </cloud-backup>
    <device-transfer>
        <exclude domain="sharedpref" path="auth_tokens.xml" />
    </device-transfer>
</data-extraction-rules>

<!-- res/xml/backup_rules.xml (API 23–30, атрибут android:fullBackupContent) -->
<full-backup-content>
    <exclude domain="sharedpref" path="auth_tokens.xml" />
    <exclude domain="database" path="secrets.db" />
</full-backup-content>

Подключение в манифесте:

    <application
        android:allowBackup="true"
        android:fullBackupContent="@xml/backup_rules"
        android:dataExtractionRules="@xml/data_extraction_rules"
        ... >

  1. Не полагайтесь на бэкап как на «безопасное» хранилище. Чувствительные данные шифруйте на устройстве через Android Keystore и EncryptedSharedPreferences/Jetpack Security; при обработке персональных данных учитывайте требования 152-ФЗ (минимизация и защита ПДн при их возможном попадании в бэкап).

  2. Учитывайте отладочные сборки. В debuggable-сборках локальное извлечение данных остаётся возможным независимо от версии ОС; не оставляйте отладочные сборки и тестовые данные в публичном доступе.

Ссылки

  1. Android Developers — Back up user data with Auto Backup
  2. Android Developers — <application>: атрибут allowBackup
  3. Android Developers — Changes to backup and restore in Android 12 (adb backup ограничен)
  4. Android Developers — Define device-to-device transfer and backup rules
  5. OWASP MASTG — Testing Data Storage (Android)
  6. OWASP MASVS — MASVS-STORAGE
  7. android-backup-extractor (legacy-инструмент для adb backup)
К началу