明文通信
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
OWASP 类别:MASVS-NETWORK:网络通信
概览
在 Android 应用中允许明文网络通信,意味着监控网络流量的任何人都可以查看和操纵正在传输的数据。如果传输的数据包含敏感信息(例如密码、信用卡号或其他个人信息),这就会成为一个漏洞。
无论您是否发送敏感信息,使用明文都可能是一个漏洞,因为明文流量也可能通过网络攻击(例如 ARP 或 DNS 投毒)来操纵,因此可能会使攻击者影响应用的行为。
影响
当 Android 应用通过网络发送或接收明文数据时,监控网络的任何人都可以拦截并读取这些数据。如果这些数据包含敏感信息(例如密码、信用卡号或个人消息),可能会导致身份窃取、金融欺诈和其他严重问题。
例如,应用如果以明文形式传输密码,可能会将这些凭据泄露给拦截流量的恶意操作者。然后,攻击者可能会利用这些数据在未经授权的情况下访问用户账号。
风险:未加密的通信渠道
通过未加密的通信通道传输数据会泄露设备和应用端点之间共享的数据。上述数据可能会被攻击者拦截并可能被修改。
缓解措施
数据应通过加密的通信通道发送。对于不提供加密功能的协议,应使用安全协议的替代方案。
特定风险
本部分将汇总符合以下条件的风险:需要采用非标准的缓解策略,或原本已在特定 SDK 级别得到缓解,而为了提供完整信息才列在此处。
风险信号:HTTP
此部分中的指南仅适用于以 Android 8.1(API 级别 27)或更低版本为目标平台的应用。从 Android 9(API 级别 28)开始,网址Connection、Cronet 和 OkHttp 等 HTTP 客户端会强制使用 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>
此选项有助于防止应用因外部源(如后端服务器)提供的网址发生变化而意外回归。
风险:FTP
使用 FTP 协议在设备之间交换文件会带来多种风险,其中最严重的是通信通道缺少加密。应改用更安全的替代方案,例如 SFTP 或 HTTPS。
缓解措施
在应用中通过互联网实现数据交换机制时,您应使用 HTTPS 等安全协议。Android 提供了一组 API,支持开发者创建客户端-服务器逻辑。您可以使用传输层安全协议 (TLS) 来实现安全保护,确保两个端点之间的数据交换经过加密,从而防止恶意用户窃听通信内容和检索敏感数据。
通常,客户端-服务器架构依赖于开发者拥有的 API。如果您的应用依赖于一组 API 端点,请遵循以下安全最佳实践来保护 HTTPS 通信,从而确保深度安全:
- 身份验证 - 用户应使用 OAuth 2.0 等安全机制进行身份验证。通常不建议使用基本身份验证,因为它不提供会话管理机制,并且如果凭据存储不当,可以从 Base64 解码。
- 授权 - 应根据最小权限原则限制用户仅访问预期资源。为应用的资源采用谨慎的访问权限控制解决方案即可实现这一点。
- 确保使用经过深思熟虑且最新的加密套件,遵循安全性最佳实践。例如,考虑支持 TLSv1.3 协议,并在必要时为 HTTPS 通信提供向后兼容性。
风险:自定义通信协议
实现自定义通信协议或尝试手动实现知名协议都很危险。
虽然自定义协议可让开发者根据预期需求定制独特的解决方案,但开发过程中发生的任何错误都可能导致安全漏洞。例如,在开发会话处理机制时出现错误,可能会导致攻击者能够窃听通信内容,并动态检索敏感信息。
另一方面,如果不使用操作系统或维护良好的第三方库来实现 HTTPS 等众所周知的协议,则会增加引入编码错误的可能性,这可能会导致在需要时难以(如果不是完全不可能的话)更新您实现的协议。此外,这可能会引入与使用自定义协议相同类型的安全漏洞。
缓解措施
使用维护的库实现众所周知的通信协议
如需在应用中实现 HTTPS 等众所周知的协议,应使用操作系统库或受维护的第三方库。
这样一来,开发者便可以安全地选择经过全面测试、随着时间的推移不断改进并且会持续接收安全更新以修复常见漏洞的解决方案。
此外,通过选择众所周知的协议,开发者可以获享跨各种系统、平台和 IDE 的广泛兼容性,从而降低开发过程中出现人为错误的可能性。
使用 SFTP
此协议会对传输中的数据进行加密。使用此类文件交换协议时,应考虑采取其他措施:
- SFTP 支持不同类型的身份验证。应使用公钥身份验证方法,而不是基于密码的身份验证。此类密钥应以安全的方式创建和存储,建议为此使用 Android 密钥库。
- 确保支持的密码遵循安全最佳实践。
资源
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-26。
[null,null,["最后更新时间 (UTC):2025-07-26。"],[],[],null,["# Cleartext communications\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-NETWORK: Network Communication](https://mas.owasp.org/MASVS/08-MASVS-NETWORK)\n\nOverview\n--------\n\nAllowing cleartext network communications in an Android app means that anyone\nmonitoring network traffic can see and manipulate the data that is being\ntransmitted. This is a vulnerability if the transmitted data includes sensitive\ninformation such as passwords, credit card numbers, or other personal\ninformation.\n\nRegardless of if you are sending sensitive information or not, using cleartext\ncan still be a vulnerability as cleartext traffic can also be manipulated\nthrough network attacks such as ARP or DNS poisoning, thus potentially enabling\nattackers to influence the behavior of an app.\n\nImpact\n------\n\nWhen an Android application sends or receives data in cleartext over a network,\nanyone who is monitoring the network can intercept and read that data. If this\ndata includes sensitive information such as passwords, credit card numbers, or\npersonal messages, this can lead to identity theft, financial fraud, and other\nserious problems.\n\nFor example, an app transmitting passwords in cleartext could\nexpose these credentials to a malicious actor intercepting the traffic. This\ndata could then be used to gain unauthorized access to the user's accounts.\n\nRisk: Unencrypted communication channels\n----------------------------------------\n\nTransmitting data over unencrypted communication channels exposes the data\nshared between the device and the application endpoints. Said data can be\nintercepted and potentially modified by an attacker.\n\n### Mitigations\n\nData should be sent over encrypted communication channels. Secure protocols\nshould be used as an alternative to protocols that don't offer encryption\ncapabilities.\n\nSpecific Risks\n--------------\n\nThis section gathers risks that require non-standard mitigation strategies or\nwere mitigated at certain SDK level and are here for completeness.\n\n### Risk: HTTP\n\nThe guidance in this section applies only to apps that target Android 8.1 (API\nlevel 27) or earlier. Starting with Android 9 (API level 28), HTTP Clients such\nas URLConnection, [Cronet](/develop/connectivity/cronet), and [OkHttp](https://square.github.io/okhttp/) enforce the use of\nHTTPS, therefore cleartext support is disabled by default. However, be aware\nthat other HTTP Client libraries such as [Ktor](https://ktor.io/) are unlikely to\nenforce these restrictions on cleartext and should be used with care.\n\n#### Mitigations\n\nUse the [NetworkSecurityConfig.xml](/training/articles/security-config#CleartextTrafficPermitted) feature to opt-out of cleartext traffic\nand enforce HTTPS for your app, with exceptions for only the specific domains\nrequired (usually for debugging purposes): \n\n### Xml\n\n \u003c?xml version=\"1.0\" encoding=\"utf-8\"?\u003e\n \u003cnetwork-security-config\u003e\n \u003cbase-config cleartextTrafficPermitted=\"false\"\u003e\n \u003cdomain-config cleartextTrafficPermitted=\"true\"\u003e\n \u003cdomain includeSubdomains=\"true\"\u003edebug.domain.com\u003c/domain\u003e\n \u003c/domain-config\u003e\n \u003c/network-security-config\u003e\n\nThis option helps prevent accidental regressions in apps due to changes in URLs\nprovided by external sources such as backend servers.\n\n*** ** * ** ***\n\n### Risk: FTP\n\nUsing the FTP protocol to exchange files between devices presents several risks,\nthe most significant being the lack of encryption over the communication\nchannel. Safer alternatives such as SFTP or HTTPS should be used instead.\n\n#### Mitigations\n\nWhen implementing data exchange mechanisms over the internet in your\napplication, you should use a secure protocol such as HTTPS. Android makes a\n[set of APIs](/develop/connectivity/network-ops/connecting) available that allow developers to create a client-server\nlogic. This can be secured using [Transport Layer Security (TLS)](/privacy-and-security/security-ssl), ensuring\nthat data exchange between two endpoints is encrypted, therefore preventing\nmalicious users from eavesdropping on communications and retrieving sensitive\ndata.\n\nCommonly, client-server architectures rely on developer-owned APIs. If your\napplication depends on a set of API endpoints, ensure security-in-depth by\nfollowing these security best practices to protect HTTPS communications:\n\n- Authentication -- Users should authenticate themselves using secure mechanisms such as [OAuth 2.0](https://developers.google.com/identity/protocols/oauth2/native-app). Basic authentication is generally discouraged, as it doesn't provide session management mechanisms and, if credentials are improperly stored, can be decoded from Base64.\n- Authorization -- Users should be restricted to access only intended resources following the principle of least-privilege. This can be implemented by adopting careful access control solutions for the application's assets.\n- Ensure that thoughtful and most recent cipher suites are used, following security best practices. For example, consider supporting the [TLSv1.3\n protocol](https://wiki.mozilla.org/Security/Server_Side_TLS) with backward compatibility, if needed, for HTTPS communications.\n\n*** ** * ** ***\n\n### Risk: Custom-Communication Protocols\n\nImplementing custom communication protocols, or trying to implement well-known\nones manually, can be dangerous.\n\nWhile custom protocols allow developers to tailor a unique solution that adapts\nto the intended needs, any error during the development process can potentially\nresult in security vulnerabilities. For example, errors in developing session\nhandling mechanisms can potentially result in attackers being able to eavesdrop\non communications, and retrieve sensitive information on the fly.\n\nOn the other hand, implementing well-known protocols such as HTTPS without using\nOS or well-maintained third-party libraries, increases the likelihood of\nintroducing coding errors that may make it difficult, if not impossible, to\nupdate the protocol that you implemented when needed. Additionally, this can\nintroduce the same kind of security vulnerabilities as using custom protocols.\n\n#### Mitigations\n\n##### Use maintained libraries to implement well-known communication protocols\n\nTo implement well-known protocols such as HTTPS in your application, OS\nlibraries or maintained third-party libraries should be used.\n\nThis gives developers the security of opting for solutions that have been\nthoroughly tested, were improved over time, and are continuously receiving\nsecurity updates to fix common vulnerabilities.\n\nIn addition, by opting for well-known protocols, developers benefit from broad\ncompatibility across various systems, platforms, and IDEs, reducing the\nlikelihood of human errors during the development process.\n\n##### Use SFTP\n\nThis protocol encrypts the data in transit. Additional measures should be taken\ninto consideration when using this kind of file exchange protocol:\n\n- SFTP supports different kinds of authentication. Instead of password-based authentication, the public key authentication method should be used. Such keys should be securely created and stored, [Android Keystore](/privacy-and-security/keystore) is recommended for this purpose.\n- Ensure that supported ciphers follow security best practices.\n\n*** ** * ** ***\n\nResources\n---------\n\n- [Ktor](https://ktor.io/)\n- [Perform network operations using Cronet](/develop/connectivity/cronet)\n- [OkHttp](https://square.github.io/okhttp/)\n- [Cleartext Traffic Opt-out for Network Security Configuration](/training/articles/security-config#CleartextTrafficPermitted)\n- [Connect to the network](/develop/connectivity/network-ops/connecting)\n- [Security with network protocols](/privacy-and-security/security-ssl)\n- [OAuth 2.0 for Mobile \\& Desktop Apps](https://developers.google.com/identity/protocols/oauth2/native-app)\n- [HTTP Over TLS RFC](https://www.ietf.org/rfc/rfc2818.txt)\n- [HTTP Authentication Schemes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#authentication_schemesl)\n- [Mozilla web security recommendations](https://infosec.mozilla.org/guidelines/web_security)\n- [Mozilla SSL recommended configuration generator](https://ssl-config.mozilla.org/)\n- [Mozilla Server Side TLS recommendations](https://wiki.mozilla.org/Security/Server_Side_TLS)\n- [OpenSSH main manual page](https://www.openssh.com/manual.html)\n- [SSH RFC, which details the configurations and schemes that can be used for this protocol](https://www.ietf.org/rfc/rfc4251.txt)\n- [Mozilla OpenSSH security recommendations](https://infosec.mozilla.org/guidelines/openssh.html)\n- [Android Keystore system](/privacy-and-security/keystore)"]]