7 опасных разрешений Android и как их избежать

Каждому владельцу Android‑устройства полезно помнить: «личное» не всегда остаётся личным. Покупка внутри приложения, установка приложения из ненадёжного источника или просто слишком широкие разрешения — всё это может привести к утечке имени, адреса, списка контактов и других персональных данных. Яркий пример — скандал с Path, когда приложение получало контакты пользователей без должного уведомления.

Многие пользователи не знакомы с тонкостями модели безопасности Android и не знают, чем она отличается от iOS. У Apple жёсткая модерация и строгие критерии качества. Android даёт разработчикам больше свободы, а приложения запрашивают у пользователя «разрешения» (permissions) на доступ к аппаратным компонентам и данным. Google не всегда подробно объясняет риски некоторых разрешений — и то, что пользователь не понимает, действительно может навредить.

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

Что такое разрешение и почему это важно

Разрешение (permission) — это явное право, которое приложение запрашивает у системы, чтобы использовать аппаратную функцию (камера, микрофон, GPS) или доступ к данным (контакты, SMS, логи). Оно — мост между приложением и теми ресурсами телефона, которые могут содержать конфиденциальную информацию.

Коротко: разрешение позволяет приложению делать что‑то, что без вашего согласия делать нельзя. В современной модели Android (начиная с Android 6.0) многие из этих разрешений запрашиваются «во время работы» — то есть при первом требовании функции, а не при установке. Это уменьшает экспозицию, но не устраняет проблему полностью.

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

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

Краткая справка по версиям Android и разрешениям

• Android 6.0 (Marshmallow) ввёл модель runtime permissions: пользователи подтверждают отдельные группы разрешений во время работы приложения.
• Ранние версии требовали всех разрешений на этапе установки — тогда сложно было отказаться от лишних доступов.
• Некоторые разрешения (например, доступ к камере или контактам) сохраняют смысл на всех версиях, но поведение и интерфейс подтверждения менялись.

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

Список: семь опасных разрешений, объяснение и рекомендации

Ниже — оригинальный список расширенный со сценариями злоупотребления и мерами защиты.

1. Authenticate accounts — «аутентификация аккаунтов»

Что это делает: приложение получает право «аутентифицировать» учётные записи в системе — то есть использовать встроенные механизмы для доступа к токенам, паролям и авторизации.

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

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

Как проверить: изучите профиль разработчика, отзывы и сайт; проверяйте, нужна ли функция аутентификации для основной задачи приложения.

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

2. Read sensitive log data — «чтение чувствительных логов»

Что это делает: даёт приложению доступ к логам системы и приложений, которые могут содержать технические детали, включая отладочную информацию и иногда — фрагменты введённых данных.

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

Когда оправдано: редко. Только для отладки специализированных инструментов разработки и диагностических приложений от доверенных производителей.

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

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

3. Read contacts — «чтение контактов»

Что это делает: доступ к списку контактов телефона, включая имена, номера, адреса и e‑mail.

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

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

Как проверить: задайте себе вопрос — нужна ли программе доступ к контактам для основной функции? Если нет — отказать.

Митигаторы: вручную указывайте доступные контакты (если приложение поддерживает) или используйте отдельную безопасную адресную книгу для важных контактов.

4. Write secure settings — «изменение системных настроек»

Что это делает: позволяет приложению читать и записывать защищённые системные настройки (например, параметры сети, поведение устройств).

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

Когда оправдано: крайне редко — в основном для системных утилит от производителя и приложений с привилегиями администратора.

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

Митигаторы: избегайте рутированных устройств, если вы не понимаете последствия; не давайте это разрешение сторонним приложениям.

5. Process outgoing calls — «обработка исходящих вызовов»

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

Риски: перехват номеров или подмена вызовов может привести к мошенничеству, утечке контактных данных, прослушиванию звонков.

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

Как проверить: проверьте, связан ли функционал приложения с совершением вызовов; иначе — не разрешайте.

Митигаторы: используйте проверенные VOIP‑клиенты, дайте разрешение только при необходимости.

6. Send SMS — «отправка SMS»

Что это делает: разрешение отправлять SMS и MMS от имени пользователя.

Риски: мошеннические приложения могут рассылать SMS на платные номера, подписывать вас на платные сервисы или распространять спам; счёт придёт владельцу телефона.

Когда оправдано: у приложений, которые специально отправляют сообщения (мессенджеры, сервисы уведомлений).

Как проверить: если приложение не связано с отправкой сообщений, доступ не нужен.

Митигаторы: ограничьте разрешение; проверяйте состояние баланса и при подозрениях — аннулируйте операторы и обратитесь в банк по вопросам списаний.

7. Read social stream — «чтение ленты социальных сетей»

Что это делает: даёт приложению доступ к данным, которые вы публикуете и получаете в социальных сетях, а также к метаданным о вашей активности.

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

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

Как проверить: изучите запрашиваемые области данных и настройте видимость ваших постов и информации в социалках.

Митигаторы: ограничьте объём публикуемой информации, используйте приватность на платформах, не связывайте чувствительные данные с публичными профилями.

Как взаимодействовать с разрешениями: практическое руководство и SOP

Ниже — стандартная операционная процедура (SOP) для проверки приложения до установки и сразу после неё.

Шаги перед установкой

1. Оцените источник: устанавливайте только из Google Play или других доверенных официальных каналов.
2. Проверьте профиль разработчика: сайт, контакты, история публикаций.
3. Прочитайте отзывы, особенно негативные — ищите упоминания о подозрительных запросах или фоновой активности.
4. На странице приложения в Google Play откройте раздел «Разрешения» (Permissions) и проверьте, какие группы запрошены.
5. Спросите себя: требуется ли приложению этот доступ для основной функции? Если нет — не устанавливайте.

Шаги сразу после установки

1. При первом запуске просмотрите все запросы разрешений и отклоняйте те, которые не связаны с функцией.
2. Проверьте потребление батареи и трафика в первые 48 часов — резкие всплески могут свидетельствовать о фоновой активности.
3. Используйте приложения‑сканеры разрешений (Permissions Explorer, No Permissions, aSpotCat, Stowaway) для анализа запасов прав (см. раздел «Инструменты»).
4. По мере необходимости отзовите разрешения в настройках Android: Приложения → Права доступа.

Критерии приёмки (после оценки)

• Приложение оправдывает каждый запрошенный доступ в коротком, понятном описании.
• Разработчик имеет положительную репутацию и историю обновлений.
• Потребление ресурсов адекватно ожидаемому поведению приложения.
• Нет сторонних SDK, которые собирают данные сверх необходимого (реклама, аналитика).

Important: если приложения просят необычно много прав при первой установке — это сигнал к отказу или дополнительной проверке.

Инструменты и альтернативы для анализа разрешений

• Permissions Explorer — позволяет фильтровать установленные приложения по запрошенным разрешениям.
• Stowaway — анализирует, «перепрошивает» ли приложение свои права; подходит для пользователей, умеющих работать с APK.
• No Permissions — показывает, какие права реально использует приложение, и помогает выявить «over‑privileged» приложения.
• aSpotCat — ещё один инструмент анализа прав.

Если у вас root‑доступ: приложения типа Permissions Denied дают более тонкий контроль, но root увеличивает общие риски безопасности. Не делайте root‑доступа без понимания последствий.

Роли и чеклисты: кто за что отвечает

Чеклист для обычного пользователя

• Устанавливать только из доверенных источников.
• Читать отзывы и описание разработчика.
• Отклонять лишние разрешения.
• Мониторить расход батареи и трафика.

Чеклист для продвинутого пользователя (power user)

• Проводить аудит установленных приложений раз в месяц.
• Использовать Permission Manager и анализаторы пакетов.
• Изолировать чувствительные контакты/пароли и не хранить их в сомнительных приложениях.

Чеклист для IT‑администратора (корпоративная среда)

• Внедрить MDM/EMM с политиками разрешений.
• Разрешать только утверждённые приложения («whitelist»).
• Проводить регулярные тренинги по безопасности для сотрудников.

Чеклист для разработчика

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

Инцидентный план: что делать при подозрении на компрометацию

1. Отключите устройство от сети (режим полёта).
2. Удалите недавно установленные приложения, особенно те, которые запросили много прав.
3. Сбросьте пароли для важных сервисов (почта, банковские приложения) с другого, безопасного устройства.
4. Проверьте аккаунты Google и другие подключённые сервисы на предмет сессий и доступов; отзовите неизвестные.
5. Если есть списания или подозрительная активность, свяжитесь с банком и оператором связи.
6. При необходимости выполните сброс к заводским настройкам после резервного копирования нужных данных.

Критерии отката: если приложение было системным или требовало root‑прав и удаление вызвало нестабильность — рассмотрите восстановление из резервной копии и профессиональную диагностику.

Когда разрешение оправдано: чеклист принятия решения

• Явная функциональная необходимость: доступ к камере для фото‑приложения.
• Прозрачное объяснение: разработчик объясняет цель доступа в описании или всплывающем окне.
• Техническая реализация: доступ не передаётся на сомнительные серверы.
• Репутация: разработчик и сервисы проверяемы.

Если хотя бы один пункт отсутствует — сомневайтесь.

Пара примеров, когда модель может «пасть»

Контрпример 1: приложение‑игра просит доступ к контактам. Возможно, разработчик добавил соцфункции (например «пригласи друга»), но чаще это признак профиля данных для рассылок.

Контрпример 2: медиаплеер просит отправлять SMS. Почти всегда это нечестное поведение.

Контрпример 3: официальное банковское приложение просит доступ к контактам и логам. Это необычно и требует встроенной проверки у банка.

Эти примеры показывают: спросите «почему?» и добивайтесь конкретного ответа.

Технические и юридические заметки (GDPR и приватность)

Юридическая сторона: в регионах с требованиями о защите данных (например, GDPR в ЕС) приложения обязаны давать прозрачную информацию о собираемых данных и основаниях их обработки. Как пользователь, вы имеете права на доступ, исправление и удаление персональных данных. В случае сомнений — воспользуйтесь правами на удаление данных и обратитесь к поддержке разработчика.

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

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

Ментальные модели и эвристики безопасности

1. Минимальный привилегированный доступ: давайте приложению ровно столько прав, сколько нужно для выполнения его основной функции.
2. Не доверяйте внешнему виду: красивый интерфейс не гарантирует безопасность.
3. Принцип «первого отказа»: если не уверены — отказывайте; позже разрешение всегда можно дать.
4. Изоляция чувствительных задач: храните пароли и банковские операции в отдельных приложениях и не используйте их в сторонних сервисах.

Эти простые правила помогают быстро оценивать риск.

Таблица совместимости и заметки по версиям Android

Тесты и критерии приёмки для корпоративного использования

• Тест 1: Установка приложения и отслеживание запросов разрешений. Ожидаемый результат: только утверждённые группы разрешений запрошены.
• Тест 2: Наблюдение трафика после установки. Ожидаемый результат: данные передаются только на авторизованные домены и в шифрованном виде.
• Тест 3: Проверка поведения при отказе в разрешении. Ожидаемый результат: приложение корректно обрабатывает отказ без скрытой деградации.

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

Быстрый чеклист перед установкой (печатаемый шаблон)

• Источник: Google Play или официальный сайт
• Проверка разработчика: сайт и история публикаций
• Отзывы: прочитать 10‑20 последних, обратить внимание на жалобы
• Разрешения: соответствуют ли функциям приложения?
• Трафик и батарея: мониторинг первые 48 часов
• Резервная копия: на случай проблем

Сохраните этот чеклист в заметках и используйте перед каждой новой установкой.

Часто задаваемые вопросы (FAQ)

Как понять, что разрешение «ненужное»?

Если функция явно не связана с основной задачей приложения (например, калькулятор запрашивает доступ к SMS), это ненужное разрешение.

Можно ли отозвать разрешение после установки?

Да. В Android: Настройки → Приложения → выберите приложение → Права доступа → отключите нужные разрешения.

Что опаснее: сторонний магазин или Play Store?

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

Что делать, если приложение уже отправляет платные SMS?

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

Заключение и краткое резюме

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

И помните: знание о том, какие права вы даёте, — это первая линия защиты.

Image Credits: Parchment via MorgueFile.com; Robot via MorgueFile.com; Stop via MorgueFile.com