代码安全审核的代码结果

[jglwiz]

High 级别发现

1. operate eval - 任意 JavaScript 执行

• 文件: src/cli.ts:498-503
• 描述: 接受用户输入的任意 JS 并在浏览器页面上下文中执行, 无任何过滤或沙箱. 可窃取 cookies、读取敏感 DOM 内容.
• 建议: 虽然是设计功能, 但应添加 --allow-eval 安全开关并在文档中明确风险.

2. Plugin 安装 - 不可信代码执行

• 文件: src/plugin.ts:570-601
• 描述: 从 GitHub 克隆插件后立即执行 npm install + 动态加载. 插件的 package.json 可包含 postinstall 脚本实现任意代码执行.
• 建议: 使用 npm install --ignore-scripts, 并显示安全警告.

---

Medium 级别发现

3 & 4. operate get text/value/html/attributes 及 operate type - DOM 注入

• 文件: src/cli.ts:381-402, src/cli.ts:420-429
• 描述: index 参数直接拼接进 JS 模板字符串, 无转义:
  document.querySelector('[data-opencli-ref="${index}"]')
• 恶意 index 如 "]') || eval(...)// 可注入执行.
• 建议: 使用 JSON.stringify() 转义 (同文件中 operate select 在 line 446 已正确使用了此方式).

5. 网络拦截器 - 敏感数据捕获

• 文件: src/cli.ts:311, src/interceptor.ts
• 描述: 拦截所有 fetch/XHR 响应体 (最大 200 条, 每条 50KB), 可能包含 auth tokens、PII、会话密钥.
• 建议: 默认过滤 auth/login/token 相关端点, 添加敏感数据警告.

---

Low 级别发现

┌─────┬───────────────────────┬───────────────────────────────┬────────────────────────────────────────────────────────────────┐
│ # │ 问题 │ 文件 │ 说明 │
├─────┼───────────────────────┼───────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 6 │ 命令注入 (有部分防护) │ src/external.ts:100-120 │ shell 操作符正则未覆盖所有情况, 但 execFileSync 提供了额外保护 │
├─────┼───────────────────────┼───────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 7 │ CDP 端口可预测 │ src/launcher.ts:38-45 │ 固定调试端口, 本机恶意进程可抢占或连接 │
├─────┼───────────────────────┼───────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 8 │ 路径遍历 (有部分防护) │ src/download/index.ts:220-227 │ sanitizeFilename() 替换了 /\ 但未显式处理 .. 文件名 │
├─────┼───────────────────────┼───────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 9 │ Cookie 文件权限 │ src/download/index.ts:184-205 │ 导出到 tmpdir 未设置 0o600 权限 │
└─────┴───────────────────────┴───────────────────────────────┴────────────────────────────────────────────────────────────────┘

---

[Astro-Han]

Thanks for the review. I went through the referenced code paths one by one.

A few of these findings are solid. A few are directionally right but framed too strongly. One or two point to the wrong place in the code.

Here is how I’d break it down:

1. plugin install is a real issue, and one we should treat seriously.
   The current flow clones a third-party repo, runs npm install, and then loads plugin code during discovery. Loading plugin code is the whole point of the plugin system, so that part is expected. Running npm install on an untrusted repo is the extra risk here because of lifecycle scripts. I think this one is valid. Using --ignore-scripts plus a clear warning would be a good first step.

2. The unsafe interpolation in some operate commands is real.
   index is inserted directly into several page.evaluate(...) strings and should be escaped consistently. One correction though: get html already escapes its selector input, so it should not be included in this finding. Also, select appears to have the same problem and should be fixed along with get text, get value, get attributes, and the autocomplete check inside type.

3. operate eval is dangerous, but I would not describe it as an unintended arbitrary code execution bug.
   That command is explicitly there to run user-provided JavaScript in the page context. So the behavior matches the feature. The part I agree with is that it has almost no guardrail right now. A warning, confirmation step, or explicit opt-in flag would make sense.

4. The network capture finding is basically right, but this is more of a privacy and defaults problem than a classic vulnerability.
   operate open starts capture automatically, and operate network can show previews or full response bodies. That means tokens or other sensitive data can end up in local terminal output. We should probably narrow the default capture behavior and add stronger warnings. Still, this is local inspection behavior, not silent exfiltration.

5. The external.ts command injection claim looks overstated.
   The regex filtering is not a full shell parser, but the code is not handing the raw string to a shell either. It uses execFileSync(binary, args). That matters. I can see an argument for tightening validation, but I do not think this is a clear command injection bug as written.

6. The fixed CDP port point is fair, but low severity.
   Ports are predefined per app, so another local process could race to bind or attach. That is a real localhost hardening issue. I would not rank it with the stronger findings above.

7. The path traversal citation is off, but the broader area still deserves attention.
   The lines cited in the report are cookie export code, not the filename sanitization path. So that specific reference does not support the claim. That said, after checking the download paths more broadly, there are filename-handling cases that should be tightened, including one path where media.filename is joined into the output path directly.

8. The cookie file permissions finding is valid.
   The exported cookie file is written without explicitly locking down permissions. That is a straightforward hardening fix and should be addressed.

So my rough split would be:

Clearly valid and worth prioritizing:

• plugin install running third-party install scripts
• unsafe interpolation in several operate subcommands
• cookie temp file permissions

Valid, but better framed as safety-boundary or default-behavior issues:

• operate eval
• automatic network capture and response-body display
• fixed CDP ports

Overstated or inaccurately cited:

• the external.ts command injection claim
• the specific path traversal citation in the report