Polymarket 项目安全审计报告
以下内容为对两个 Polymarket 相关套利/交易 Bot 项目的完整安全审计结果汇总（中文）。
说明：审计覆盖点包括私钥泄露、隐藏网络调用、可疑代码模式、交易安全、依赖风险、Telegram/Redis 安全、Monkey-patch 使用等。
总体结论：未发现后门，但存在多项安全隐患
两个项目均未发现恶意后门或私钥窃取代码。所有出站网络连接均指向合法的 Polymarket/Polygon/Binance/Coinbase/Deribit 等官方 API。但两个项目都存在不同程度的安全隐患，需要注意并修复。
一、Polymarket-Autobetting（风险等级：⚠️ 中等）
- 安全亮点
- 未在代码中找到打印或主动发送私钥的行为
- 未发现 eval/exec/compile 等直接执行代码的危险用法（除了少量动态 import 用法，见下文）
- 所有外部 URL 均为官方 Polymarket/Polygon 等服务
- 主要风险与证据
Telegram Bot 运行时修改 .env（高风险）
- 文件：scripts/bots/telegram_bot.py（约 172-205 行）
- 问题：_update_env_5m_fill_preset() 在运行时直接读写 .env 文件，攻击者若获得 Bot 控制权，可修改关键配置，可能影响签名密钥或其它凭据。
- 建议：移除或限制运行时写 .env；改为在受控流程中部署配置变更，或使用受控数据库/配置服务。
Telegram Bot 进程管理/重启（中高风险）
- 文件：scripts/bots/telegram_bot.py（约 1151-1169 行）
- 问题：_restart_script_by_pid() 接受脚本路径/名称，需确认调用方不会将未经校验的用户输入当作路径传入，从而发生命令注入。
- 建议：对可重启的脚本使用白名单，并尽量避免直接从用户输入构建命令行。
无限 ERC20 授权（中风险）
- 文件：scripts/tools/approve_allowance.py、src/utils/auto_approve.py
- 问题：使用
2**256 - 1作为默认授权额度（无限授权）。即便目标为官方合约，若合约或钱包泄露，风险极高。 - 建议：改为按需授权或设置较小上限，加入明确的复核步骤。
动态 import（低风险）
- 文件：scripts/redeem/redeem_manual.py、scripts/tools/parse_5m_log_fill.py
- 问题：使用
__import__("time")、__import__("io")等动态导入，降低审计可见性。当前用法看似为兼容性/IO 包装，但建议改为显式 import。
依赖管理
- 依赖项包括 httpx、py-clob-client、py-builder-relayer-client、web3、websockets、python-telegram-bot 等。
- 建议运行 pip-audit/safety，锁定版本并生成 lock 文件，定期扫描 CVE。
二、Polymarket-BTC-15-Minute-Trading-Bot（风险等级：⚠️ 中等）
- 安全亮点
- 私钥与 API 密钥均从环境变量读取（未在源码中硬编码私钥）
- 主动调用的外部端点均为官方 API（Polymarket CLOB、Gamma、Binance、Coinbase、Deribit、Solana RPC 等）
- 主要风险与证据
Grafana 管理凭据硬编码（高风险）
- 文件：grafana/import_dashboard.py（约 15-18 行）
- 问题：GRAFANA 用户/密码直接写在源码中（比如 admin/admin），若仓库泄露或未被忽略，会导致监控面板被劫持。
- 建议：从源码中移除，改为使用环境变量或密钥管理服务；并将该脚本限制为离线或受控运行。
运行时 Monkey-Patching（中高风险）
- 文件：patch_gamma_markets.py、patch_market_orders.py、bot.py（启动时加载并应用补丁，约 18-29 行和 72-75 行）
- 问题：启动时对 NautilusTrader 或内部模块进行方法替换（如 build_markets_query、load_all_async、_submit_market_order）。补丁本身实现了功能修正（如强制使用 Gamma API、强制 USD 买单），但运行时补丁若遭篡改会悄然改变交易逻辑或做后门。
- 建议：对补丁文件做完整性校验（SHA256/签名），或将补丁逻辑纳入受控的源代码分支/配置中而非动态替换；建立补丁审计和版本管理流程。
Redis 认证缺失（中风险）
- 文件：redis_control.py（约 16-24 行）
- 问题：Redis 客户端使用主机/端口/DB，但未在代码中看到密码或 TLS。若 Redis 暴露在公网或同网段不可信主机，可被用于切换 simulation/live 等控制命令。
- 建议：启用 Redis AUTH/ACL、使用 TLS，或将 Redis 限制在私有网络 + VPN 中。
依赖与测试脚本
- 存在 test.py、grafana 脚本与多种外部 API 调用（CryptoPanic、Fear&Greed、Solana RPC 等），建议在生产与测试环境中分离运行，避免测试脚本泄露。
三、两项目对比要点
| 风险维度 | Polymarket-Autobetting | BTC-15min-Bot |
|---|---|---|
| 后门 | 未发现 | 未发现 |
| 私钥泄露 | 未发现代码性漏洩，但私钥在内存中使用 | 同左 |
| 运行时代码修改 | 否（有 .env 写入） | 是（monkey-patch） |
| 凭据硬编码 | 否 | Grafana 管理凭据硬编码 |
| 无限授权 | 有（USDC unlimited approve） | 无明显 unlimited approve |
| Redis 安全 | N/A（未见） | 未启用 AUTH（需注意） |
| 外部端点 | 官方为主（Polymarket + RPC） | 官方为主（Polymarket + 多交易所/数据源） |
四、通用修复建议（优先级由高到低）
- 立即（高优先级）
- 禁止或受控运行时修改 .env。对必须的配置变更，使用受控的部署/配置管理流程（CI/CD、发布脚本、或安全的配置后端）。
- 移除或替换 Grafana 等工具中硬编码的管理凭据，改为环境变量或密钥管理服务。
- 对补丁文件（patch_gamma_markets.py、patch_market_orders.py）在启动时校验哈希或数字签名，记录加载日志并限制修改权限。
- Redis：启用 AUTH/ACL，限制网络访问。
- 近期（中优先级）
- 替换动态 import 为显式 import，提升代码可审计性。
- 将无限 ERC20 授权替换为最小必要授权或实现批准复核流程。
- 在 CI 中加入 pip-audit/safety 扫描并锁定依赖版本，生成 lock 文件。
- 可选/长期（低优先级）
- 将私钥与签名操作迁移到受管密钥库（KMS / HSM / Vault）或使用专用签名服务，避免将私钥加载到普通进程内存中。
- 建立补丁/插件的治理流程（代码签名、审核、变更日志和自动化回滚）。
五、下一步操作建议
- 我可以为你生成一个针对性补丁（可作为 PR 草案），包括：
- 将 Grafana 凭据移到 env，移除硬编码
- 在启动时新增补丁文件哈希校验逻辑
- 禁用 Telegram Bot 的 .env 写操作（或替换为受控接口）
- 在 redis_control.py 中添加示例的 AUTH/TLS 配置注释
- 我也可以在仓库中运行 pip-audit 并输出依赖漏洞报告（需要在你的环境中运行命令）。
保存位置：polymarket-hft-audit.md（当前文件）
如果你需要，我会把这些修复以 PR 补丁形式列出并逐项实现（在你允许我修改仓库文件时）。