MASTG-TEST-0335: WebView File Origin Access Relaxed by Configuration
Overview¶
WKWebView supports configuration that affects how JavaScript running from file:// origins can access other resources. In particular, allowFileAccessFromFileURLs allows JavaScript running in the context of a file:// URL to access content from other file:// URLs, while allowUniversalAccessFromFileURLs allows JavaScript running in the context of a file:// URL to access content from any origin. Both settings are considered dangerous when enabled because they relax the origin restrictions that normally apply to local content which increases the risk of vulnerabilities such as Cross-Site Scripting (XSS) or Local File Inclusion (LFI) leading to data exfiltration or other malicious actions.
This test checks whether the app enables either of these settings for any WKWebView instance. On iOS, these settings are commonly accessed through non-public or unsupported paths, for example by using key value coding on WKPreferences or WKWebViewConfiguration via setValue:forKey: or equivalent Swift calls.
Remember that JavaScript is enabled by default unless the app explicitly sets WKWebViewPreferences.setJavaScriptEnabled (deprecated since iOS 14) or WKWebpagePreferences.allowsContentJavaScript to false.
This test is related to, but distinct from, Overly Broad File Read Access in WebViews, which focuses on the native file system read scope granted to the WebView through loadFileURL(_:allowingReadAccessTo:). By contrast, this test focuses on JavaScript origin restrictions for content loaded from file:// URLs. Even if the file read scope is correctly restricted, enabling allowFileAccessFromFileURLs or allowUniversalAccessFromFileURLs can allow JavaScript (e.g. fetch(), XMLHttpRequest) running in a local page to access additional resources or communicate with remote origins.
Steps¶
- Extract the app as described in Exploring the App Package.
- Run a static analysis tool such as radare2 (iOS) on the app binary and search for references to the relevant configuration values.
Observation¶
The output should identify locations in the binary where the app references or enables the relevant configuration values.
Evaluation¶
The test case fails if the app enables allowFileAccessFromFileURLs or allowUniversalAccessFromFileURLs for a WKWebView that loads local file:// content.
Inspect each reported call site using Reviewing Disassembled Objective-C and Swift Code.
- Determine whether
allowFileAccessFromFileURLsorallowUniversalAccessFromFileURLsis explicitly used and set totrue, for example throughsetValue:forKey:or equivalent Swift calls. - Determine which
WKWebViewinstance receives the configuration and whether it handles sensitive information or functionality. - Determine whether that
WKWebViewloads localfile://content, for example using APIs such asloadFileURL(_:allowingReadAccessTo:)orloadHTMLString(_:baseURL:)with afile://base URL.
Note that some apps may use variables or configuration logic to set allowFileAccessFromFileURLs or allowUniversalAccessFromFileURLs, which can make them difficult to identify through static analysis alone. Dynamic analysis can help confirm whether the settings are enabled at runtime.
For the identified WebViews, determine whether attacker-controlled JavaScript could execute in the local page context, for example through HTML injection, JavaScript injection, or other untrusted content. Also determine whether the attacker could exfiltrate accessed data, for example by sending it to a remote server using fetch or XMLHttpRequest, or by embedding it in requests to external resources such as images or iframes.
Best Practices¶
MASTG-BEST-0033: Securely Load File Content in a WebView
Demos¶
MASTG-DEMO-0098: References to File Access in WebViews with radare2