# Navigation to `chrome-extension://` origin (internal pages) from the web

Brave's navigation blocklist for chrome-extension:// origins omitted the ftp scheme, letting ftp:// pages open internal extension pages and preferences.

- Payout: hidden
- Severity: low
- Program: Brave Software
- Found by: metnew
- Disclosed: 2018-09-24
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/378805
- Library page: https://bugbountylibrary.com/r/h1%3A378805
- Tags: area:os domain:browser impact:integrity kind:bounty platform:hackerone sev:low tech:chromium technique:source-review vuln:access-control vuln:auth-bypass

**Target:** Browser navigation policy / extension origin handling
**Root cause:** The extension navigation allow/deny check only blocked http and https schemes from navigating to chrome-extension:// origins, omitting ftp (and file) schemes.
**Steps:**
1. Start an ftp server serving exploit.html (`npm i ftpd && node ftp-server.js`)
2. Open `ftp://localhost:7002/exploit.html`
3. Click "Go to payment settings" which calls `window.open` to a chrome-extension:// URL
4. `about:preferences#payments` page opens, confirming navigation to extension origin succeeded
**How found:** Code review of the navigation restriction in atom_browser_client_extensions_part.cc, noticing only http/https were checked and hypothesizing other schemes (ftp, file) bypass it.
**Exploitation:** An attacker hosts a page on an ftp:// origin; a click triggers window.open to a chrome-extension:// internal page, bypassing the scheme check. Impact requires a vulnerable extension page (e.g. reflected XSS) to escalate to code execution in extension context.
**Escalation:** Chain with reflected XSS in an extension's bundled HTML to execute arbitrary code in the extension's context.
**Insight:** When a security check enumerates blocked schemes (http/https), test the complement: ftp, file, blob, data, and custom schemes often slip past allow/deny lists written as explicit enumerations.