Передача данных в виде открытого текста

Категория OWASP: MASVS-NETWORK: Network Communication

Обзор

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

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

Влияние

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

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

Риск: незашифрованные каналы связи

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

Предотвращение атак

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

Особые риски

В этом разделе собраны риски, которые требуют нестандартных стратегий устранения или были устранены на определенном уровне SDK. Они приведены здесь для полноты картины.

Риск: HTTP

Рекомендации в этом разделе относятся только к приложениям, предназначенным для Android 8.1 (API уровня 27) или более ранних версий. Начиная с Android 9 (уровень API 28) HTTP-клиенты, такие как URLConnection, Cronet и OkHttp, требуют использования HTTPS, поэтому поддержка открытого текста по умолчанию отключена. Однако имейте в виду, что другие клиентские библиотеки HTTP, такие как Ktor, вряд ли будут применять эти ограничения к открытому тексту, и их следует использовать с осторожностью.

Предотвращение атак

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

XML

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

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

Риск: FTP

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

Предотвращение атак

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

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

  • Аутентификация. Пользователи должны проходить аутентификацию с помощью безопасных механизмов, таких как OAuth 2.0. Базовая аутентификация обычно не рекомендуется, поскольку она не предоставляет механизмов управления сеансами и, если учетные данные хранятся неправильно, может быть декодирована из Base64.
  • Авторизация. Пользователи должны иметь доступ только к необходимым ресурсам в соответствии с принципом минимальных привилегий. Для этого можно использовать решения по контролю доступа к объектам приложения.
  • Убедитесь, что используются самые современные наборы шифров, соответствующие рекомендациям по безопасности. Например, для HTTPS-соединений можно использовать протокол TLSv1.3 с обратной совместимостью.

Риск: нестандартные протоколы связи

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

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

С другой стороны, если вы реализуете широко известные протоколы, такие как HTTPS, без использования ОС или сторонних библиотек, которые регулярно обновляются, то повышается вероятность ошибок в коде. Из-за этого вам может быть сложно или даже невозможно обновить реализованный протокол, когда это потребуется. Кроме того, это может привести к тем же уязвимостям, что и использование собственных протоколов.

Предотвращение атак

Используйте поддерживаемые библиотеки для реализации известных протоколов связи

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

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

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

Использование SFTP

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

  • SFTP поддерживает разные типы аутентификации. Вместо аутентификации на основе пароля следует использовать способ аутентификации с открытым ключом. Такие ключи должны создаваться и храниться безопасным образом. Для этого рекомендуется использовать Android Keystore.
  • Убедитесь, что поддерживаемые шифры соответствуют рекомендациям по безопасности.

Ресурсы