Открытый текст

Категория OWASP: MASVS-NETWORK: Сетевая связь

Обзор

Разрешение сетевых коммуникаций в открытом виде в приложении 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-интерфейсов , которые позволяют разработчикам создавать логику клиент-сервер. Это можно защитить с помощью Transport Layer Security (TLS) , гарантируя, что обмен данными между двумя конечными точками зашифрован, что предотвращает подслушивание сообщений злоумышленниками и получение конфиденциальных данных.

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

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

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

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

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

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

Смягчения

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

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

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

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

Используйте SFTP

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

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

Ресурсы