Skip to content

MASTG-TEST-0250: References to Content Provider Access in WebViews

Overview

This test checks for references to Content Provider access in WebViews, which is enabled by default and can be disabled using the setAllowContentAccess method in the WebSettings class. If improperly configured, this can introduce security risks such as unauthorized file access and data exfiltration.

The JavaScript code would have access to any content providers on the device, such as:

  • declared by the app, even if they are not exported.
  • declared by other apps, only if they are exported and if they are not following recommended best practices to restrict access.

Refer to WebViews for more information on the setAllowContentAccess method, the specific files that can be accessed, and the conditions under which they can be accessed.

Note 1: We do not consider minSdkVersion since setAllowContentAccess defaults to true regardless of the Android version.

Note 2: The provider's android:grantUriPermissions attribute is irrelevant in this scenario as it does not affect the app itself accessing its own content providers. It allows other apps to temporarily access URIs from the provider even though restrictions such as permission attributes, or android:exported="false" are set. Also, if the app uses a FileProvider, the android:grantUriPermissions attribute must be set to true by definition (otherwise you'll get a SecurityException: Provider must grant uri permissions").

Note 3: allowUniversalAccessFromFileURLs is critical in the attack since it relaxes the default restrictions, allowing pages loaded from file:// to access content from any origin, including content:// URIs.

If this setting is not enabled, the following error will appear in logcat:

[INFO:CONSOLE(0)] "Access to XMLHttpRequest at 'content://org.owasp.mastestapp.provider/sensitive.txt'
from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported
for protocol schemes: http, data, chrome, https, chrome-untrusted.", source: file:/// (0)

While the fetch request to the external server would still work, retrieving the file content via content:// would fail.

Steps

  1. Use Reverse Engineering Android Apps to reverse engineer the app.
  2. Use Static Analysis on Android to look for the relevant APIs.
  3. Use Obtaining Information from the AndroidManifest to obtain the AndroidManifest.xml.
  4. Use Analyzing the AndroidManifest to obtain the list of content providers declared in the app's AndroidManifest.xml file.

Observation

The output should contain:

  • A list of WebView instances, including the following methods and their arguments:
    • setAllowContentAccess
    • setJavaScriptEnabled
    • setAllowUniversalAccessFromFileURLs
  • A list of content providers declared in the app's AndroidManifest.xml file.

Evaluation

The test case fails if all the following applies:

  • setJavaScriptEnabled is explicitly set to true.
  • setAllowContentAccess is explicitly set to true or not used at all (inheriting the default value, true).
  • setAllowUniversalAccessFromFileURLs method is explicitly set to true.

You should use the list of content providers obtained in the observation step to verify if they handle sensitive data.

Note

The setAllowContentAccess method being set to true does not represent a security vulnerability by itself, but it can be used in combination with other vulnerabilities to escalate the impact of an attack.

Best Practices

MASTG-BEST-0011: Securely Load File Content in a WebView MASTG-BEST-0012: Disable JavaScript in WebViews MASTG-BEST-0013: Disable Content Provider Access in WebViews MASTG-BEST-0049: Restrict and Validate Access to Exported Content Providers

Demos

MASTG-DEMO-0029: Uses of WebViews Allowing Content Access with semgrep