Browser Auth

Start a secure remote browser tunnel for manual user authentication (solving Captchas, 2FA, logins) and capture session data. Built for AI Commander.

Security Scan

The skill implements the described remote browser tunnel and session capture, but there are security-relevant mismatches and defaults (public bind, on-disk session storage, token logging) that make its behavior surprising and riskier than the documentation indicates.

Purpose & Capability

The code, required binaries (node, chromium-browser), and npm deps (express, socket.io, playwright-core) match the stated purpose of launching a local headless Chromium and streaming control/screenshots for manual authentication. However the SKILL.md claims a default local bind of 127.0.0.1 and 'No Persistence', while the runtime behavior differs (see instruction_scope and environment_proportionality).

Instruction Scope

Runtime instructions align with the code's workflow (start server, share link, verify, delete session file). BUT the server, when invoked without AUTH_HOST set, binds to 0.0.0.0 by default (code: host = process.env.AUTH_HOST || '0.0.0.0') contrary to the SKILL.md claim. The code writes sensitive session data (cookies and localStorage) to a local session file without encryption and does not auto-delete it. The server prints an access link containing the token to stdout, which can leak the token via logs. These behaviors broaden the exposure surface beyond what's described.

Install Mechanism

The provided install step uses a standard npm install (express, socket.io, playwright-core). This is a common pattern for Node skills and is traceable to npm; it is not an arbitrary download. Installing playwright-core is moderately heavyweight and will require network access to the npm registry, but no untrusted URLs or extract-from-URL steps are present.

Credentials

The registry lists no required env vars, but SKILL.md and the code reference AUTH_HOST, AUTH_TOKEN, and BROWSER_PROXY. If AUTH_HOST is unset the code will bind publicly (0.0.0.0). The skill captures and persists session cookies/localStorage to disk (session.json) — highly sensitive data that the documentation downplays by saying 'No Persistence'. Requiring no credentials is coherent, but the combination of token-in-query links and token logging increases risk if the host is exposed.

Persistence & Privilege

The skill does not request platform-wide privileges and always:false (not force-included), which is good. However it persists sensitive artifacts to the filesystem, prints the access link/token to stdout, and — via its default host behavior — can expose the server to the network unintentionally. Those factors increase privilege/exposure risk in practice even though the skill does not modify system-wide configs.

What to consider before installing

This skill largely does what it says (launches a headless Chromium and captures cookies/localStorage), but several details are risky or inconsistent with its documentation. Before installing or running it: - Treat the session file (session.json) as highly sensitive — delete it immediately after use and restrict file permissions. - Always explicitly set AUTH_HOST=127.0.0.1 when starting the server (do not rely on defaults) to avoid accidental public exposure. - Always set an explicit AUTH_TOKEN and share it over a secure channel; do not rely on auto-generated tokens if running in insecure environments. - Run the skill inside an isolated environment (dedicated VM or container) and firewall the host/port; do not run on a host with public network access without a secure tunnel (SSH/Tailscale/Cloudflare Tunnel). - Be aware the server prints the access URL/token to stdout — avoid running it where logs are collected or visible to others. - Review the code and confirm npm packages will be installed from the official registry; consider installing dependencies in an isolated environment. Given the mismatches (public bind default, on-disk persistence, token logging), proceed only if you understand and mitigate these risks. If you need, ask the author to change the default host to 127.0.0.1, avoid printing tokens in cleartext, and add an option to encrypt or avoid writing session data to disk by default.

This skill allows the agent to request the user to perform a manual login on a website and then capture the session cookies/localStorage for further automated work.

🚨 Security & Risk Mitigation

We take security seriously. Below is how we address common concerns related to remote browser control:

1. Remote Code Execution (RCE) Protection

• Always Sandboxed: Chromium runs with the system sandbox ENABLED. There is no option to disable it in the code. This prevents a malicious website from escaping the browser and executing code on your host.
• Isolation Recommendation: We recommend running this skill within an isolated container (Docker) or a dedicated VM for an extra layer of protection.

2. Token Leakage (Referrer Protection)

• Referrer Policy: The server enforces Referrer-Policy: no-referrer. This ensures that even if you navigate to an untrusted site, your secret AUTH_TOKEN is NEVER sent in the HTTP Referer header.
• URL Cleansing: The interface automatically clears the token parameter from your browser's address bar immediately after the page loads.

3. Data Sensitivity

• Session Artifacts: The session.json file contains active login cookies. Treat it with the same level of security as a password.
• Mandatory Cleanup: Always delete the session file immediately after the agent finishes its task.
• No Persistence: This skill does not store credentials long-term or exfiltrate them to external servers.

4. Network Exposure

• Default Local Bind: By default, the server binds to 127.0.0.1.
• Secure Access: If you need remote access, do not bind to 0.0.0.0 directly. Instead, use a secure tunnel like Tailscale, Cloudflare Tunnel (cloudflared), or an SSH tunnel.

When to Use

• When a website requires manual interaction to solve Captcha or 2FA.
• When bot detection prevents automated login.
• When you want to authorize an agent without sharing your password.

Workflow

1. Request Auth: Start the tunnel using scripts/auth_server.js.
2. Provide Link: Share the link (including token) with the intended user over a secure channel.
3. Wait for Session: The user logs in and clicks DONE in the web UI.
4. Verify: Use scripts/verify_session.js to confirm the session is valid.
5. Cleanup: Delete the session file once the task is complete.

Tools

Start Auth Server

AUTH_HOST=127.0.0.1 AUTH_TOKEN=mysecret node scripts/auth_server.js <port> <session_file>

Verify Session

node scripts/verify_session.js <session_file> <target_url> <expected_text>

Runtime Requirements

Requires: express, socket.io, playwright-core, and a system chromium-browser.