Project Fortify, 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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: The extension CSP validator fails to identify modern sandbox tokens like ‘allow-top-navigation-by-user-activation’ for Platform Apps. This allow sandboxed pages to navigate the top-level AppWindow after a user gesture, bypassing intended navigation restrictions. Since AppWindows lack a URL bar, this provides a vector for phishing and origin spoofing.

Affected files:

• extensions/common/csp_validator.cc
• extensions/browser/app_window/app_web_contents_helper.cc
• content/browser/renderer_host/navigator.cc
• extensions/common/manifest_handlers/csp_info.cc
• services/network/public/cpp/web_sandbox_flags.cc

Estimated timestamp from git blame: 2017-01-19

Summary

A potential vulnerability in the Chrome Extensions CSP validator allows Platform Apps to bypass restrictions on top-level navigation from sandboxed pages. By using newer sandbox tokens such as allow-top-navigation-by-user-activation or allow-top-navigation-to-custom-protocols, an app can successfully pass manifest validation while retaining the capability to navigate its main window at runtime.

Root Cause Analysis

The function csp_validator::ContentSecurityPolicyIsSandboxed in extensions/common/csp_validator.cc is responsible for validating sandbox CSPs. For Platform Apps, it is designed to reject policies that allow top-level navigation. However, the check is implemented as an exact string match against the legacy kAllowTopNavigation constant (“allow-top-navigation”):

// extensions/common/csp_validator.cc
if (type == Manifest::Type::kPlatformApp &&
    token_lower_case == kAllowTopNavigation) {
  return false;
}

The validator fails to account for newer variants recognized by the runtime sandbox parser in services/network/public/cpp/web_sandbox_flags.cc. Consequently, if a Platform App specifies a token like allow-top-navigation-by-user-activation, the validator returns true, and the manifest is accepted.

Runtime Bypass Mechanism

At runtime, manifest-sandboxed extension pages are typically process-isolated (OOPIFs). When a sandboxed frame initiates a navigation targeting its parent (top.location = ...), the request is routed through RenderFrameProxyHost::OpenURL and Navigator::NavigateFromFrameProxy in the browser process.

This execution path bypasses the WebContentsDelegate::OpenURL and OpenURLFromTab methods. In Platform Apps, AppWebContentsHelper::OpenURLFromTab is the primary mechanism for blocking CURRENT_TAB navigations (the main window). Because the OOPIF navigation path skips this check, the top-level window can be navigated to an arbitrary external URL after a user gesture.

Potential Impact

Because AppWindow instances do not have a URL bar or other origin indicators, an attacker can navigate the window to a malicious site that mimics a legitimate login page or system prompt. Users have no visual way to verify that the application chrome is now hosting content from a different origin.

Potential Reproduction Steps

Note: These steps are based on code analysis and have not been executed on a live build.

1. Create a Platform App with a sandboxed page defined in the manifest:

   "sandbox": {
     "pages": ["sandbox.html"],
     "content_security_policy": "sandbox allow-scripts allow-top-navigation-by-user-activation"
   }
   

2. In sandbox.html, add a script that triggers a top-level navigation on click:

   <button onclick="top.location='https://attacker.example/'">Click to Continue</button>
   

3. Load the app and embed sandbox.html via an iframe.
4. Click the button and observe if the main AppWindow navigates to the external URL.

Suggested Fix

Update ContentSecurityPolicyIsSandboxed in extensions/common/csp_validator.cc to recognize and reject all top-level navigation sandbox tokens for Platform Apps. Ideally, the validator should use a logic consistent with the runtime parser in services/network/public/cpp/web_sandbox_flags.cc or maintain an exhaustive list of forbidden tokens.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

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.