AutoGPT Platform 安全报告流程、版本支持范围与 JWKS 传输校验机制详解

AutoGPT Platform 安全报告流程、版本支持范围与 JWKS 传输校验机制详解【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT本文以仓库根目录的 SECURITY.md 为主体系统讲解 AutoGPT 项目的安全漏洞报告流程与披露策略、安全更新覆盖的版本范围并深入剖析文档中特别澄清的 JWKS 传输检查 机制——结合 auth 配置源码 与其测试用例说明该检查在启动时如何校验JWT_JWKS_URL、它为什么被定位为操作员指引而非安全边界以及自托管时应当如何正确配置令牌验证链路。一、安全漏洞报告只走私有渠道SECURITY.md 开宗明义地提出两条基本原则通过私有渠道报告如果你认为发现了安全漏洞必须私下列报。严禁通过公开的 GitHub issues、讨论区或 pull request 报告安全漏洞——公开渠道会削弱漏洞在修复窗口期内被利用前的可控性。classic/目录不在安全支持范围内文档明确声明classic/文件夹内的代码被视为遗留legacy代码不受支持、不纳入安全报告范围官方不会处理其中的安全漏洞。仓库中classic/目录下另有独立的 classic/SECURITY.md阅读该目录时需注意与根级安全策略的区别。报告渠道为项目维护的 GitHub Security Advisory 入口即仓库的 Security Advisories 提交页文档中还保留了第三方漏洞赏金平台披露页的引用在源文件中已注释停用。报告流程四步走文档定义了从提交到修复的完整协作流程步骤内容时限/说明1. 提交报告Submit Report通过上述私有渠道提交—2. 响应确认Response Time团队确认收到报告14 个工作日内确认收到3. 协作验证Collaboration与报告人协作理解并验证问题—4. 修复发布Resolution修复漏洞并协调发布流程—披露政策Disclosure Policy报告人需要满足以下披露约束这也是负责任披露Responsible Disclosure的典型约定提供详细报告与可复现步骤附上发现漏洞的版本或 commit hash任何公开披露前预留 90 天安全修复窗口补丁发布后再预留30 天给用户更新即更新时间与修复时间之间总计最长 120 天如已知潜在的缓解措施或规避方案mitigations/workarounds应一并提供。文档落款标注Last updated: November 2024阅读时请以仓库当前版本的实际策略为准。二、受支持版本矩阵与安全最佳实践哪些版本能获得安全更新SECURITY.md 用矩阵明确了安全更新的资格范围版本是否受支持master 分支的最新 release✅master 之前的开发提交pre-master✅Classic 目录已弃用❌其他所有版本❌这一矩阵与文档开头的classic/排除声明互相呼应AutoGPT 仓库同时维护着新一代AutoGPT Platformautogpt_platform/下的前后端与库代码与历史遗留的classic/代码而安全投入只集中在前者。使用者安全最佳实践文档给出了五条面向部署者/使用者的准则始终使用最新的稳定版本更新前先查阅安全公告advisories遵循官方安全文档与指引保持依赖项更新不要使用classic/目录中的代码它已弃用且不受支持。三、JWKS 传输检查从安全声明到源码实现SECURITY.md 中有一段对安全报告资格划界的Important Note值得重点展开JWKS 传输检查当JWT_JWKS_URL通过明文http://从非本地主机拉取时的启动告警是尽力而为的操作员指引不是安全边界。它只是警告不会阻断启动也无法区分受信任的内网与敌对网络。保障后端与 JWKS 端点之间网络路径的安全性是操作员的职责。因此报告该警告可以被忽略、静默或绕过不符合 CVE 资格。要理解这段话需要先理解 AutoGPT Platform 的登录令牌验证架构前端Next.js内置 Better Auth 服务负责签发用户 JWT。从 auth.ts 可以看到Better Auth 的jwt插件配置了jwksJWKS 密钥对持久化到UserAuthJwks模型密钥算法由 service-token.ts 中的JWKS_ALG统一指定平台前端使用ES256非对称签名。后端FastAPI做无状态验签不直接查会话库而是从前端暴露的.../api/auth/jwks端点拉取公钥集合对请求头中的 Bearer JWT 验签。关键实现见 jwt_utils.pyalg以HS开头的对称令牌用共享密钥JWT_VERIFY_KEY验签这是为 Supabase GoTrue 时代遗留令牌保留的迁移兼容路径;其余非对称令牌走PyJWKClient从JWT_JWKS_URL取公钥验签算法白名单默认ES256,RS256,EdDSAJWKS 客户端带 1 小时缓存JWKS_CACHE_LIFESPAN_SECONDS 3600单次拉取超时仅 5 秒JWKS_FETCH_TIMEOUT_SECONDS 5避免前端短暂重部署时拖死后端 worker。威胁模型为什么明文 JWKS 拉取危险后端信任JWT_JWKS_URL返回的任何密钥。如果该拉取走明文http://且跨过了不受信任的网络段例如前后端分置于局域网两台机器、或对外暴露路径上的攻击者可以实施中间人替换——把伪造的公钥集合注入响应从而为任意用户伪造合法令牌。因此该检查的本质是提醒JWKS 拉取必须运行在受信任路径上。源码级校验逻辑启动时到底做了什么检查的实现位于 config.py 的Settings.validate()。完整规则如下JWT_JWKS_URL必填未设置时直接抛AuthConfigError因为 Better Auth 签发的是非对称ES256令牌没有 JWKS 端点后端无法验证任何有效会话JWT_VERIFY_KEY不能替代它只覆盖迁移窗口的遗留 HS256 令牌。URL 必须以http://或https://开头否则在配置期报错而不是等到第一个请求才抛出晦涩的PyJWKClientErrorurlparse无法解析的主机如括号不配的 IPv6同样在启动期失败。明文http:// 非本地主机是核心检查点本地主机 的判定config.pylocalhost、127.0.0.1、::1以及单标签主机名不含.与:例如 Docker 服务名frontend——后者被视为与回环地址同等可信的容器内部流量若主机非本地且JWKS_ALLOW_INSECURE_TRANSPORT未启用Settings()抛AuthConfigError错误信息直接点明攻击面路径上的攻击者可替换密钥并伪造任意用户的令牌若显式设置JWKS_ALLOW_INSECURE_TRANSPORT为1/true/yes则允许启动但会输出一条留在日志记录中的启动警告⚠️ JWKS_ALLOW_INSECURE_TRANSPORT is enabled...。附带检查JWT_VERIFY_KEY少于 32 字符会记录弱密钥警告JWT_JWKS_ALGORITHMS中出现对称HS*、none或非法算法会直接拒绝启动JWKS 验签只允许非对称算法白名单中若缺ES256则告警因为平台前端恰好以 ES256 签名缺省会静默拒绝该前端签发的全部令牌。需要指出的是SECURITY.md 将这一整套机制定位为操作员指引而非安全边界——即便源码默认会拒绝启动攻击者仍可通过JWKS_ALLOW_INSECURE_TRANSPORT这一官方开关让服务以警告状态运行且任何基于主机名的本地性判断都无法在运行时验证网络路径的真实安全性。真正的安全保证来自运维侧对网络路径的管控这正是文档声明警告可被绕过不构成 CVE的由来。仓库中的实际配置示例标准 Docker 部署下的默认值恰好落在本地可信一侧docker-compose.platform.yml 将后端环境变量设为# JWKS endpoint of the Better Auth service embedded in the frontend. # Containers reach it via the compose service name, not localhost. JWT_JWKS_URL: http://frontend:3000/api/auth/jwksfrontend是 compose 服务名单标签主机因此明文http://不会触发拒绝。本地开发用的 .env.defaultJWT_JWKS_URLhttp://localhost:3000/api/auth/jwks # 非本地主机走明文 http 时后端会拒绝启动 # 若网络路径可信置为 true 可强制启动日志会留警告。 # JWKS_ALLOW_INSECURE_TRANSPORTfalse # 遗留共享密钥验签HS256仅在旧 Supabase 令牌流通期间需要 JWT_VERIFY_KEYyour-super-secret-jwt-token-with-at-least-32-characters-long自托管指南 docs/platform/getting-started.md 的 Auth transport security (JWKS over untrusted networks) 小节给出了对应的运维建议单机 Docker 网络内用http即可一旦前后端跨机器部署或对外暴露必须把前端置于 TLS 反向代理之后或使用本地受信证书再把JWT_JWKS_URL指向https://地址。文档同时强调这是无状态 JWT/JWKS 验签的通用属性并非 AutoGPT 特有。相关环境变量速查变量是否必填默认值作用JWT_JWKS_URL是无缺失则启动失败Better Auth 服务的 JWKS 端点非对称令牌验签的密钥来源JWKS_ALLOW_INSECURE_TRANSPORT否未设置允许明文http://指向非本地主机时以警告态启动JWT_VERIFY_KEY否空回退读取SUPABASE_JWT_SECRET遗留 HS256 共享密钥少于 32 字符触发弱密钥警告JWT_JWKS_ALGORITHMS否ES256,RS256,EdDSAJWKS 验签算法白名单拒绝对称/非法算法JWT_SIGN_ALGORITHM否HS256对称路径使用的签名算法设为HS*且配置了共享密钥时会输出安全建议警告测试用例如何锁定这些行为config_test.py 对上述规则做了边界完备的覆盖可作为行为核对清单test_jwks_url_cleartext_remote_host_is_rejected明文 URL 指向可路由主机http://auth.example.com/...时Settings()必须抛出含JWKS_ALLOW_INSECURE_TRANSPORT提示的AuthConfigErrortest_jwks_url_trusted_transport_does_not_warn回环地址、127.0.0.1、[::1]、Docker 服务名http://frontend:3000/...与https://URL 均静默通过test_jwks_url_cleartext_allowed_with_override_but_warns覆盖值1/true/TRUE/yes均可放行且日志中出现cleartext警告test_jwks_algorithms_rejects_unsafe_entriesHS256、none、INVALID均被拒绝进入 JWKS 白名单test_warns_when_es256_missing_from_jwks_algorithms白名单缺 ES256 时输出每个平台令牌都会被拒绝的告警。四、历史安全公告与延伸阅读对于已披露的历史漏洞SECURITY.md 指引读者查阅项目的 Security Advisory 页面与第三方披露页正文输出此处不附外部链接可在仓库的 GitHub 安全公告区检索。结合本文的源码证据建议自托管用户在部署时按以下顺序核对确认运行的是 master 最新 release受支持矩阵检查后端启动日志中是否出现⚠️开头的 JWT/JWKS 告警弱密钥、明文传输、算法白名单异常若前后端跨网络段部署按 docs/platform/getting-started.md 的安全小节为 JWKS 拉取路径加 TLS不再使用的遗留令牌若已退出流通可按 .env.default 中的注释移除JWT_VERIFY_KEY共享密钥路径缩小攻击面。关键文件索引安全策略 SECURITY.md、校验实现 config.py、验签实现 jwt_utils.py、测试 config_test.py、默认配置 .env.default 与 docker-compose.platform.yml、自托管安全说明 docs/platform/getting-started.md。【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考