Android Browser Security--What You Haven't Been Told

This article focuses on flaws in Android's stock web libraries, while acknowledging related exploits. Some modern Android browsers have critically weak encryption and other dangerous flaws that cannot be patched or otherwise corrected. This weakness extends to multiple browsers and applications and is determined by the linkage to the system webcore on older OS versions. HTML applications that do not provide their own rendering engine should be avoided for all versions of Android less than 5.0.

Recent statistics indicate that 19% of the population accessing internet information systems have been the victims of an exploit or data breach, causing 45% to reduce or eliminate reliance upon electronic commerce and communication. Computer security flaws are resulting in a direct impact on the economics of online business, and this must be corrected.

Weakened WebKit

Most mobile platforms (including Android) owe a great debt to the KHTML rendering engine from the KDE Konqueror web browser. Mobile HTML is essentially a monoculture from the perspective of an OS default browser—they all emerge from KHTML, which won this position by providing a high-quality codebase under a reasonable license at the right time.

Although one would hesitate to call Apple a consistently good steward of KHTML due to past friction with the Konqueror project, the Safari browser introduced a compelling rework of KHTML known as WebKit. Apple has provided both new features and regular security fixes for WebKit (more than 100 security-related patches in 2015), which eventually were brought back to Konqueror. As Safari moved from desktop MacOS to mobile iOS, WebKit assumed the mantle of mobile browser leadership, and that role never has been seriously challenged.

Google also adopted WebKit into both Android and the Chrome web browser. Chrome has become the dominant browser by market share, and it receives regular updates from Google on all platforms where it is supported.

However, Google also added WebKit as a library to Android. Any application can link the system WebKit to render HTML as part of the User Interface (UI) by calling WebView, which links in /system/lib/

The problem with Android's bundled WebKit is that for older versions, it is never updated, which is not well known. Android 5.0 Lollipop is the first release where the bundled WebKit can be patched.

For Android 4.4 KitKat, the bundled WebKit 537.36 and its TLS implementation does not conform to best-practice encryption as defined in RFC 7525 As reported by the Qualys SSL Scanner:

  • SSL version 3 is enabled—a must not from the RFC. This can be exploited via the POODLE downgrade attack to decrypt traffic.

  • Weak "export-grade" ciphers are allowed—also a must not from the RFC. This enables hostile decryption by third parties via the FREAK attack.

  • RC4 ciphers are allowed—also a must not from the RFC.

  • Weak Diffie-Hellman primes are allowed, which can be exploited via the Logjam attack.

These software flaws preclude the use of the KitKat system WebKit for sensitive transactions of any kind. Android JellyBean, which spans numerical releases of 4.1 through 4.3, has WebKit version 534.30, which is even worse, as it wasn't actually updated since Android version 4.0.1 Ice Cream Sandwich:

  • JellyBean disables TLS 1.1 and 1.2 by default, in addition to allowing SSL v3.

  • JellyBean also is vulnerable to the "Same Origin Policy" bug CVE-2014-6041, which allows hostile websites to spy on browser activity.


Charles Fisher has an electrical engineering degree from the University of Iowa and works as a systems and database administrator for a Fortune 500 mining and manufacturing corporation.