QuantDinger 安全与漏洞响应指南密钥管理、Agent 隔离与生产加固基线【免费下载链接】QuantDingerOpen-source AI Trading OS, agent trading, and vibe trading, with Jev System One integration. Research, build Python strategies, backtest, and paper/live trade across crypto, stocks, and forex. Launch your own multi-tenant trading SaaS with built-in user management, billing, payments, and settlement.项目地址: https://gitcode.com/gh_mirrors/qu/QuantDingerQuantDinger 是一个本地优先、自托管的量化交易系统运行中会持有模型密钥、交易所/券商交易凭证与账户数据。本文以 docs/security/README.md 为骨架系统讲解运营者的安全职责、Agent Token 与人工 JWT 的隔离模型、泄密应急处置流程、私有漏洞上报规范并结合仓库源码与生产加固文档深入剖析底层实现帮助你在部署、运行与响应三个环节建立可落地的安全基线。威胁模型为什么安全边界必须“从整体看待”QuantDinger 并非一个无状态的前端应用而是一套完整的交易闭环后端 API 持有 JWT 会话密钥与凭证加密密钥数据库保存用户、策略与账户快照Redis 同时充当一次性缓存和 Celery 持久任务队列反向代理负责对外 TLS 终结。因此安全总览 明确要求运营者把应用、数据库、缓存、反向代理视为同一安全边界并限制对管理面admin 接口、Grafana、Agent Token 签发等的网络访问。这与 SECURITY.md 声明的支持范围是一致的源码漏洞、认证与授权逻辑、密钥与凭证处理、策略执行隔离边界、默认配置安全性均在安全评审范围内而操作系统/Docker/防火墙/云主机的错误配置、被攻破的用户机器、第三方交易所 API、以及非官方构建则明确不在范围内。也就是说框架保障边界内的逻辑安全边界外的环境安全是运营者的责任——文档中的“Operator responsibilities”清单正是对这一责任的落地。运营者责任清单Operator Responsibilities安全总览 给出的运营者责任可以归纳为四个层面1. 部署与升级只部署受信任的 release 或镜像升级前阅读 release notes生产环境的配置基线见 生产加固指南运行监控见 可观测性指南。2. 凭据管理使用长随机密码管理员与普通用户分离凭据一律通过环境变量或密钥系统注入严禁写入源码、日志、截图或 issue定期轮换模型密钥、OAuth 密钥、Agent Token 与交易凭证。3. 交易权限最小化交易 API 只授予完成任务所需的最小权限禁用提现优先使用专用子账户。4. 数据保护对数据库、对象存储与备份实施访问控制、加密与保留策略在反向代理层启用 HTTPS限制管理端点持续更新依赖与基础镜像。其中“禁用提现 专用子账户”与 实盘安全清单 中 Preflight 清单的第 1 条完全对应即使密钥泄露攻击者也无法把资金转出损失被限制在交易账户本身。Agent 与自动化Token 最小权限与幂等控制针对外部 AI Agent、MCP 服务器和自定义自动化仓库实现了独立的 Agent Gateway其认证模块位于 app/utils/agent_auth.py与人类 JWT 认证app/utils/auth.py有意分离。模块注释明确写着Agent Token 面向机器客户端受能力类作用域、逐 Token 限流和追加式审计日志约束人类 JWT 与 Agent Token 不可互换。Agent Token 的安全属性对应数据库结构Agent Token 的完整安全属性可以从 agent_auth.py 的建表语句看到属性默认值说明scopesR能力类作用域R读、W工作区写、B回测/模拟、N通知与副作用、C凭证仅管理员、T交易/资金markets/instruments*市场与标的白名单用于market_allowed()/instrument_allowed()过滤paper_onlyTRUE仅模拟盘实盘需要显式置为false且服务端打开总开关rate_limit_per_min60逐 Token 每分钟限流max_order_notional1000单笔名义金额上限max_daily_notional5000每日累计名义金额上限status/expires_atactive/ 无状态控制与到期时间这就是“最小作用域 过期时间 限流 名义金额上限”四个维度的落地文档要求的“minimum scopes, expirations, rate limits, and notional limits”全部有对应的强制字段。Token 签发时使用secrets.token_urlsafe(32)生成 32 字节随机体前缀为qd_agent_数据库仅保存 SHA-256 哈希完整 Token 只在签发时展示一次。每个副作用请求必须携带唯一 Idempotency-Key文档强调“Every side-effecting Agent request should use a uniqueIdempotency-Key.”这一要求并非建议而是强制。从 agent_auth.py 的实现看所有非GET/HEAD/OPTIONS且作用域在W/B/N/T的请求缺少Idempotency-Key头会直接返回400Key 上限 120 字符按(agent_token_id, method, route, idempotency_key)唯一索引去重表qd_agent_idempotency相同 Key 携带不同请求指纹返回409进行中的相同请求返回409 retriable已完成请求直接重放已持久化的响应并附带Idempotent-Replayed: true头。这意味着交易类 Agent 调用天然具备“重试安全”网络抖动导致的重发不会产生重复下单。配额预留在qd_agent_notional_reservations表中按(agent_token_id, idempotency_key)唯一约束保证单笔与每日名义金额上限在并发下也不会被绕过。服务端实盘总开关双重闸门除 Token 级别的paper_only外还存在服务端全局开关AGENT_LIVE_TRADING_ENABLED。在 routes/agent_v1/quick_trade.py 中该开关默认falseservices/agent_token_service.py 的注释总结了这条规则“实盘需要 Token 上paper_onlyfalse且服务端AGENT_LIVE_TRADING_ENABLEDtrue两者都必须被有意开启。”这正对应文档“保持全局实盘开关关闭直到运营者完成实盘安全清单后显式开启”的要求——任何单点配置失误都无法把资金暴露到真实市场。审计与脱敏每次 Agent 调用无论成功还是拒绝都会写入qd_agent_audit追加式审计表。写入前会经过_redact()深度脱敏agent_auth.py对password、secret、token、api_key、authorization、passphrase、private_key、webhook_secret等键名统一替换为redacted字符串超过 500 字符截断。审计日志既保留取证价值又不扩散敏感信息——与文档应急处置第 4 条“在不扩散秘密的前提下保全必要日志”直接呼应。密钥体系SECRET_KEY 与 CREDENTIAL_ENCRYPTION_KEYJWT 会话密钥SECRET_KEY人类 JWT 使用 HS256 签名密钥来自SECRET_KEY环境变量。在 app/config/settings.py 中应用启动时会强制校验为空或命中已知不安全默认值quantdinger-secret-key-change-me时直接抛RuntimeError字节数少于 10 时拒绝启动这是为兼容旧版本保留的下限新部署应使用 32 随机字节错误信息会直接提示生成方式python -c import secrets; print(secrets.token_hex(32))。在 app/utils/auth.py 的generate_token中JWT payload 至少包含exp、iat、sub、user_id、role、token_versionverify_token使用require选项强制这些声明存在并校验user_id/token_version类型与取值范围。最关键的是授权决策永不依赖 Token 内携带的 role 声明校验逻辑会重新加载数据库中的权威用户行比对用户状态active、数据库中的token_version防止单一客户端登录被旧 Token 绕过以及数据库中的角色任何不一致都直接拒绝。这正是 2026 年 7 月 JWT 认证/授权绕过漏洞修复后的行为详见下文安全公告。凭证加密密钥CREDENTIAL_ENCRYPTION_KEY交易所 API Key 等持久化凭证由 app/utils/credential_crypto.py 负责加解密。新安装使用独立的CREDENTIAL_ENCRYPTION_KEY这样轮换 JWT 会话密钥时不会牵连已加密的持久凭证CREDENTIAL_ENCRYPTION_KEY与SECRET_KEY二者必填其一才能加解密持久凭证。关键约束若更换CREDENTIAL_ENCRYPTION_KEY而没有先完成迁移已存储的凭证将无法解密读取对应 2026 年 8 月安全公告中的提醒。生产配置预检仓库提供预检脚本 backend_api_python/scripts/check_production_config.py用于在部署前拒绝已知不安全默认值默认数据库、管理员、Grafana、JWT、凭证加密密钥python backend_api_python/scripts/check_production_config.py \ --env-file .env \ --env-file backend_api_python/.env脚本会检查SECRET_KEY是否缺失或命中已知默认值、是否少于 10 字节推荐 32并汇总所有错误输出。生产加固锁定运行时与网络边界生产加固指南 给出了与安全总览配套的部署基线核心是“锁定运行时 收敛网络”锁定运行时生产覆盖层以非 root 用户UID/GID10001运行后端进程cap_drop: ALL丢弃全部 Linux 能力read_only: true使根文件系统只读并对内存/CPU 设限如 docker-compose.production.yml 中 backend 默认mem_limit: 2g、cpus: 2.0。启动命令为docker compose \ -f docker-compose.yml \ -f docker-compose.production.yml \ -f docker-compose.observability.yml \ up -d --build需要注意非 root 容器无法自行生成或持久化密钥因此首次锁定启动前必须准备好两份后端密钥.env与backend_api_python/.env迁移只能通过随附的 migration 服务执行禁止从 API worker 并发运行迁移。Redis 双层架构生产环境把 Redis 拆成两个独立实例实例用途淘汰策略备份要求redis一次性缓存allkeys-lru无需备份redis-jobsCelery broker/结果存储AOF 周期快照noeviction需备份celery_redis_data卷两者使用独立的密码REDIS_PASSWORD与CELERY_REDIS_PASSWORD、独立数据库与独立内存上限。noeviction的语义是内存耗尽时拒绝新写入而非静默丢弃队列任务从而保证在途交易指令不丢失运营者应监控任务 Redis 内存并在触及REDIS_JOBS_MAXMEMORY前扩容。网络收敛PostgreSQL 与 Redis 端口保持默认 loopback 绑定公网访问只允许经 TLS 反向代理终结于前端与后端。可观测性组件同样遵循这一原则可观测性指南 明确要求不要将/metrics、Prometheus127.0.0.1:9090、Alertmanager127.0.0.1:9093、Grafana127.0.0.1:3000直接暴露公网且对外暴露 Grafana 前必须修改GRAFANA_ADMIN_PASSWORD。发现暴露或可疑活动后的应急处置安全总览 给出的响应流程是 5 步闭环停止受影响的策略与新的交易——实盘侧对应 实盘安全指南 的 Incident Response停止新开仓与加仓、必要时使用 emergency stop且修复前不得重启吊销相关 Token、API Key 与会话——包括 Agent Token置为 inactive 或删除、交易所 API Key、用户会话升级token_version使旧 JWT 失效在交易所/券商侧核实订单、仓位与权限——以交易所实际记录为准不能只依赖缓存的 UI 状态同时确认不能误伤受保护的手动持仓在不扩散秘密或个人信息的前提下保全必要日志——利用qd_agent_audit审计表与X-Request-ID关联请求链路配合 可观测性指南 的 JSON 结构化日志与 Prometheus 指标定位时间窗口完成修复与凭据轮换后再恢复服务——顺序不可颠倒先轮换、再恢复。漏洞上报与安全公告上报方式若发现漏洞严禁在公开 issue 中披露可利用细节、凭据或账户数据。请遵循仓库根目录的 SECURITY.md 走私有上报流程报告需包含受影响版本、复现条件、影响范围、以及可行的缓解措施。项目承诺 72 小时内确认收到、7 天内给出初步评估。已披露的安全公告截至 2026 年 9 月2026 年 7 月 — JWT 认证与授权绕过已修复2026-07-21此前发布的默认SECRET_KEY可被未认证攻击者伪造 HS256 access token旧验证路径还允许无token_version声明的 Token 绕过会话版本检查并直接信任 Token 内携带的 role 做授权。修复后拒绝缺失、已知默认、少于 10 字节的签名密钥强制 JWT 身份与会话声明并以数据库权威记录校验用户状态、Token 版本与角色。受影响部署应升级、更换高熵SECRET_KEY并要求用户重新登录。2026 年 8 月 — 策略与指标执行隔离接受不受信任的策略/指标代码的部署应假设应用环境密钥可能已暴露。升级到最新main、审查访问日志并轮换 JWT/会话密钥、数据库凭据、Provider Token 与交易所/券商凭据在旧CREDENTIAL_ENCRYPTION_KEY加密的凭证完成重加密或重录前保留旧密钥。2026 年 9 月 — 客户端代理 IP 头信任问题修复了不当信任客户端提供的代理 IP 头的问题强化了基于 IP 的认证与反滥用控制。致谢上述公告分别由安全研究员 Risma AjulJWT 绕过、Satrio策略/指标执行边界属性遍历、Jo Arsy代理 IP 头信任负责任地披露研究均基于公开仓库未触及托管服务与真实用户数据。源码级证据索引主题文件人类 JWT 签发与校验强制声明、数据库权威角色app/utils/auth.pyAgent Gateway作用域、限流、审计、幂等、名义金额配额app/utils/agent_auth.pySECRET_KEY 启动强校验与不安全默认值拒绝app/config/settings.py凭证加密与密钥轮换约束app/utils/credential_crypto.py生产配置预检脚本scripts/check_production_config.py实盘总开关双重闸门routes/agent_v1/quick_trade.py生产锁定运行时非 root、只读、cap_dropdocker-compose.production.yml安全策略与历史公告SECURITY.md结语QuantDinger 的安全设计可以浓缩为一句话边界外的环境安全由运营者负责边界内的信任由机制强制。运营者需要落实的是责任清单凭据入环境变量、最小交易权限、定期轮换、HTTPS 与网络收敛代码层面强制的是 JWT 权威校验、Agent Token 最小作用域与幂等控制、实盘双闸门、审计脱敏以及可复现的应急处置与私有上报流程。将 安全总览、生产加固指南、可观测性指南、实盘安全清单 与 SECURITY.md 串起来执行就是一套从部署到响应、从人到机器的完整安全闭环。【免费下载链接】QuantDingerOpen-source AI Trading OS, agent trading, and vibe trading, with Jev System One integration. Research, build Python strategies, backtest, and paper/live trade across crypto, stocks, and forex. Launch your own multi-tenant trading SaaS with built-in user management, billing, payments, and settlement.项目地址: https://gitcode.com/gh_mirrors/qu/QuantDinger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
QuantDinger 安全与漏洞响应指南密钥管理、Agent 隔离与生产加固基线【免费下载链接】QuantDingerOpen-source AI Trading OS, agent trading, and vibe trading, with Jev System One integration. Research, build Python strategies, backtest, and paper/live trade across crypto, stocks, and forex. Launch your own multi-tenant trading SaaS with built-in user management, billing, payments, and settlement.项目地址: https://gitcode.com/gh_mirrors/qu/QuantDingerQuantDinger 是一个本地优先、自托管的量化交易系统运行中会持有模型密钥、交易所/券商交易凭证与账户数据。本文以 docs/security/README.md 为骨架系统讲解运营者的安全职责、Agent Token 与人工 JWT 的隔离模型、泄密应急处置流程、私有漏洞上报规范并结合仓库源码与生产加固文档深入剖析底层实现帮助你在部署、运行与响应三个环节建立可落地的安全基线。威胁模型为什么安全边界必须“从整体看待”QuantDinger 并非一个无状态的前端应用而是一套完整的交易闭环后端 API 持有 JWT 会话密钥与凭证加密密钥数据库保存用户、策略与账户快照Redis 同时充当一次性缓存和 Celery 持久任务队列反向代理负责对外 TLS 终结。因此安全总览 明确要求运营者把应用、数据库、缓存、反向代理视为同一安全边界并限制对管理面admin 接口、Grafana、Agent Token 签发等的网络访问。这与 SECURITY.md 声明的支持范围是一致的源码漏洞、认证与授权逻辑、密钥与凭证处理、策略执行隔离边界、默认配置安全性均在安全评审范围内而操作系统/Docker/防火墙/云主机的错误配置、被攻破的用户机器、第三方交易所 API、以及非官方构建则明确不在范围内。也就是说框架保障边界内的逻辑安全边界外的环境安全是运营者的责任——文档中的“Operator responsibilities”清单正是对这一责任的落地。运营者责任清单Operator Responsibilities安全总览 给出的运营者责任可以归纳为四个层面1. 部署与升级只部署受信任的 release 或镜像升级前阅读 release notes生产环境的配置基线见 生产加固指南运行监控见 可观测性指南。2. 凭据管理使用长随机密码管理员与普通用户分离凭据一律通过环境变量或密钥系统注入严禁写入源码、日志、截图或 issue定期轮换模型密钥、OAuth 密钥、Agent Token 与交易凭证。3. 交易权限最小化交易 API 只授予完成任务所需的最小权限禁用提现优先使用专用子账户。4. 数据保护对数据库、对象存储与备份实施访问控制、加密与保留策略在反向代理层启用 HTTPS限制管理端点持续更新依赖与基础镜像。其中“禁用提现 专用子账户”与 实盘安全清单 中 Preflight 清单的第 1 条完全对应即使密钥泄露攻击者也无法把资金转出损失被限制在交易账户本身。Agent 与自动化Token 最小权限与幂等控制针对外部 AI Agent、MCP 服务器和自定义自动化仓库实现了独立的 Agent Gateway其认证模块位于 app/utils/agent_auth.py与人类 JWT 认证app/utils/auth.py有意分离。模块注释明确写着Agent Token 面向机器客户端受能力类作用域、逐 Token 限流和追加式审计日志约束人类 JWT 与 Agent Token 不可互换。Agent Token 的安全属性对应数据库结构Agent Token 的完整安全属性可以从 agent_auth.py 的建表语句看到属性默认值说明scopesR能力类作用域R读、W工作区写、B回测/模拟、N通知与副作用、C凭证仅管理员、T交易/资金markets/instruments*市场与标的白名单用于market_allowed()/instrument_allowed()过滤paper_onlyTRUE仅模拟盘实盘需要显式置为false且服务端打开总开关rate_limit_per_min60逐 Token 每分钟限流max_order_notional1000单笔名义金额上限max_daily_notional5000每日累计名义金额上限status/expires_atactive/ 无状态控制与到期时间这就是“最小作用域 过期时间 限流 名义金额上限”四个维度的落地文档要求的“minimum scopes, expirations, rate limits, and notional limits”全部有对应的强制字段。Token 签发时使用secrets.token_urlsafe(32)生成 32 字节随机体前缀为qd_agent_数据库仅保存 SHA-256 哈希完整 Token 只在签发时展示一次。每个副作用请求必须携带唯一 Idempotency-Key文档强调“Every side-effecting Agent request should use a uniqueIdempotency-Key.”这一要求并非建议而是强制。从 agent_auth.py 的实现看所有非GET/HEAD/OPTIONS且作用域在W/B/N/T的请求缺少Idempotency-Key头会直接返回400Key 上限 120 字符按(agent_token_id, method, route, idempotency_key)唯一索引去重表qd_agent_idempotency相同 Key 携带不同请求指纹返回409进行中的相同请求返回409 retriable已完成请求直接重放已持久化的响应并附带Idempotent-Replayed: true头。这意味着交易类 Agent 调用天然具备“重试安全”网络抖动导致的重发不会产生重复下单。配额预留在qd_agent_notional_reservations表中按(agent_token_id, idempotency_key)唯一约束保证单笔与每日名义金额上限在并发下也不会被绕过。服务端实盘总开关双重闸门除 Token 级别的paper_only外还存在服务端全局开关AGENT_LIVE_TRADING_ENABLED。在 routes/agent_v1/quick_trade.py 中该开关默认falseservices/agent_token_service.py 的注释总结了这条规则“实盘需要 Token 上paper_onlyfalse且服务端AGENT_LIVE_TRADING_ENABLEDtrue两者都必须被有意开启。”这正对应文档“保持全局实盘开关关闭直到运营者完成实盘安全清单后显式开启”的要求——任何单点配置失误都无法把资金暴露到真实市场。审计与脱敏每次 Agent 调用无论成功还是拒绝都会写入qd_agent_audit追加式审计表。写入前会经过_redact()深度脱敏agent_auth.py对password、secret、token、api_key、authorization、passphrase、private_key、webhook_secret等键名统一替换为redacted字符串超过 500 字符截断。审计日志既保留取证价值又不扩散敏感信息——与文档应急处置第 4 条“在不扩散秘密的前提下保全必要日志”直接呼应。密钥体系SECRET_KEY 与 CREDENTIAL_ENCRYPTION_KEYJWT 会话密钥SECRET_KEY人类 JWT 使用 HS256 签名密钥来自SECRET_KEY环境变量。在 app/config/settings.py 中应用启动时会强制校验为空或命中已知不安全默认值quantdinger-secret-key-change-me时直接抛RuntimeError字节数少于 10 时拒绝启动这是为兼容旧版本保留的下限新部署应使用 32 随机字节错误信息会直接提示生成方式python -c import secrets; print(secrets.token_hex(32))。在 app/utils/auth.py 的generate_token中JWT payload 至少包含exp、iat、sub、user_id、role、token_versionverify_token使用require选项强制这些声明存在并校验user_id/token_version类型与取值范围。最关键的是授权决策永不依赖 Token 内携带的 role 声明校验逻辑会重新加载数据库中的权威用户行比对用户状态active、数据库中的token_version防止单一客户端登录被旧 Token 绕过以及数据库中的角色任何不一致都直接拒绝。这正是 2026 年 7 月 JWT 认证/授权绕过漏洞修复后的行为详见下文安全公告。凭证加密密钥CREDENTIAL_ENCRYPTION_KEY交易所 API Key 等持久化凭证由 app/utils/credential_crypto.py 负责加解密。新安装使用独立的CREDENTIAL_ENCRYPTION_KEY这样轮换 JWT 会话密钥时不会牵连已加密的持久凭证CREDENTIAL_ENCRYPTION_KEY与SECRET_KEY二者必填其一才能加解密持久凭证。关键约束若更换CREDENTIAL_ENCRYPTION_KEY而没有先完成迁移已存储的凭证将无法解密读取对应 2026 年 8 月安全公告中的提醒。生产配置预检仓库提供预检脚本 backend_api_python/scripts/check_production_config.py用于在部署前拒绝已知不安全默认值默认数据库、管理员、Grafana、JWT、凭证加密密钥python backend_api_python/scripts/check_production_config.py \ --env-file .env \ --env-file backend_api_python/.env脚本会检查SECRET_KEY是否缺失或命中已知默认值、是否少于 10 字节推荐 32并汇总所有错误输出。生产加固锁定运行时与网络边界生产加固指南 给出了与安全总览配套的部署基线核心是“锁定运行时 收敛网络”锁定运行时生产覆盖层以非 root 用户UID/GID10001运行后端进程cap_drop: ALL丢弃全部 Linux 能力read_only: true使根文件系统只读并对内存/CPU 设限如 docker-compose.production.yml 中 backend 默认mem_limit: 2g、cpus: 2.0。启动命令为docker compose \ -f docker-compose.yml \ -f docker-compose.production.yml \ -f docker-compose.observability.yml \ up -d --build需要注意非 root 容器无法自行生成或持久化密钥因此首次锁定启动前必须准备好两份后端密钥.env与backend_api_python/.env迁移只能通过随附的 migration 服务执行禁止从 API worker 并发运行迁移。Redis 双层架构生产环境把 Redis 拆成两个独立实例实例用途淘汰策略备份要求redis一次性缓存allkeys-lru无需备份redis-jobsCelery broker/结果存储AOF 周期快照noeviction需备份celery_redis_data卷两者使用独立的密码REDIS_PASSWORD与CELERY_REDIS_PASSWORD、独立数据库与独立内存上限。noeviction的语义是内存耗尽时拒绝新写入而非静默丢弃队列任务从而保证在途交易指令不丢失运营者应监控任务 Redis 内存并在触及REDIS_JOBS_MAXMEMORY前扩容。网络收敛PostgreSQL 与 Redis 端口保持默认 loopback 绑定公网访问只允许经 TLS 反向代理终结于前端与后端。可观测性组件同样遵循这一原则可观测性指南 明确要求不要将/metrics、Prometheus127.0.0.1:9090、Alertmanager127.0.0.1:9093、Grafana127.0.0.1:3000直接暴露公网且对外暴露 Grafana 前必须修改GRAFANA_ADMIN_PASSWORD。发现暴露或可疑活动后的应急处置安全总览 给出的响应流程是 5 步闭环停止受影响的策略与新的交易——实盘侧对应 实盘安全指南 的 Incident Response停止新开仓与加仓、必要时使用 emergency stop且修复前不得重启吊销相关 Token、API Key 与会话——包括 Agent Token置为 inactive 或删除、交易所 API Key、用户会话升级token_version使旧 JWT 失效在交易所/券商侧核实订单、仓位与权限——以交易所实际记录为准不能只依赖缓存的 UI 状态同时确认不能误伤受保护的手动持仓在不扩散秘密或个人信息的前提下保全必要日志——利用qd_agent_audit审计表与X-Request-ID关联请求链路配合 可观测性指南 的 JSON 结构化日志与 Prometheus 指标定位时间窗口完成修复与凭据轮换后再恢复服务——顺序不可颠倒先轮换、再恢复。漏洞上报与安全公告上报方式若发现漏洞严禁在公开 issue 中披露可利用细节、凭据或账户数据。请遵循仓库根目录的 SECURITY.md 走私有上报流程报告需包含受影响版本、复现条件、影响范围、以及可行的缓解措施。项目承诺 72 小时内确认收到、7 天内给出初步评估。已披露的安全公告截至 2026 年 9 月2026 年 7 月 — JWT 认证与授权绕过已修复2026-07-21此前发布的默认SECRET_KEY可被未认证攻击者伪造 HS256 access token旧验证路径还允许无token_version声明的 Token 绕过会话版本检查并直接信任 Token 内携带的 role 做授权。修复后拒绝缺失、已知默认、少于 10 字节的签名密钥强制 JWT 身份与会话声明并以数据库权威记录校验用户状态、Token 版本与角色。受影响部署应升级、更换高熵SECRET_KEY并要求用户重新登录。2026 年 8 月 — 策略与指标执行隔离接受不受信任的策略/指标代码的部署应假设应用环境密钥可能已暴露。升级到最新main、审查访问日志并轮换 JWT/会话密钥、数据库凭据、Provider Token 与交易所/券商凭据在旧CREDENTIAL_ENCRYPTION_KEY加密的凭证完成重加密或重录前保留旧密钥。2026 年 9 月 — 客户端代理 IP 头信任问题修复了不当信任客户端提供的代理 IP 头的问题强化了基于 IP 的认证与反滥用控制。致谢上述公告分别由安全研究员 Risma AjulJWT 绕过、Satrio策略/指标执行边界属性遍历、Jo Arsy代理 IP 头信任负责任地披露研究均基于公开仓库未触及托管服务与真实用户数据。源码级证据索引主题文件人类 JWT 签发与校验强制声明、数据库权威角色app/utils/auth.pyAgent Gateway作用域、限流、审计、幂等、名义金额配额app/utils/agent_auth.pySECRET_KEY 启动强校验与不安全默认值拒绝app/config/settings.py凭证加密与密钥轮换约束app/utils/credential_crypto.py生产配置预检脚本scripts/check_production_config.py实盘总开关双重闸门routes/agent_v1/quick_trade.py生产锁定运行时非 root、只读、cap_dropdocker-compose.production.yml安全策略与历史公告SECURITY.md结语QuantDinger 的安全设计可以浓缩为一句话边界外的环境安全由运营者负责边界内的信任由机制强制。运营者需要落实的是责任清单凭据入环境变量、最小交易权限、定期轮换、HTTPS 与网络收敛代码层面强制的是 JWT 权威校验、Agent Token 最小作用域与幂等控制、实盘双闸门、审计脱敏以及可复现的应急处置与私有上报流程。将 安全总览、生产加固指南、可观测性指南、实盘安全清单 与 SECURITY.md 串起来执行就是一套从部署到响应、从人到机器的完整安全闭环。【免费下载链接】QuantDingerOpen-source AI Trading OS, agent trading, and vibe trading, with Jev System One integration. Research, build Python strategies, backtest, and paper/live trade across crypto, stocks, and forex. Launch your own multi-tenant trading SaaS with built-in user management, billing, payments, and settlement.项目地址: https://gitcode.com/gh_mirrors/qu/QuantDinger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
