Cleartext Transmission of Sensitive Data

Description

Cleartext transmission of sensitive data (CWE-319 — Cleartext Transmission of Sensitive Information) occurs when an application sends security-relevant information — credentials, session tokens, personal data, financial information, or API keys — over an unencrypted or improperly secured network channel. The primary vector is HTTP rather than HTTPS, but the issue also manifests in unencrypted FTP, Telnet, SMTP without STARTTLS, LDAP without LDAPS, internal service-to-service communication, and database connections without TLS.

This vulnerability is classified under A02:2021 — Cryptographic Failures because the cryptographic protection of data in transit is absent or insufficient. Unlike certificate validation bypass (where encryption is present but authentication is absent), cleartext transmission uses no encryption at all — any passive observer on the network path can read the data verbatim. Active attackers can also modify the data in transit.

The threat model includes: shared Wi-Fi networks, rogue access points, ISP monitoring, BGP hijacking, and any network device between the client and server. Internal service communication is frequently overlooked under the assumption that internal networks are trusted — a dangerous assumption, as demonstrated repeatedly by insider threat incidents and lateral movement after initial compromise.

How It Works

The most basic form is a login form submitted over HTTP:

POST http://app.example.com/login HTTP/1.1
Host: app.example.com
Content-Type: application/x-www-form-urlencoded

username=alice&password=correcthorsebatterystaple

Any observer on the network — a coffee shop Wi-Fi operator, a passive tap on the network path — captures the request verbatim using Wireshark or tcpdump:

tcpdump -i wlan0 -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

The output shows the HTTP request and the password in plaintext.

HTTPS with HTTP mixed content is a common nuance: the login page loads over HTTPS, but a form, iframe, or API endpoint is called over HTTP. Some browsers warn about mixed content; others silently submit it. The sensitive data still travels over cleartext for that specific request.

Internal service communication is frequently unencrypted. Microservice architectures where service mesh encryption (mTLS) is not implemented transmit API calls, database queries, and authentication checks in cleartext within the internal network. A compromised internal service can sniff all traffic.

FTP and Telnet remain in use on legacy infrastructure. FTP transmits credentials and file contents in plaintext; Telnet transmits entire sessions including keystrokes. Ettercap and Responder can perform ARP poisoning on local networks to redirect and capture these sessions.

Database connections without TLS are common in internal deployments. A MySQL connection without --ssl-mode=REQUIRED sends all queries and results over the network in plaintext — including SELECT results containing PII and INSERT statements with user-supplied data.

Impact

• Credential theft — username/password pairs, API keys, and session tokens captured directly from network traffic.
• Session hijacking — session cookies transmitted over HTTP are captured and replayed to impersonate authenticated users.
• PII exposure — personal data, health records, and financial information read from unencrypted responses violates GDPR, HIPAA, and CCPA.
• API key compromise — bearer tokens and API keys in Authorization headers are readable in cleartext, enabling unauthorized API access.
• Man-in-the-middle manipulation — without encryption, active attackers can modify requests and responses, injecting malicious content or altering transaction data.
• Internal service credential leakage — database passwords and service-to-service tokens captured from internal traffic enable lateral movement.

Detection

1. Check whether HTTP redirects to HTTPS — attempt to connect via http:// for all application hostnames. Confirm that a 301/302 redirect to HTTPS is returned and that the redirect itself does not contain sensitive data (some login pages load partially over HTTP before redirecting).
2. Test with a proxy — configure Burp Suite and confirm all application requests use HTTPS. Look for mixed content — requests to HTTP URLs embedded in HTTPS pages.
3. Capture network traffic during mobile app testing — run the mobile app while Wireshark or tcpdump captures traffic. Filter for http protocol (not https). Any cleartext HTTP traffic is a finding.
4. Scan for internal cleartext services — use nmap to scan internal network ranges for ports 21 (FTP), 23 (Telnet), 80 (HTTP), 143 (IMAP), 389 (LDAP), 1433/3306/5432 (database without TLS).
5. Verify HSTS is in place — check that Strict-Transport-Security is present in HTTPS responses. Without HSTS, the first-visit HTTP connection is vulnerable to SSLStrip.
6. Test internal service communication — in a microservice environment, verify that service-to-service calls use HTTPS/mTLS rather than plain HTTP by inspecting service mesh configuration or capturing traffic inside the cluster.

Remediation

Redirect all HTTP to HTTPS. Configure the web server and load balancer to return a 301 Moved Permanently for all HTTP requests, redirecting to the HTTPS equivalent URL. Never serve content over HTTP.

Configure HSTS. Add Strict-Transport-Security: max-age=63072000; includeSubDomains; preload to enforce HTTPS for all future visits, preventing first-visit HTTP interception. Submit the domain to the HSTS preload list.

Replace FTP with SFTP or FTPS. Replace Telnet with SSH. Replace SMTP with SMTPS or SMTP+STARTTLS with mandatory encryption.

Enforce TLS for all database connections. In MySQL: --ssl-mode=REQUIRED. In PostgreSQL: sslmode=require. For MongoDB, Redis, and other data stores, configure TLS endpoints and require client-side TLS.

Implement mTLS for internal services. Use a service mesh (Istio, Linkerd) or sidecar proxies to enforce mutual TLS for all service-to-service communication within the cluster, even on internal networks.

# Verify database TLS in MySQL
mysql --ssl-mode=REQUIRED -u user -p -h db.internal.example.com
# Check connection: SHOW STATUS LIKE 'Ssl_cipher';