Many mobile applications rely heavily on web technologies and resources for their functionality. For example, WebViews offer a simple and convenient way to load and display web content directly within a mobile app. However, WebViews can increase the mobile attack surface while introducing significant risk depending on their configuration. Cyberattackers can exploit Android WebViews to steal user credentials or perform phishing by directing traffic to a malicious site.
This tutorial will analyze a common Android WebView implementation to show how it’s susceptible to URL redirect, cross-site scripting (XSS) and internal code execution. Additionally, you’ll learn how to exploit these vulnerabilities using Frida, an open-source dynamic instrumentation toolkit created and supported by NowSecure researchers.
Pen Testing Tool Prerequisites
In addition to Frida, this exercise requires use of the following mobile application security testing tools:
- A rooted Android device (physical or virtual)
- Vulnerable app I created for this exercise to showcase a standard WebView implementation
- JADX Dex to Java decompiler
- Frida dynamic code instrumentation toolkit
- ngrok blank to expose local Apache server HTTPS
- Integrated Development Environment (IDE) that supports HTML and JavaScript
- Android Debug Bridge (adb) tool to install .apk files on an Android device
We will use the Android app and the mobile pen testing tools listed above to exploit WebViews in the following order:
- URL redirect
- XSS
- Code execution
WebViews can expand the mobile attack surface while introducing significant risk depending on their configuration.
URL Redirect
We will start off slow by showing how to redirect the Android Web View and then we will gradually launch more complex attacks. There are two ways to redirect a WebView on the client-side:
- The Web View Activity is exported within the AndroidManifest.xml.
- The Web View function is vulnerable to parameter injection.
We can check the AndroidManifest.xml to see if the WebView activity is exported:
Unfortunately, the activity is not exported which means we can move on to looking at the WebView function that initiates and configures the WebView. This is located in com.vulnerablewebview.WebviewActivity. Within the activity there’s a function called ConfigWebview that takes in a string parameter which sets the URL:
We can use Frida to hook into this function and inject our own value for the URL parameter. To do this, we will need to create a custom Frida script. Luckily JADX makes this very easy —simply right click on the “ConfigWebview” function and select “Copy as Frida snippet”:
Next, paste the Frida snippet into your JavaScript IDE. Be sure to wrap your snippet in the Java.perform function and add the URL variable with a valid website as the value. (Java.perform() is a function that is used to create a Java Virtual Machine (JVM), which allows our script to interact with Java objects and classes of the Android mobile app.
Your JavaScript code should look like this:
Finally, we use Frida to hook into our application and run the script to inject the new value for the URL. To do this, we must first attach our device via USB to our computer and start the Frida-Server on our device using Android Debug Bridge:
Run Frida with the custom script in a terminal:
The app will launch on your device, and when you click the WebView button it should display https://www.google.com:
Cross-Site Scripting (XSS)
To exploit XSS in an Android WebView, the WebView must have JavaScript enabled. Examining the ConfigWebview function in JADX shows that the WebView has JavaScript enabled:
Before getting to the exploit, we must first configure a few tools that will allow us to inject our payload into the URL parameter. The biggest obstacle is placing a script from our desktop onto the Internet. To do this, we will leverage the Apache and ngrok web server tools.
Start Apache:
To confirm that Apache is working properly, open a web browser and type in http://localhost/. If your Apache web server is working properly, you should receive a message that says, “It works!”.
Now that we have our local web server running, this is the perfect opportunity to write an XSS exploit script and test it locally. To do this, open your IDE and write a simple XSS payload:
To call the script from our Apache server, we must move the SimpleXSS.html script into our web server documents folder. On MacOS this is located in /Library/WebServer/Documents. Once you’ve moved the script, open a web browser and type http://localhost/SimpleXSS.html. You should receive this pop-up message:
This confirms our XSS payload is ready to go.
Use ngrok to get the payload onto the public Internet without having to pay for servers and a domain. With Apache still running, start the ngrok service in your terminal by using the command ngrok http 80.
You should see the URL for the ngrok address in the terminal window. Copy and paste this address into a web browser. If you configured everything correctly, you should receive the “It works!” message:
The ngrok tool will also have access to all scripts from the web server documents folder. Be sure to double check that all your scripts are behaving the same way they did with Apache.
Now we will use the exact same technique from the URL redirect section. The only difference is the URL variable in your Frida script will now have the value of our XSS payload via ngrok:
In a terminal window, execute the same Frida command that will execute your JavaScript code:
Press the button to navigate to the WebView and you should encounter the following:
Code Execution
Because The WebView is vulnerable to XSS, we can investigate other attack vectors that are more impactful to the mobile app. If we go back to the ConfigWebview function, we can see that a JavascriptInterface has been implemented:
We can gain access and call any functions from within the interface because the WebView implements a JavascriptInterface and is vulnerable to XSS.
Navigate to the WebViewInterface class within JADX:
This class has a function called displayFlag that returns a super-secret code. We can execute this function by using Frida to inject a URL that links to a malicious HTML script that calls the displayFlag function.
If you look in JADX inside of the addJavascriptInterface function, notice there’s a string of “Android”. Similarly, we will use that same keyword in our script:
We will then move the ExecuteFunction.html file into our webserver documents folder so that we can call it with ngrok. After that’s done, we can update our Frida script to point to the new script:
Then run the Frida command and open the app’s WebView:
Conclusion
We’ve reviewed how to create a custom Frida script to exploit Android WebViews in different ways. This blog has also covered how to analyze a WebView implementation in an Android application and how to determine if it’s vulnerable to exploitation. Learn more by registering to watch a hands-on tutorial in the May 2023 TechTalk to see these techniques demonstrated by the author.
We must emphasize that the techniques and methodologies described in this tutorial should only be used for ethical and lawful purposes. As pen testers and researchers, we take responsibility for educating developers and the general public about security risks so that measures can be taken to strengthen mobile application security.
NowSecure hopes this blog has provided some valuable insight into WebView exploitation. Safeguard your mobile apps from common mobile security and privacy issues with NowSecure Mobile Pen Testing as a Service (PTaaS) and NowSecure Platform continuous mobile application security testing.
