Android WebViews: All about security
Have you thought about adding some content to your app in a WebView? Have you heard of how insecure it can be? Let’s demystify this topic and explain what security improvements different versions of Android bring to the table.
WebView security: Version by Version
Prior to Android 4.3 (Jelly Bean)
WebView uses code based on Apple’s Webkit (same tech behind the Safari browser). There are some open JavaScript vulnerabilities that were fixed in higher versions on Android.
Android 4.4 (KitKat)
WebView is based on Chromium (open-source base of Google Chrome that uses Google’s Blink engine). JavaScript vulnerabilities mentioned above are fixed.
Android 5.0 (Lollipop)
WebView was broken out as a separate app (to allow updates through Google Play without requiring firmware updates).
Android gave developers a more granular way of controlling the requests going in and out of the WebView. Classes like ClientCertRequest give us the option to choose the client certificate so we can perform SSL pinning (a must-have).
Safe Browsing: WebView incorporates Google’s Safe Browsing protections to detect and warn users about potentially dangerous sites.
Android 7.0 (Nougat)
EDIT (01/07/18): As Graham Smith pointed out in his comment, Android 7.0 added Network Security Config with which you can customize your network security settings in a declarative configuration file (without modifying app code). As it also works with WebViews, it’s an easy way to perform SSL Pinning.
Android 8.0 (Oreo)
WebView has the renderer running in an isolated process separate from the host app. Apart from preventing crashes that affect the host app, it also has access to limited amount of resources.
Android 8.1 (Oreo)
Android 5.0 added Google’s Safe Browsing protections. Now, you can define programmatically how your app responds to a known threat.
WebViews security concerns with JavaScript enabled for Android 4.3 and below
The primary vulnerabilities involved in the WebView component are Insecure Direct Object References, SQL Injection, and Cross-Site Scripting (XSS).
While all three are potentially huge risks, the XSS vulnerability potential can be used to gain access to shared preference files using the file:/// command or can utilize smsJSInterface.launchSMSActivity to send unwanted SMS messages from the phone, in addition to stealing credentials or providing a false front to the HTML, CSS, Javascript, or other browser-level behavior.
Does this affect you? If your application is hosted at your own server, as long as no malicious code infects it and you don’t redirect to external websites, you should be good.
How can you make your WebView secure?
If you want the content in your WebView to be secure, I’d recommend you bumping your minSdkVersion at least to Android 5.0 (API Level 21) where major security improvements were added.
If you don’t need JavaScript and you disabled it, you shouldn’t worry about those security issues. In case you need it, if you control all the content displayed on the WebView and you think your server is secure enough that no one is going to modify it, you could use a lower version although I highly recommend using SSL pinning (that was added in Lollipop, Android 5.0).
Sources of information
Thanks for reading,
Manuel Vicente Vivo
