Klartextkommunikation

OWASP-Kategorie: MASVS-NETWORK: Netzwerkkommunikation

Übersicht

Wenn Sie in einer Android-App Klartext-Netzwerkkommunikation zulassen, kann jeder, der den Netzwerkverkehr überwacht, die übertragenen Daten sehen und ändern. Dies ist eine Sicherheitslücke, wenn die übertragenen Daten vertrauliche Informationen wie Passwörter, Kreditkartennummern oder andere personenbezogene Daten enthalten.

Unabhängig davon, ob Sie vertrauliche Daten senden oder nicht, kann die Verwendung von Klartext eine Sicherheitslücke darstellen, da Klartext-Traffic auch durch Netzwerkangriffe wie ARP oder DNS-Poisoning manipuliert werden kann. So können Angreifer potenziell das Verhalten einer App beeinflussen.

Positiv beeinflussen

Wenn eine Android-App Daten im Klartext über ein Netzwerk sendet oder empfängt, kann jeder, der das Netzwerk überwacht, diese Daten abfangen und lesen. Wenn diese Daten vertrauliche Informationen wie Passwörter, Kreditkartennummern oder persönliche Nachrichten enthalten, kann dies zu Identitätsdiebstahl, Finanzbetrug und anderen schwerwiegenden Problemen führen.

Eine App, die Passwörter im Klartext überträgt, könnte diese Anmeldedaten beispielsweise einem böswilligen Akteur ausliefern, der den Traffic abfängt. Diese Daten könnten dann verwendet werden, um unbefugten Zugriff auf die Konten des Nutzers zu erhalten.

Risiko: Nicht verschlüsselte Kommunikationskanäle

Bei der Übertragung von Daten über unverschlüsselte Kommunikationskanäle werden die Daten freigegeben, die zwischen dem Gerät und den Anwendungsendpunkten geteilt werden. Diese Daten können von einem Angreifer abgefangen und möglicherweise geändert werden.

Abhilfemaßnahmen

Daten sollten über verschlüsselte Kommunikationskanäle gesendet werden. Sichere Protokolle sollten als Alternative zu Protokollen verwendet werden, die keine Verschlüsselung bieten.

Spezifische Risiken

In diesem Abschnitt werden die Risiken aufgeführt, die nicht standardmäßige Strategien zur Risikominderung erfordern oder auf einer bestimmten SDK-Ebene gemindert wurden. Der Abschnitt enthält Informationen zur Vollständigkeit.

Risiko: HTTP

Die Hinweise in diesem Abschnitt gelten nur für Apps, die auf Android 8.1 (API-Ebene 27) oder niedriger ausgerichtet sind. Ab Android 9 (API-Ebene 28) erzwingen HTTP-Clients wie URLConnection, Cronet und OkHttp die Verwendung von HTTPS. Daher ist die Unterstützung von Klartext standardmäßig deaktiviert. Andere HTTP-Clientbibliotheken wie Ktor werden diese Einschränkungen jedoch wahrscheinlich nicht für Klartext durchsetzen und sollten daher mit Vorsicht verwendet werden.

Abhilfemaßnahmen

Mit der Funktion NetworkSecurityConfig.xml können Sie den Klartext-Traffic deaktivieren und HTTPS für Ihre App erzwingen, wobei nur für die erforderlichen Domains Ausnahmen zulässig sind (in der Regel zu Debugging-Zwecken):

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>

Mit dieser Option können versehentliche Rückschritte in Apps aufgrund von Änderungen an URLs verhindert werden, die von externen Quellen wie Back-End-Servern bereitgestellt werden.

Risiko: FTP

Die Verwendung des FTP-Protokolls zum Austausch von Dateien zwischen Geräten birgt mehrere Risiken, von denen das größte die fehlende Verschlüsselung über den Kommunikationskanal ist. Stattdessen sollten sicherere Alternativen wie SFTP oder HTTPS verwendet werden.

Abhilfemaßnahmen

Wenn Sie in Ihrer Anwendung Datenaustauschmechanismen über das Internet implementieren, sollten Sie ein sicheres Protokoll wie HTTPS verwenden. Android stellt eine Reihe von APIs bereit, mit denen Entwickler eine Client-Server-Logik erstellen können. Dies kann mit Transport Layer Security (TLS) gesichert werden, um sicherzustellen, dass der Datenaustausch zwischen zwei Endpunkten verschlüsselt wird. So wird verhindert, dass böswillige Nutzer die Kommunikation abhören und sensible Daten abrufen.

Client-Server-Architekturen basieren üblicherweise auf APIs des Entwicklers. Wenn Ihre Anwendung von einer Reihe von API-Endpunkten abhängt, sorgen Sie für gestaffelte Sicherheit, indem Sie die folgenden Best Practices für die Sicherheit befolgen, um die HTTPS-Kommunikation zu schützen:

  • Authentifizierung: Nutzer sollten sich mit sicheren Mechanismen wie OAuth 2.0 authentifizieren. Von der Basisauthentifizierung wird im Allgemeinen abgeraten, da sie keine Mechanismen zur Sitzungsverwaltung bietet und bei falscher Speicherung von Anmeldedaten aus Base64 decodiert werden kann.
  • Autorisierung: Nutzer sollten gemäß dem Prinzip der geringsten Berechtigung nur auf die vorgesehenen Ressourcen zugreifen dürfen. Dies kann durch sorgfältige Zugangskontrolllösungen für die Assets der Anwendung umgesetzt werden.
  • Achten Sie darauf, dass durchdachte und neueste Cipher Suites verwendet werden. Beachten Sie dabei die Best Practices für die Sicherheit. Sie können beispielsweise das TLSv1.3-Protokoll mit Abwärtskompatibilität für die HTTPS-Kommunikation unterstützen.

Risiko: Benutzerdefinierte Kommunikationsprotokolle

Die Implementierung benutzerdefinierter Kommunikationsprotokolle oder der Versuch, bekannte Protokolle manuell zu implementieren, kann gefährlich sein.

Mit benutzerdefinierten Protokollen können Entwickler eine individuelle Lösung anpassen, die den gewünschten Anforderungen entspricht. Jeder Fehler während des Entwicklungsprozesses kann jedoch zu Sicherheitslücken führen. Fehler bei der Entwicklung von Mechanismen zur Sitzungsverarbeitung können beispielsweise dazu führen, dass Angreifer die Kommunikation abhören und vertrauliche Informationen spontan abrufen können.

Wenn Sie jedoch bekannte Protokolle wie HTTPS ohne Betriebssystem oder gut gepflegte Drittanbieterbibliotheken implementieren, steigt die Wahrscheinlichkeit, dass Programmierfehler auftreten, die es schwierig oder sogar unmöglich machen, das implementierte Protokoll bei Bedarf zu aktualisieren. Darüber hinaus kann dies zu denselben Sicherheitslücken führen wie bei benutzerdefinierten Protokollen.

Abwehrmaßnahmen

Verwaltete Bibliotheken verwenden, um bekannte Kommunikationsprotokolle zu implementieren

Wenn Sie bekannte Protokolle wie HTTPS in Ihrer Anwendung implementieren möchten, sollten Sie Betriebssystembibliotheken oder gepflegte Drittanbieterbibliotheken verwenden.

Entwickler können sich so für Lösungen entscheiden, die gründlich getestet und im Laufe der Zeit verbessert wurden und kontinuierlich Sicherheitsupdates zur Behebung häufiger Sicherheitslücken erhalten.

Wenn Entwickler bekannte Protokolle verwenden, profitieren sie außerdem von einer breiten Kompatibilität mit verschiedenen Systemen, Plattformen und IDEs. So wird die Wahrscheinlichkeit von menschlichen Fehlern während des Entwicklungsprozesses verringert.

SFTP verwenden

Dieses Protokoll verschlüsselt die Daten bei der Übertragung. Bei der Verwendung dieses Dateiübertragungsprotokolls sollten zusätzliche Maßnahmen berücksichtigt werden:

  • SFTP unterstützt verschiedene Authentifizierungsarten. Anstelle der passwortbasierten Authentifizierung sollte die Public-Key-Authentifizierung verwendet werden. Diese Schlüssel sollten sicher erstellt und gespeichert werden. Für diesen Zweck wird Android Keystore empfohlen.
  • Achten Sie darauf, dass die unterstützten Chiffren den Best Practices für Sicherheit entsprechen.

Ressourcen