WebView
Da WebView Webinhalte nutzt, die HTML und JavaScript enthalten können, kann eine unsachgemäße Verwendung zu häufigen Web-Sicherheitsproblemen wie Cross-Site-Scripting (JavaScript-Injection) führen. Android verfügt über eine Reihe von Mechanismen, um das Ausmaß dieser potenziellen Probleme zu reduzieren, indem die Funktionalität von WebView auf die für Ihre Anwendung erforderliche Mindestfunktionalität beschränkt wird.
Wenn Ihre Anwendung JavaScript nicht direkt in einer WebView verwendet, rufen Sie setJavaScriptEnabled() nicht auf. Einige Beispielcodes verwenden diese Methode; Wenn Sie Beispielcode, der ihn in einer Produktionsanwendung verwendet, für andere Zwecke verwenden, entfernen Sie diesen Methodenaufruf, wenn er nicht erforderlich ist. Standardmäßig führt WebView kein JavaScript aus, sodass Cross-Site-Scripting nicht möglich ist.
Verwenden Sie addJavaScriptInterface() mit besonderer Sorgfalt, da es JavaScript ermöglicht, Vorgänge aufzurufen, die normalerweise Android-Anwendungen vorbehalten sind. Wenn Sie es verwenden, stellen Sie addJavaScriptInterface() nur für Webseiten bereit, von denen alle Eingaben vertrauenswürdig sind. Wenn nicht vertrauenswürdige Eingaben zulässig sind, kann nicht vertrauenswürdiges JavaScript möglicherweise Android-Methoden in Ihrer App aufrufen. Im Allgemeinen empfehlen wir, addJavaScriptInterface() nur für JavaScript verfügbar zu machen, das in Ihrem Anwendungs-APK enthalten ist.
Wenn Ihre Anwendung mit einem WebView auf vertrauliche Daten zugreift, sollten Sie die Verwendung der Methode „clearCache()“ in Betracht ziehen, um alle lokal gespeicherten Dateien zu löschen. Sie können auch serverseitige Header wie „no-store“ verwenden, um anzugeben, dass eine Anwendung bestimmte Inhalte nicht zwischenspeichern soll.
Geräte mit Plattformen, die älter als Android 4.4 (API-Level 19) sind, verwenden eine Webkit-Version, die eine Reihe von Sicherheitsproblemen aufweist. Um dieses Problem zu umgehen, muss Ihre App, wenn sie auf diesen Geräten ausgeführt wird, bestätigen, dass WebView-Objekte nur vertrauenswürdige Inhalte anzeigen. Um sicherzustellen, dass Ihre App keinen potenziellen Schwachstellen in SSL ausgesetzt ist, verwenden Sie das aktualisierbare Sicherheitsanbieterobjekt, wie unter Aktualisieren Ihres Sicherheitsanbieters zum Schutz vor SSL-Exploits beschrieben. Wenn Ihre Anwendung Inhalte aus dem offenen Web rendern muss, sollten Sie die Bereitstellung eines eigenen Renderers in Betracht ziehen, damit Sie sie mit den neuesten Sicherheitspatches auf dem neuesten Stand halten können.
Anmeldedatenanfragen
Um Phishing-Angriffe auffälliger und weniger erfolgreich zu machen, minimieren Sie die Häufigkeit, mit der nach Benutzeranmeldeinformationen gefragt wird. Verwenden Sie stattdessen ein Autorisierungstoken und aktualisieren Sie es.
Speichern Sie Benutzernamen und Passwörter nach Möglichkeit nicht auf dem Gerät. Führen Sie stattdessen die Erstauthentifizierung mit dem vom Benutzer bereitgestellten Benutzernamen und Kennwort durch und verwenden Sie dann ein kurzlebiges, dienstspezifisches Autorisierungstoken.
Wir empfehlen, mit AccountManager eine Verbindung zu Diensten herzustellen, auf die mehrere Anwendungen zugreifen können. Verwenden Sie nach Möglichkeit die AccountManager-Klasse, um einen cloudbasierten Dienst aufzurufen, und speichern Sie keine Kennwörter auf dem Gerät.
Nachdem Sie AccountManager zum Abrufen eines Kontos verwendet haben, verwenden Sie CREATOR, bevor Sie Anmeldeinformationen übergeben, damit Sie nicht versehentlich Anmeldeinformationen an die falsche Anwendung übergeben.
Wenn Anmeldeinformationen nur von Anwendungen verwendet werden, die Sie erstellen, können Sie die Anwendung, die auf den AccountManager zugreift, mit checkSignatures() überprüfen. Wenn nur eine Anwendung die Anmeldeinformationen verwendet, können Sie alternativ einen KeyStore zur Speicherung verwenden.