flawopen.com/Android-WebView-Sicherheit/addJavascriptInterface

Android addJavascriptInterface: Risiken und sichere Nutzung

Referenzseite

Kurzantwort

Behandle eine WebView mit addJavascriptInterface als privilegierte Grenze. Android injiziert das Objekt in jeden Frame; die App kann nicht erkennen, welcher Frame es aufgerufen hat. Erreicht angreiferkontrolliertes JavaScript einen Frame, kann es exponierte Methoden mit den Berechtigungen der App aufrufen. Verwende WebViews mit Bridge nur für appkontrollierte Inhalte und lade nicht vertrauenswürdige Seiten in einer separaten WebView ohne Bridge.

Wie die Bridge die XSS-Auswirkung verändert

Eine Bridge stellt JavaScript aufrufbare Einstiegspunkte in der Host-App bereit. Android exponiert das Objekt für alle Frames einschließlich Iframes; addJavascriptInterface prüft nicht den Ursprung des aufrufenden Frames. Injizierte Skripte können daher annotierte Bridge-Methoden erreichen. Ihre Wirkung hängt von diesen Methoden und den Autorisierungsprüfungen der App ab. Für Apps mit Ziel-API 16 oder niedriger dokumentiert Android ein schwerwiegenderes Altverhalten: Alle öffentlichen Methoden können exponiert sein. Ab API 17 ist @JavascriptInterface erforderlich, doch die Annotation macht nicht vertrauenswürdige Inhalte nicht sicher.

Halte die Bridge von nicht vertrauenswürdigen Seiten fern

RISKANT — Bridge und nicht vertrauenswürdige Navigation in derselben WebView

webView.addJavascriptInterface(
  NativeBridge(), "Android"
)
webView.loadUrl(untrustedUrl)

SICHERER — vertrauenswürdige und nicht vertrauenswürdige Inhalte trennen

// Diese WebView ist für die gebündelte, appkontrollierte Oberfläche reserviert.
trustedWebView.settings.javaScriptEnabled = true
trustedWebView.addJavascriptInterface(
  NativeBridge(), "Android"
)
trustedWebView.loadUrl("file:///android_asset/index.html")

// Eine separate WebView verarbeitet entfernte oder nutzergesteuerte Seiten.
untrustedWebView.removeJavascriptInterface("Android")
untrustedWebView.settings.javaScriptEnabled = false
// HTTPS und eine explizite Host-Allowlist validieren.
untrustedWebView.loadUrl(validatedHttpsUrl)

Die stärkste Grenze ist die Architektur: Navigiere mit einer Bridge-WebView niemals zu entfernten, nutzergenerierten oder anderweitig angreiferkontrollierten Seiten. Falls nicht vertrauenswürdige Inhalte geladen werden müssen, entferne die Schnittstelle vor dem Laden und verwende eine separate WebView mit deaktiviertem JavaScript, sofern es nicht benötigt wird. Android weist darauf hin, dass das injizierte Objekt allen Frames zur Verfügung steht und die Entfernung erst nach dem nächsten Seitenladen wirksam wird. HTTPS schützt den Transport, macht aber weder einen Host noch dessen Inhalte vertrauenswürdig. Prüfe URL-Schema und Host und öffne nicht erlaubte Links im Systembrowser. Beschränke Bridge-Methoden, validiere jedes Argument und setze Autorisierung im nativen Code durch, statt der aufrufenden Seite zu vertrauen.

FAQ zur Sicherheit von Android-WebView-Bridges

Macht API 17 oder höher addJavascriptInterface automatisch sicher?

Nein. API 17+ begrenzt die Exposition auf öffentliche Methoden mit @JavascriptInterface; sie prüft weder den Ursprung des aufrufenden Frames noch macht sie angreiferkontrollierte Inhalte vertrauenswürdig. Verwende die Bridge nur in einer WebView, die ausschließlich appkontrollierte Inhalte lädt.

Quellen

Siehe auch Cross-Site-Scripting (XSS, CWE-79): Funktionsweise und Schutz in jeder Sprache — flawopen.com Angular-XSS-Schutz: sichere Standards und Bypass-APIs XSS durch MIME-Sniffing: Content-Type und nosniff CSP und Output-Escaping: Brauchst du beides? Ist dangerouslySetInnerHTML in React sicher? Reicht DOMPurify für sicheres innerHTML? Ist Markdown-Rendering vor XSS sicher?