Flapjack, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: The session restoration process on iOS constructs a WKWebView interactionState blob without sanitizing URLs in the NavigationItem. This allows an attacker to sync a malicious javascript: URL into a victim’s history. When the victim navigates to this history entry, the JavaScript executes in the context of the current origin, leading to a potential Universal Cross-Site Scripting (UXSS) vulnerability.

Affected files:

• ios/web/navigation/synthesized_session_restore.mm
• ios/web/navigation/navigation_manager_impl.mm

Estimated timestamp from git blame: 2021-11-18

Description

A potential Universal Cross-Site Scripting (UXSS) vulnerability exists in the session restoration mechanism of Chrome for iOS. The vulnerability stems from a lack of URL validation when constructing the WKWebView interactionState binary blob from synced session data.

The function SynthesizedSessionRestore in ios/web/navigation/synthesized_session_restore.mm creates the session state blob from a list of NavigationItem objects. It directly injects the URL string into the kEntryURL and kEntryOriginalURL properties of the state dictionary without verifying that the scheme is safe (e.g., restricting to HTTP/HTTPS/File):

    [entries addObject:@{
      kEntryData : entry_data.AsNSData(),
      kEntryOriginalURL : base::SysUTF8ToNSString(item->GetURL().spec()),
      kEntryExternalURLPolicy : external_url_policy,
      kEntryTitle : base::SysUTF16ToNSString(item->GetTitle()),
      kEntryURL : base::SysUTF8ToNSString(item->GetURL().spec()),
    }];

This data ultimately originates from components/sync_sessions/synced_session.cc where SessionNavigationFromSyncData accepts URLs from the sync protobuf without rejecting javascript: schemes. Consequently, an attacker can sync a malicious session containing a javascript: URL.

When NavigationManagerImpl::Restore calls SynthesizedSessionRestore, the resulting blob is passed to [WKWebView setInteractionState:]. WebKit implicitly trusts the contents of this blob and populates its native history stack with the javascript: entry.

If a user opens the restored tab and performs a back/forward navigation to the malicious entry, WebKit executes the javascript: URL in the context of the currently loaded origin. Because this is a history navigation handled internally by WebKit as a script execution, it bypasses Chrome’s CRWWKNavigationHandler::decidePolicyForNavigationAction delegate, which normally blocks javascript: navigations.

Potential Attack Steps

Note: These steps are based on static analysis; a working Proof of Concept has not been verified dynamically.

1. An attacker constructs a malicious sync_pb::SessionSpecifics payload containing a tab with two history entries: a legitimate target URL (e.g., https://example.com) and an adjacent javascript: URL (e.g., javascript:alert(document.domain)).
2. The attacker syncs this payload to their Chrome account and tricks the victim into signing in, or compromises the victim’s account to inject the payload.
3. The victim’s iOS Chrome instance pulls down the synced session data.
4. The victim navigates to “Recent Tabs” and opens the synced tab.
5. The tab loads the legitimate URL, establishing the active document context.
6. The victim interacts with the app by swiping back or clicking the back/forward button, triggering a navigation to the malicious history entry.
7. WebKit executes the injected JavaScript within the context of the legitimate origin, completing the UXSS.

Suggested Fix

Sanitize URLs before encoding them into the interactionState blob. In SynthesizedSessionRestore, verify that item->GetURL().SchemeIsHTTPOrHTTPS() or use a broader allowlist of safe schemes (e.g., about:blank, chrome://). If a URL contains an unsafe scheme like javascript:, the entry should either be omitted from the restoration payload or the URL should be neutralized.

Evaluated with Chrome root at commit: cc901875d53bf4e4fe0e01f02843871da4106e70

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.