Cleartext communications

OWASP category: MASVS-NETWORK: Network Communication

Overview

Allowing cleartext network communications in an Android app means that anyone monitoring network traffic can see and manipulate the data that is being transmitted. This is a vulnerability if the transmitted data includes sensitive information such as passwords, credit card numbers, or other personal information.

Regardless of if you are sending sensitive information or not, using cleartext can still be a vulnerability as cleartext traffic can also be manipulated through network attacks such as ARP or DNS poisoning, thus potentially enabling attackers to influence the behavior of an app.

Impact

When an Android application sends or receives data in cleartext over a network, anyone who is monitoring the network can intercept and read that data. If this data includes sensitive information such as passwords, credit card numbers, or personal messages, this can lead to identity theft, financial fraud, and other serious problems.

For example, an app transmitting passwords in cleartext could expose these credentials to a malicious actor intercepting the traffic. This data could then be used to gain unauthorized access to the user's accounts.

Risk: Unencrypted communication channels

Transmitting data over unencrypted communication channels exposes the data shared between the device and the application endpoints. Said data can be intercepted and potentially modified by an attacker.

Mitigations

Data should be sent over encrypted communication channels. Secure protocols should be used as an alternative to protocols that don't offer encryption capabilities.

Specific Risks

This section gathers risks that require non-standard mitigation strategies or were mitigated at certain SDK level and are here for completeness.

Risk: HTTP

The guidance in this section applies only to apps that target Android 8.1 (API level 27) or earlier. Starting with Android 9 (API level 28), HTTP Clients such as URLConnection, Cronet, and OkHttp enforce the use of HTTPS, therefore cleartext support is disabled by default. However, be aware that other HTTP Client libraries such as Ktor are unlikely to enforce these restrictions on cleartext and should be used with care.

Mitigations

Use the NetworkSecurityConfig.xml feature to opt-out of cleartext traffic and enforce HTTPS for your app, with exceptions for only the specific domains required (usually for debugging purposes):

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>

This option helps prevent accidental regressions in apps due to changes in URLs provided by external sources such as backend servers.

Risk: FTP

Using the FTP protocol to exchange files between devices presents several risks, the most significant being the lack of encryption over the communication channel. Safer alternatives such as SFTP or HTTPS should be used instead.

Mitigations

When implementing data exchange mechanisms over the internet in your application, you should use a secure protocol such as HTTPS. Android makes a set of APIs available that allow developers to create a client-server logic. This can be secured using Transport Layer Security (TLS), ensuring that data exchange between two endpoints is encrypted, therefore preventing malicious users from eavesdropping on communications and retrieving sensitive data.

Commonly, client-server architectures rely on developer-owned APIs. If your application depends on a set of API endpoints, ensure security-in-depth by following these security best practices to protect HTTPS communications:

  • Authentication – Users should authenticate themselves using secure mechanisms such as OAuth 2.0. Basic authentication is generally discouraged, as it doesn't provide session management mechanisms and, if credentials are improperly stored, can be decoded from Base64.
  • 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.
  • Ensure that thoughtful and most recent cipher suites are used, following security best practices. For example, consider supporting the TLSv1.3 protocol with backward compatibility, if needed, for HTTPS communications.

Risk: Custom-Communication Protocols

Implementing custom communication protocols, or trying to implement well-known ones manually, can be dangerous.

While custom protocols allow developers to tailor a unique solution that adapts to the intended needs, any error during the development process can potentially result in security vulnerabilities. For example, errors in developing session handling mechanisms can potentially result in attackers being able to eavesdrop on communications, and retrieve sensitive information on the fly.

On the other hand, implementing well-known protocols such as HTTPS without using OS or well-maintained third-party libraries, increases the likelihood of introducing coding errors that may make it difficult, if not impossible, to update the protocol that you implemented when needed. Additionally, this can introduce the same kind of security vulnerabilities as using custom protocols.

Mitigations

Use maintained libraries to implement well-known communication protocols

To implement well-known protocols such as HTTPS in your application, OS libraries or maintained third-party libraries should be used.

This gives developers the security of opting for solutions that have been thoroughly tested, were improved over time, and are continuously receiving security updates to fix common vulnerabilities.

In addition, by opting for well-known protocols, developers benefit from broad compatibility across various systems, platforms, and IDEs, reducing the likelihood of human errors during the development process.

Use SFTP

This protocol encrypts the data in transit. Additional measures should be taken into consideration when using this kind of file exchange protocol:

  • 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 is recommended for this purpose.
  • Ensure that supported ciphers follow security best practices.

Resources