Klartextkommunikation

OWASP-Kategorie: MASVS-NETWORK: Network Communication

Übersicht

Wenn Sie in einer Android-App Netzwerkkommunikation im Klartext zulassen, können alle, die den Netzwerkverkehr überwachen, die übertragenen Daten sehen und manipulieren. Das 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 Informationen senden oder nicht, kann die Verwendung von Klartext eine Sicherheitslücke darstellen, da Klartext-Traffic auch durch Netzwerkangriffe wie ARP- oder DNS-Spoofing manipuliert werden kann. So können Angreifer möglicherweise das Verhalten einer App beeinflussen.

Auswirkungen

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 private Nachrichten enthalten, kann dies zu Identitätsdiebstahl, Finanzbetrug und anderen schwerwiegenden Problemen führen.

Wenn eine App beispielsweise Passwörter im Klartext überträgt, können diese Anmeldedaten von einem böswilligen Akteur abgefangen werden. Diese Daten können dann verwendet werden, um unbefugten Zugriff auf die Konten des Nutzers zu erhalten.

Risiko: Unverschlüsselte Kommunikationskanäle

Wenn Daten über unverschlüsselte Kommunikationskanäle übertragen werden, sind die zwischen dem Gerät und den Anwendungsendpunkten ausgetauschten Daten nicht geschützt. Diese Daten können von einem Angreifer abgefangen und möglicherweise geändert werden.

Risikominimierung

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

Spezifische Risiken

In diesem Abschnitt werden Risiken zusammengefasst, für die nicht standardmäßige Risikominimierungsstrategien erforderlich sind oder die auf einer bestimmten SDK-Ebene minimiert wurden und hier der Vollständigkeit halber aufgeführt sind.

Risiko: HTTP

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

Risikominimierung

Verwenden Sie die NetworkSecurityConfig.xml-Funktion, um Klartext-Traffic zu deaktivieren und HTTPS für Ihre App zu erzwingen. Ausnahmen sind nur für die erforderlichen spezifischen Domains zulässig (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>

Diese Option trägt dazu bei, versehentliche Regressionen in Apps aufgrund von Änderungen an URLs zu verhindern, 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. Das größte Risiko ist die fehlende Verschlüsselung über den Kommunikationskanal. Stattdessen sollten sicherere Alternativen wie SFTP oder HTTPS verwendet werden.

Risikominimierung

Wenn Sie Mechanismen für den Datenaustausch über das Internet in Ihrer Anwendung implementieren, sollten Sie ein sicheres Protokoll wie HTTPS verwenden. Android stellt eine Reihe von APIs zur Verfügung, mit denen Entwickler eine Client-Server Logik erstellen können. Diese kann mit Transport Layer Security (TLS) gesichert werden. So wird sichergestellt, dass der Datenaustausch zwischen zwei Endpunkten verschlüsselt ist. Dadurch wird verhindert, dass böswillige Nutzer die Kommunikation abhören und vertrauliche Daten abrufen können.

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 einhalten, um HTTPS-Kommunikation zu schützen:

  • Authentifizierung: Nutzer sollten sich mit sicheren Mechanismen wie OAuth 2.0 authentifizieren. Die Basisauthentifizierung wird im Allgemeinen nicht empfohlen, da sie keine Sitzungsverwaltungsmechanismen bietet und Anmeldedaten, wenn sie nicht ordnungsgemäß gespeichert werden, aus Base64 decodiert werden können.
  • Autorisierung: Nutzer sollten gemäß dem Prinzip der geringsten Berechtigung nur auf die beabsichtigten Ressourcen zugreifen können. Dies kann durch die Einführung sorgfältiger Zugriffssteuerungslösungen für die Assets der Anwendung implementiert werden.
  • Achten Sie darauf, dass durchdachte und aktuelle Cipher Suites verwendet werden, die den Best Practices für die Sicherheit entsprechen. 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.

Benutzerdefinierte Protokolle ermöglichen es Entwicklern, eine einzigartige Lösung zu entwickeln, die an die beabsichtigten Anforderungen angepasst ist. Fehler während des Entwicklungsprozesses können 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 abrufen können.

Andererseits erhöht die Implementierung bekannter Protokolle wie HTTPS ohne Verwendung von Betriebssystem- oder gut gewarteten Drittanbieterbibliotheken die Wahrscheinlichkeit von Programmierfehlern, die es schwierig oder sogar unmöglich machen können, das implementierte Protokoll bei Bedarf zu aktualisieren. Außerdem können dadurch dieselben Sicherheitslücken wie bei der Verwendung benutzerdefinierter Protokolle entstehen.

Risikominimierung

Gewartete Bibliotheken verwenden, um bekannte Kommunikationsprotokolle zu implementieren

Um bekannte Protokolle wie HTTPS in Ihrer Anwendung zu implementieren, sollten Sie Betriebssystembibliotheken oder gewartete Drittanbieterbibliotheken verwenden.

So können Entwickler Lösungen wählen, die gründlich getestet, im Laufe der Zeit verbessert wurden und regelmäßig Sicherheitsupdates erhalten, um häufige Sicherheitslücken zu beheben.

Darüber hinaus profitieren Entwickler durch die Wahl bekannter Protokolle von einer breiten Kompatibilität mit verschiedenen Systemen, Plattformen und IDEs, wodurch die Wahrscheinlichkeit menschlicher Fehler während des Entwicklungsprozesses verringert wird.

SFTP verwenden

Dieses Protokoll verschlüsselt die Daten bei der Übertragung. Bei der Verwendung dieser Art von Dateiaustauschprotokoll sollten zusätzliche Maßnahmen berücksichtigt werden:

  • SFTP unterstützt verschiedene Arten der Authentifizierung. Anstelle der passwortbasierten Authentifizierung sollte die Methode der Authentifizierung mit öffentlichen Schlüsseln verwendet werden. Solche Schlüssel sollten sicher erstellt und gespeichert werden. Android Keystore wird für diesen Zweck empfohlen.
  • Achten Sie darauf, dass die unterstützten Verschlüsselungen den Best Practices für die Sicherheit entsprechen.

Ressourcen