Android Security : A Checklist For Exploiting WebView

Source :- https://tutorialboy24.blogspot.com/2022/10/android-security-checklist-for.html

WebView is a web browser that can be built into an app, and represents the most widely used component of the Android ecosystem; it is also subject to the largest number of potential errors. If it is possible to load arbitrary URLs or to execute JavaScript code controlled by the attacker, we most often have to deal with the leaking of authentication tokens, the theft of arbitrary files, and access to arbitrary activities – which can even lead to remote code execution.

A Typical Example of the Vulnerability

The commonest version is the case where there are no checks or limitations on loading arbitrary URLs inside WebView. Let’s suppose we have a DeeplinkActivity that processes a URL such as myapp://deeplink.

File AndroidManifest.xml

Inside, it has the ability to process WebView deep links:

In this case the attacker can carry out a remote attack to obtain the user’s authentication token by creating a page with the following code:

When the user taps Attack, the vulnerable app automatically opens https://attacker.com in the built-in WebView, adding the user’s token to the header of the HTTP request. The attacker can therefore steal it and gain access to the victim’s account.

Insufficient URL validation

Developers sometimes try to check which URLs are loaded in WebView but do so incorrectly. OVAA (Oversecured Vulnerable Android App) contains an example of this vulnerability. The scan report for it looks like this: vulnerability

In this section, we shall look at typical attacks on URL validation.

Only checking host

This is one of the most typical errors. Only the value of host is checked, forgetting about scheme:

The attacker can use, for instance, the javascript, content or file schemes to bypass the checks:

• javascript://legitimate.com/%0aalert(1)
• file://legitimate.com/sdcard/exploit.html
• content://legitimate.com/

In the case of the javascript scheme, the attacker can execute arbitrary JavaScript code in WebView. In the case of the content scheme, they can claim a content provider with the specified authority and return arbitrary files by using the ContentProvider.openFile(...) method. The file scheme allows them to open a file in the public directory.

Logic errors in the verification process

We also encounter an error where developers use logically incorrect methods to verify URLs:

We have also seen the String.contains(...) method used. In this case there is an obvious way to bypass the verification.

Attack using HierarchicalUri and the Java Reflection API

Let’s glance at an example of seemingly secure URL validation:

android.net.Uri is widely used on Android, but in fact it is an abstract class. android.net.Uri$HierarchicalUri is one of its subclasses. The Java Reflection API makes it possible to create a Uri capable of bypassing this check.

File MainActivity.java:

File TestActivity.java:

The log will be as follows:

This attack is only possible by using a third-party app installed on the same device, and if the vulnerable app takes a Uri object controlled by the attacker and works exclusively with that. If we make a change such as

Important! Beginning from API level 28 (Android 9), the use of internal interfaces is forbidden – but this can easily be bypassed by using tools such as RestrictionBypass.

Backslashes on old versions of Android

On devices with API level 1-24 (up to Android 7.0), android.net.Uri and java.net.URL parsers works incorrectly. If we run the following code

Thus, this attack allows us to bypass checks such as

If your app contains a value of minSdkVersion lower than 25, you need to protect yourself against this attack.

There are several possible protections:

• set the value of minSdkVersion to 25 or above.
• use the java.net.URI class for validation: it throws a URISyntaxException if backslashes are discovered in the authority part.
• verify the value of authority, not host.

Universal XSS

Besides the obvious cases, where an attacker controls the baseUri and data parameters in a call to

and receives XSS on an arbitrary website, there is also another widespread version of UXSS. Let’s look at the code of the exported WebActivity:

In this case onCreate is called when the activity is launched for the first time, and onNewIntent is called each time the activity receives a new Intent. The following code allows to achieve UXSS in the vulnerable app:

When it is first run it opens a domain within whose context arbitrary JavaScript code must be executed. The second time, this code is executed using the javascript scheme.

JavaScript code injections

Developers often concatenate data with JavaScript code insecurely, leading to XSS on the domain that is loaded:

or with the javascript scheme:

If you concatenate data with JavaScript code, we advise you to use JSON methods to sanitize the data.

This attack resembles DOM-based XSS in the web world. But on Android, depending on the WebView configurations we shall explain below, it is possible to carry the exploitation of the vulnerability further.

Attacks on internal URL handlers

Many Android apps employ custom URL handlers using the WebViewClient.shouldOverrideUrlLoading(...) method, but their functionality is often implemented insecurely:

At the moment each URL is loaded, WebView calls the shouldOverrideUrlLoading method to check whether it needs to be handled by the app or by WebView itself. As a rule, this is used to launch activities or handlers for an additional list of deep links. It is important to note that even if the attacker cannot bypass the check on loading arbitrary domains, they may still be able to try to exploit the handlers.

For instance, in this example, the attacker can launch arbitrary activities (we have analyzed this attack in more detail elsewhere) and achieve XSS on the page that is loaded, by opening https://legitimate.com/?page='-alert(1)-'.

Attacks on JavaScript interfaces

If the app adds JavaScript interfaces to WebView, an attacker can gain access to them if they can execute arbitrary code within this WebView. As a rule, JS interfaces are divided into two categories: the first return data (such as geolocation or the user’s authentication token), and the second perform actions (such as taking a photo or sending queries to designated endpoints).

In this case, WebView automatically creates a JavaScript object with the specified name and with methods that are also imported from the Java code. To obtain the user’s token from this example, all we need to do is run the following code:

Attacks where universal/file access from file URLs is enabled

This attack is possible where universal/file access from file URLs is turned on:

and the attacker can load an arbitrary URL into WebView:

In this case, the attacker can use XHR queries to obtain the content of arbitrary files to which the vulnerable app has access:

The scan report for OVAA includes an example of notification concerning this vulnerability:

Theft of arbitrary files via file choosers

Developers often want to let users choose from files stored on their devices. HTML provides, for example, the <input type="file" .../> element for this purpose. On Android, you need to implement the WebChromeClient.onShowFileChooser() method to describe the file choosing logic. Usually, it will make use of implicit intents to obtain URIs, which are passed to the ValueCallback.onReceiveValue() method with no validation of any kind. This makes it possible for attackers to intercept the intent and pass the URI of a protected file, which can lead to the theft of arbitrary files.

Example of a vulnerable app:

If you look at the Android sources (or rather the source for the com.google.android.webview app on Googled Androids), you can discover that even the standard FileChooserParams.onShowFileChooser() method returns an implicit intent. Usually, developers also use implicit intents to choose files. These intents can be intercepted by an attacker, who then returns the URI of a protected file.

Example attack:

HTML code of the page

Code of attacker’s app

File AndroidManifest.xml

File PickerActivity.java:

Remediation:

Oversecured recommends following the tips set out in the section on Exploiting URI attacks via a content scheme. This universal technique can also protect WebView from the theft of protected files.

Attacks on content providers

Content access (or access to any content:// URIs) is turned on by default, which means WebView can use any content providers available to the app on the user’s device. We have encountered vulnerabilities where providers didn’t only record or supply data but also performed dangerous actions:

In this example, it would have been possible to load a URL like content://provider.authority/debug into WebView and then read dumped data on the SD card.

So, if this setting is not explicitly turned off, you need to pay attention to exactly what the content providers are doing – especially those that are not exported.

Installing cookies for third-party sites

Sometimes WebView uses cookies for authorization instead of headers like Authorization. To do this, the app uses the CookieManager and sets a token in the cookie for the URL, which can be controlled by the attacker, and then opens it:

In this case, you must first validate the URL and then install the cookie. For example, if a sensitive cookie is installed for the attacker’s domain, but is not loaded immediately, then this still poses a threat, because this domain can be opened elsewhere in the app (remember that in one app all WebViews have common cookie storage if the default configuration is used).

The best solution for this architecture is to create a list of trusted domains and pre-install authorization cookies for them.

Recommendations

To prevent vulnerabilities, or at least to reduce their potential impact, we recommend performing the following actions for each WebView you use:

• switch off geolocation, by calling WebSettings.setGeolocationEnabled(false).
• switch off content access, by calling WebSettings.setAllowContentAccess(false).
• switch off file access by calling WebSettings.setAllowFileAccess(false) if your minSdkVersion is 29 or below.
• switch off file access from file URLs by calling WebSettings.setAllowFileAccessFromFileURLs(false) if your minSdkVersion is 15 or below.
• switch off universal file access from file URLs by calling WebSettings.setAllowUniversalAccessFromFileURLs(false) if your minSdkVersion is 15 or below.
• if any external links are loaded in WebView, it is essential to validate the origin that is loaded correctly – checking both scheme and host.
• wherever JavaScript is called with externally obtained data, you just make sure it has been sanitized.
• if internal handlers change URLs into Intent objects, the component and selector fields of the latter must be reset. For additional security, verify that the activity opened with the given Intent is exported and that either no permissions are set for it, or else they have a protection level set to normal.
• if the app has custom implantation of WebResourceResponse, you need to make sure that an attacker cannot obtain the content of arbitrary files.
• make sure the debugging of web contents option is switched off in release builds.
• do not install sensitive cookies for unverified domains.

Source :- https://tutorialboy24.blogspot.com/2022/10/android-security-checklist-for.html