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

Категория 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, следует использовать библиотеки операционной системы или поддерживаемые сторонние библиотеки.

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

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

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

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

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

Ресурсы