# CDP Browser Bridge Session Enumeration and Takeover

- **Severity:** Medium
- **Signature ID:** `7f3c1d9a-2b64-4e8f-9c05-6ad1e3f8b472`
- **OWASP:** ASI01 (Agent Authorization and Control Hijacking)

## Summary

Chrome and Chromium-based browsers can expose a debugging port (CDP) that lets any connecting process list open browser tabs and attach to them for remote viewing or control. This rule flags when a process lists available sessions and then attaches to one, especially when the target is reachable over the network, involves changing someone else's session, or touches many tabs at once.

## How the attack works

An attacker or automated tool first calls the CDP HTTP endpoint that lists active browser sessions (GET /json or /json/list), learning what tabs or windows exist. It then attaches to one of them via a devtools page, browser, or inspector path, which is the same handshake used to open a live control channel. The rule only fires when this list-then-attach sequence happens together, in order, within five minutes, and one extra condition is also present: the bridge is reachable from the network rather than just localhost, the request also modifies another session (opening, closing, or activating a tab it doesn't own), or the process attaches to three or more distinct browser targets. Simple version probes, one-off local attaches, or enumeration with no follow-up are not reported.

## Why it matters

An exposed CDP debugging port lets someone view and potentially steer a browser session that isn't theirs, including one driven by an AI agent, which can mean stolen session data, hijacked web interactions, or unauthorized control of an in-progress agent task. This rule sees the HTTP setup for that access, not the actual WebSocket control traffic, so it flags exposure and attach behavior rather than proving remote control occurred.

## What you can do

- Bind CDP/debugging ports to localhost only and block them at the network/firewall layer; never expose them to the general network.
- Restrict which processes and users can reach the debugging port, and require authentication or a proxy in front of it if remote access is genuinely needed.
- Review any alert involving a non-loopback bridge as a real exposure of the debugging port, not noise — treat it as a finding even if no further activity is visible.
- For CI or shared browser containers, isolate them from other tenants and rotate/close sessions when jobs finish so enumeration surfaces less.

## Known benign look-alikes

- Playwright, Puppeteer, chrome-remote-interface or Selenium CDP attaching to an already-running browser they legitimately own. These normally probe /json/version and connect at the browser level; the rule requires the /json(/list) enumeration -> /devtools/page attach pair PLUS an escalator, so the common loopback launch path does not report.
- Browser-automation test harnesses in CI that intentionally reuse a shared remote Chrome container over the network. These will report (non-loopback escalator) and should be triaged once and understood as a real exposure of the debugging port, not silenced by host.
- Legitimate HITL takeover workflows where a human operator is meant to view and steer the agent's browser. Indistinguishable from an attacker at this layer by design - the rule reports so the exposure can be reviewed, and never blocks.
- Session-manager tooling that opens many tabs via /json/new during normal work, which can satisfy the mutation escalator after a genuine enumeration.

## References

- https://chromedevtools.github.io/devtools-protocol/
- https://attack.mitre.org/techniques/T1219/
- https://attack.mitre.org/techniques/T1021/

---
Source: https://www.netzilo.com/threats/cdp-browser-bridge-session-takeover