X (Formerly Twitter): Android WebViews in Twitter app are vulnerable to UXSS due to configuration and CVE-2020-6506

Summary:

CVSS score: 8.1 / High / CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Embargo notice: Do Not Disclose publicly until https://crbug.com/1083819 is disclosed.

Twitter for Android is affected by a UXSS vulnerability due to its configuration of Android WebView and CVE-2020-6506.

Vendor mitigation is recommended to protect unpatched WebView users, due to its impact and ease of exploitation. Mitigation options which minimize breaking changes are provided for various use cases.

Android WebView is the system component which allows Android apps to display web pages. Apps typically use Android WebView directly or via frameworks/libraries.

CVE-2020-6506 is a universal cross-site scripting (UXSS) vulnerability in Android WebView which allows cross-origin iframes to execute arbitrary JavaScript in the top-level document. This vulnerability affects vendors which use Android WebView with a default configuration setting, and run on systems with Android WebView version prior to 83.0.4103.106.

All relevant details to understand and mitigate the vulnerability should be in this report. As an affected vendor, you may request access to the restricted crbug for full details and discussion, subject to acceptance by the Chromium Security Team. To request access, send me an email.

CVE-2020-6506 Details:

Embargo notice: Do Not Disclose publicly until https://crbug.com/1083819 is disclosed.

An Android WebView instance with WebSettings.setSupportMultipleWindows() kept at default or set to false allows an iframe on a different origin bypass same-origin policies and execute arbitrary JavaScript in the top document.

To perform the attack, an iframe can call window.open() with a javascript: URL. Other methods of opening a new window, such as a link with target=”_blank” and href=”javascript:…”, can also be used to perform the attack.

Performing the attack requires a single user interaction (a tap/click or a keypress). The malicious iframe does not need to be visible, and can obtain the keypress interaction while a user attempts to type in the top-level document (no direct iframe interaction required).

The patched version of Android WebView (83.0.4103.106) was released on Monday, June 15th, 2020: https://chromereleases.googleblog.com/2020/06/stable-channel-update-for-desktop_15.html

Vendors can and should mitigate CVE-2020-6506 to protect their users using unpatched Android WebView versions.

Vendor Details:

Twitter for Android uses WebViews to render the URL in Video Website Cards. This type of Card uses the vulnerable WebView configuration, therefore there’s two ways a user can reach the vulnerable WebView:

1. Advertiser creates legitimate Video Website Card pointing to the advertiser URL, then shares it via regular Tweets or paid advertising campaigns.
2. Attacker creates Video Website Card with the user-trusted target URL, then shares it via regular Tweets or paid advertising campaigns.

If the advertiser/target URL has a malicious or compromised iframe, the iframe can perform the UXSS attack with minimal user interaction (tap/click or keypress). If there’s sensitive data in the WebView, it is vulnerable to exfiltration. Page contents and data can also be altered to benefit the attacker, such as requesting sensitive info from the user while purporting to be the advertiser/target URL.

Based on Twitter’s use case, the suggested solution is option 1a or 1b. The final determination is left to the vendor. Reference implementations for each option is available by request.

If none of these options appear suitable, please provide feedback to address concerns. Other vendors could have the same concerns, so your input is appreciated to best mitigate for all affected vendors.

Potential Solutions:

Vendors generally have two choices to mitigate for unpatched WebView users:

1. Enable multiwindow support. If needed, implementation options exist to mimic single-window behavior and minimize breaking changes. Does not require multi-tab UI. Suitable for browsers and frameworks.
2. Keep multiwindow support disabled, and strictly limit WebView rendering to trusted content only. Suitable for non-browser apps, and for frameworks when used in non-browser apps.

Detailed choices:

• Option 1a: Enable multiwindow support, and create a new tab in UI or block window creation.

  • Suitable and preferred choice for browsers.
  • Implementation: Set WebSettings.setSupportMultipleWindows() to true, and handle onCreateWindow() callback to create new tab in UI or block window creation.
  • Potential downsides: If all window creation is blocked, user experience may be negative.

• Option 1b: Enable multiwindow support, and mimic single-window behavior via WebView instance replacement.

  • Suitable for browsers and frameworks. Preferred choice for frameworks.
  • Potential implementation: Set WebSettings.setSupportMultipleWindows() to true, and handle onCreateWindow() callback to create a new WebView on top of existing WebView. Rebind any event listeners, state info, and other logic to the new WebView. Finally, destroy the old WebView as soon as possible.
  • Potential downsides: May cause breaking changes if existing code expects a single WebView instance for duration of use.
    To minimize breaking changes, vendor could add an abstraction layer to internally track WebView instances. The abstraction could perform necessary setup/cleanup for each instance to maintain current WebView behavior (such as JS injection on first page load or each page load, event listeners, state, etc.). The abstraction layer could then seamlessly provide existing interfaces to other layers.

• Option 1c: Enable multiwindow support, and mimic single-window behavior via WebView instance reuse.

  • Suitable for browsers and frameworks.
  • Only if Option 1b is not feasible, and existing code expects a single WebView instance for duration of use. Minimizes breaking changes at the cost of complexity and fragility.
  • Potential implementation: Set WebSettings.setSupportMultipleWindows() to true, and handle onCreateWindow() callback. In the callback, create a temporary WebView with shouldOverrideUrlLoading() which returns true (prevents loading) and stores the attempted URL in a variable. Filter the attempted URL to ensure it is a safe HTTP(S) URL, then call loadUrl() on the initial WebView with the attempted URL. Finally, destroy the temporary WebView when convenient.
  • Potential downsides: May still cause breaking changes. May break if Android WebView behavior changes in future. Adds complexity which may be difficult to maintain.

• Option 2: Keep multiwindow support disabled, and enforce strict origin allowlist.

  • Suitable for non-browser apps, and for frameworks when used in non-browser apps.
  • Because the vulnerability is not mitigated with this option, WebViews must only render first-party trusted content in top-level window and iframes. If using cross-origin iframes, they must be properly sandboxed. Cross-origin iframes must avoid sandbox=“allow-popups allow-top-navigation allow-scripts” because this allows exploitation.
  • Potential downsides: Any bypass of origin filtering allows exploitation of unpatched WebView users. For frameworks with configurable origin allowlists, developers can misconfigure allowlists and make their apps vulnerable.

Adjacent phishing mitigation: If the current page URL is not guaranteed to be shown to the user, origin allowlists are recommended to mitigate phishing risks. This is an adjacent vulnerability, but it’s a good opportunity to mitigate it because URL filtering is likely to be implemented as part of the UXSS mitigation.

Additional implementation details for options 1a and 1b: When using multiple WebView instances simultaneously, ensure to destroy the background WebView, unload the background page, or handle background page events safely. Otherwise, background pages can perform actions which should only be allowed by a foreground page, which often cause other security issues.

Environment:

Device: Samsung Galaxy S10 + Emulated Android device
OS version: Android 10 (on both devices)
Twitter version: 8.50.0-release.02

Steps To Reproduce:

Prerequisites:

• System with unpatched Android WebView (prior to version 83.0.4103.106)
• Twitter Video Website Card with landing URL pointed to a PoC URL. (Provides WebView with WebSettings.setSupportMultipleWindows() kept at default or set to false.)
  • PoC 1: https://twitter.com/AlesandroOrtizR/status/1275538453183238144
  • PoC 2: https://twitter.com/AlesandroOrtizR/status/1275538647702548480

Steps To Reproduce, tap/click interaction, visible iframe:

1. Using the PoC 1 Card, navigate to https://alesandroortiz.com/security/chromiumwebview/cve-2020-6506.html
2. Tap/click iframe.

Steps To Reproduce, keypress interaction, hidden iframe:

1. Using the PoC 2 Card, navigate to https://alesandroortiz.com/security/chromiumwebview/cve-2020-6506-keypress-2.html
2. Tap the “search this site” input field to focus it. (This input field is in the parent page, not the iframe.)
3. Start typing. Before/while you type, the focus will be stolen by the hidden iframe. After typing a character while the iframe input is focused, the attack is immediately performed. (This can be made more subtle by delaying the focus theft, see code comments.)

Expected Behavior:
JavaScript is not executed in top-level document. HTML is not written to top-level document and JS alert dialog is not shown (or a JS alert dialog is shown but with info from iframe document).

Observed Behavior:
JavaScript is executed in top-level document. HTML is written to top-level document, and if the WebView allows JS alert dialogs, a JS alert dialog is also shown with info from top-level document.

Supporting Material/References:

• twitter-cve-2020-6506.mp4: Screen recording of both reproduction cases.
• Twitter-CVE-2020-6506-Report.pdf: Original report in PDF, in case any formatting is missing or difficult to parse in HackerOne.

Embargo notice: Do Not Disclose publicly until https://crbug.com/1083819 is disclosed.

Impact

A malicious iframe on any page within the vulnerable WebView can perform a UXSS attack on the top-level document with minimal user interaction.