Overcoming JavaScript Unsecurities in WebViews
summary
Running JavaScript in Android WebViews is practical but risky: demos show file XHR exfiltration from app assets, JavaScript bridge token leak via timing/race conditions, and unintended launches of internal activities through intent URIs. Mitigations that are shown and proven to work include disabling file access and universal access, using WebViewAssetLoader instead of manual webResourceResponse plumbing, validating getUrl() in real time before sensitive actions, prefer allowlists, and using the new JS Engine 1.0 (isolated, no network) or WebMessage/AndroidX WebKit APIs for safer bridges.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 2:30WebView lifecycle
- 4:35Secure JS enablement
- 7:02JS scheme attacks
- 9:31File access risks
- 11:59Response vulnerabilities
- 15:30Cross-site scripting risks with JavaScript interfaces
- 18:16Timing attacks on bridges
- 21:46Legacy bridge flaws
- 23:50Intent URI risks
- 26:40Secure JS engine
- 28:45Password demo & performance
- 30:52Modern WebView alternatives
- 32:14Q&A
related talks
42mOvercoming Unsecurities in WebViews
34mOvercoming Insecurities in WebViews
40mSo, You Want To Use A WebView? [BAD AUDIO]
22mThe Tangled Webview ----- Javascriptinterface Once More
42mDangers on Android: Vulnerabilities and Defenses
39mAndroid and the WebView
23mSupercharged WebView Observability
25mWebView Implementations in the 2020s