T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:228
- Finding
- Unauthenticated Chrome DevTools Protocol Exposure Enables Browser Session Takeover<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:228-247` **Vulnerability Type**: Unauthenticated and unencrypted exposure of a privileged browser debugging interface **Risk Level**: High ### Vulnerable Code ```powershell chrome.exe --remote-debugging-port=9222 --remote-allow-origins=* ``` ```text 2. Firewall configuration (allow inbound port 9222) 3. Obtain the LAN IP address of the Windows computer (for example, `192.168.1.100`) ``` ```json "browser": { "profiles": { "user": { "driver": "remote", "cdpUrl": "ws://<your-windows-ip>:9222", "attachOnly": false, "color": "#00AA00" } } } ``` ### Technical Analysis The documented remote setup starts Chrome with a debugging port and the permissive `--remote-allow-origins=*` option, opens TCP port 9222 through the Windows firewall, and connects to the endpoint using an unencrypted `ws://` URL. Chrome DevTools Protocol provides highly privileged control over the browser. Depending on the available targets and Chrome configuration, a connected client can enumerate tabs, inspect page content, execute JavaScript in page contexts, read sensitive information rendered by authenticated applications, and perform browser actions as the logged-in user. The project explicitly describes this browser as the owner's logged-in Chrome session, increasing the sensitivity of the exposed interface. No authentication, encrypted transport, client certificate, tunnel, or source-address restriction is specified. Restricting use to a “trusted network” is only operational guidance and does not establish an access-control boundary. The wildcard origin option also removes an important restriction against untrusted web origins attempting to interact with the debugging service. ### Attack Path 1. A user follows the documented instructions and starts Chrome with remote debugging on port 9222 and wildcard allowed origins. 2. The user permits inbound access to TCP/9222 through the host fi ...[truncated 1447 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Do not expose CDP directly to the network** - Keep the debugging endpoint bound to loopback. - Do not create a general inbound firewall rule for TCP/9222. 2. **Use an authenticated encrypted tunnel** - Access the loopback-only endpoint through SSH port forwarding or a properly authenticated VPN. - Restrict VPN or tunnel access to explicitly authorized devices and users. - Apply host firewall rules limiting connections to the tunnel interface and approved source addresses. 3. **Remove wildcard origin access** - Eliminate `--remote-allow-origins=*`. - If an origin exception is unavoidable, permit only the exact trusted origin required by the deployment. 4. **Use a dedicated browser profile** - Do not expose the owner's primary logged-in browser. - Create an isolated automation profile containing only the accounts and data required for the task. - Avoid storing high-value credentials or unrelated authenticated sessions in that profile. 5. **Apply least privilege** - Set `attachOnly: true` where supported and appropriate. - Limit the accessible debugging targets and automation capabilities. - Run the browser under a non-administrative operating-system account. 6. **Protect transport and endpoint access** - Do not use plaintext `ws://` across a network. - Use an authenticated tunnel that provides encryption and server identity verification. - Monitor access attempts and terminate debugging sessions when they are no longer needed. 7. **Update the documentation** - Replace the direct LAN exposure example with a secure loopback-plus-tunnel configuration. - Clearly warn that CDP is a privileged administrative interface and must not be exposed directly to untrusted or shared networks. ]]>