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

Приложение осуществляет сетевое взаимодействие по протоколу HTTP

Описание

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

Протокол HTTP передает данные в открытом, нешифрованном виде. Это означает, что любой злоумышленник, находящийся в той же сети, что и пользователь (например, публичный Wi-Fi, корпоративная сеть), или на пути следования трафика (провайдеры, узлы связи), может:

  • Перехватить (Sniffing): Прочитать все передаваемые данные, включая учетные данные (логины, пароли), токены аутентификации/сессии, персональную информацию (ФИО, адреса, телефоны), платежные реквизиты, содержимое сообщений и другие конфиденциальные сведения.
  • Модифицировать (Tampering): Изменить данные "на лету" как в запросах от приложения к серверу, так и в ответах от сервера к приложению. Злоумышленник может внедрить вредоносный код (например, JavaScript), подменить загружаемый контент, изменить суммы транзакций или перенаправить пользователя на фишинговый сайт.

Использование HTTP подрывает конфиденциальность и целостность передаваемых данных, что может привести к:

  • Компрометации учетных записей пользователей.
  • Краже личной и финансовой информации.
  • Финансовым потерям (для пользователя и компании).
  • Репутационному ущербу для разработчика и владельца приложения.
  • Распространению вредоносного ПО через модифицированные ответы.

Современные версии Android (начиная с Android 7/API 24) предоставляют механизм Network Security Configuration (NSC), который позволяет централизованно управлять политиками сетевой безопасности, включая принудительное использование HTTPS и запрет HTTP. Отсутствие или неверная настройка NSC часто является причиной использования HTTP.

Причины возникновения уязвимости

  • Устаревший код или зависимости: Использование старых библиотек, SDK или обращение к legacy backend-системам, которые не поддерживают HTTPS.
  • Настройки для разработки/тестирования: Использование HTTP в средах разработки или тестирования (например, для удобства отладки с прокси), которые случайно попадают в релизную сборку.
  • Явное разрешение HTTP: Некорректная настройка Network Security Configuration (NSC), явно разрешающая использование cleartext (HTTP) трафика для определенных доменов или для всего приложения без веской причины.
  • Недостаточная осведомленность: Разработчики могут не до конца понимать риски HTTP или считать внедрение HTTPS сложным.
  • Использование сторонних библиотек: Подключение SDK (например, рекламных), которые сами инициируют небезопасные HTTP-соединения без ведома разработчика основного приложения.

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

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

  1. Использовать Network Security Configuration (NSC) для запрета HTTP:

    • Основной метод: Начиная с Android 7 (API 24), используйте файл res/xml/network_security_config.xml для определения политики сетевой безопасности. Запретите HTTP (cleartext) трафик по умолчанию.
    • Создайте файл res/xml/network_security_config.xml: 
      <?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />
        </trust-anchors>
    </base-config>
    </domain-config>
    -->
</network-security-config>
    • Укажите этот файл в AndroidManifest.xml внутри тега <application>: 
      <application
    ...
    android:networkSecurityConfig="@xml/network_security_config">
    ...
</application>
    • Это заблокирует все HTTP-соединения для приложения (и его библиотек) на уровне ОС для Android 7+. Для старых версий Android (API < 24) запрет HTTP нужно реализовывать вручную через проверки URL в коде или настройки используемых HTTP-клиентов.

  2. Использовать HTTPS во всем коде и библиотеках:

    • Убедитесь, что все URL, используемые в вашем коде для сетевых запросов (HttpURLConnection, OkHttp, Retrofit, Volley и т.д.), используют схему https://.
    • Проверьте конфигурацию всех сторонних библиотек и SDK (рекламных, аналитических, платежных и др.) на предмет использования ими HTTP. Обновите их до версий, использующих HTTPS, или откажитесь от их использования, если безопасные версии недоступны.

  3. Обеспечить строгую проверку SSL-сертификатов:

    • Не отключайте проверку сертификатов! Никогда не используйте кастомные TrustManager или HostnameVerifier, которые принимают любые сертификаты или любые хостнеймы. Это полностью лишает смысла использование HTTPS и делает приложение уязвимым к атакам "человек посередине" (MITM).
    • Стандартной проверки, предоставляемой ОС и библиотеками (SSLSocketFactory.getDefault(), HttpsURLConnection.getDefaultHostnameVerifier()), обычно достаточно. Она проверяет цепочку доверия сертификата до системных или пользовательских корневых CA и соответствие имени хоста в сертификате запрошенному домену.

  4. Рассмотреть использование Certificate Pinning (для повышенной безопасности):

    • Контекст: Pinning (привязка сертификатов или публичных ключей) — это дополнительная мера защиты от MITM-атак, использующих скомпрометированные или ошибочно выпущенные доверенные сертификаты. Приложение доверяет только конкретным сертификатам/ключам для определенных доменов.
    • Когда использовать: Рекомендуется для приложений с высокими требованиями к безопасности (финансовые, медицинские, государственные), которые подключаются к ограниченному числу известных серверов.
    • Реализация (пример OkHttp): 
      import okhttp3.CertificatePinner;
import okhttp3.OkHttpClient;

// ... пины должны быть актуальными публичными ключами ваших серверов
String hostname = "secure.example.com";
CertificatePinner certificatePinner = new CertificatePinner.Builder()
    .add(hostname, "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") // Заменить реальным пином
    .add(hostname, "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=") // Можно добавить backup пин
    .build();

OkHttpClient client = new OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    // .protocols(Collections.singletonList(Protocol.HTTP_1_1)) // Если нужно отключить HTTP/2 или QUIC для пиннинга
    .build();

Дополнительные советы:

  • HSTS (HTTP Strict Transport Security): Настройте HSTS-заголовки на ваших серверах. Это инструкция для клиента (браузера или приложения) всегда использовать HTTPS для данного домена после первого успешного HTTPS-соединения. Хотя это серверная настройка, современные HTTP-клиенты в Android ее учитывают.
  • Мониторинг и логирование: Отслеживайте сетевую активность приложения на предмет аномалий или попыток использования HTTP.
  • Регулярные проверки: Используйте сканеры безопасности (SAST/DAST) и ручной анализ для выявления URL с HTTP и проверки конфигурации NSC.

Ссылки

  1. Android Developers: Network security configuration - Официальная документация по NSC.
  2. Android Developers: Security with HTTPS and SSL - Общие принципы безопасного сетевого взаимодействия.
  3. OWASP Mobile Security Testing Guide - Network Communication - Тестирование сетевого взаимодействия.
  4. OWASP Mobile Top 10: M3-Insecure Communication - Описание риска.
  5. OkHttp Recipe: Certificate Pinning - Пример реализации пиннинга в OkHttp.
К началу