Klartextkommunikation

OWASP-Kategorie: MASVS-NETWORK: Netzwerkkommunikation

Übersicht

Wenn in einer Android-App die Klartext-Netzwerkkommunikation zugelassen wird, kann jeder, der den Netzwerkverkehr überwacht, die übertragenen Daten sehen und manipulieren. 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-Anwendung 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 der Nutzer zu erhalten.

Risiko: Nicht verschlüsselte Kommunikationskanäle

Wenn Daten über unverschlüsselte Kommunikationskanäle übertragen werden, sind die Daten, die zwischen dem Gerät und den Anwendungsendpunkten geteilt werden, angreifbar. 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 Risiken zusammengefasst, für die nicht standardmäßige Risikominderungsstrategien erforderlich sind oder die auf einer bestimmten SDK-Ebene gemindert wurden. Er dient der 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 erzwingen diese Einschränkungen für Klartext jedoch wahrscheinlich nicht und sollten 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. Dabei sind nur Ausnahmen für die spezifischen Domains erforderlich, die erforderlich 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.

In der Regel basieren Client-Server-Architekturen auf APIs, die Entwicklern gehören. Wenn Ihre Anwendung von einer Reihe von API-Endpunkten abhängt, sollten Sie die folgenden Best Practices für die Sicherheit der HTTPS-Kommunikation befolgen, um eine umfassende Sicherheit zu gewährleisten:

  • Authentifizierung: Nutzer sollten sich mit sicheren Mechanismen wie OAuth 2.0 authentifizieren. Die Basisauthentifizierung wird im Allgemeinen nicht empfohlen, da sie keine Mechanismen zur Sitzungsverwaltung bietet und bei unsachgemäßer 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 Zugriffssteuerungslösungen für die Assets der Anwendung implementiert werden.
  • Achten Sie darauf, dass die neuesten Chiffrensammlungen verwendet werden, und befolgen Sie 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 Sitzungsverwaltung können beispielsweise dazu führen, dass Angreifer die Kommunikation abhören und vertrauliche Informationen in Echtzeit 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. Außerdem können dadurch dieselben Sicherheitslücken entstehen wie bei der Verwendung benutzerdefinierter Protokolle.

Abhilfemaß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.

So können Entwickler sicher sein, dass sie Lösungen verwenden, die gründlich getestet, im Laufe der Zeit verbessert und kontinuierlich mit Sicherheitsupdates zur Behebung häufiger Sicherheitslücken versorgt werden.

Wenn Entwickler für ihre Arbeit 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. Solche Schlüssel sollten sicher erstellt und gespeichert werden. Der Android Keystore wird für diesen Zweck empfohlen.
  • Die unterstützten Chiffren müssen den Best Practices für Sicherheit entsprechen.

Ressourcen