Products + All Products + Software Integrity + Semiconductor IP + Verification + Design + Silicon Engineering
Posted by Andrew Lee-Thorp on December 18, 2015
The Pre-KitKat (Android 4.4) WebView was largely based on WebKit and did not receive software updates (unless a device received an OTA update from the carrier or OEM). KitKat and later WebViews are based on the chromium open source browser. Since Android 5.0 (Lollipop), the WebView is packaged as a separate APK and is updated separately.
It is “the” (embedded) component that powers the majority of HTML-enabled apps and many internet apps. WebViews continue to be a current topic but for the wrong reasons. Fortunately (or unfortunately), none of these reasons are new.
Firstly, since a WebView is a browser control in an app, it invites traditional attacks associated with the web: connection hijacking, XSS, and so on. But WebViews sport other features (since the use of a WebView is implicit, we will just refer to them as apps). The developer can, by design, punch holes in the sandbox. Web content can interact with the app and vice versa. This design means that if a vulnerability exists then it can be exploited in either direction. Moreover, a common (even pervasive) model of apps is to bundle both local resources and web content in the same container (i.e. the app itself). When put together, the resulting threat model becomes more than the sum of its parts. A Same Origin Policy (SOP) bypass can lead to device file-system access. Think stealing user data or cookies. Incorrectly processing URLs can make the app an intermediary. Think remote attacker targeting other applications (or even the app itself) by using the intermediary app as a proxy. We’ll explore these in this and forthcoming posts.
Figure 1: A WebView combines both the threat models facing traditional and web-based apps
I/chromium(13478): [INFO:CONSOLE(1)] “Uncaught TypeError: Object [object Object] has no method ‘secret'”
The short answer is NO.
Developers can adopt a defense-in-depth approach by proactively removing system-installed bridges.
This presents a problem: if you haven’t installed these bridges, how can you name them in order to remove them? There are three possibilities, none of which is pretty: