Pull Request已成功合入, 合并人@openeuler-ci-bot
(感谢 xujing99 的贡献)Welcome To openEuler Community
Hey @xujing99 , thanks for your contribution to the community.
Bot Usage Manual
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here . That means you can comment below every pull request or issue to trigger Bot Commands. You can self-configure the PR merge rules for this repository. For more details, please refer to Here.
Contact Guide
If you have any questions, please contact the SIG: sig-intelligence ,
and any of the maintainers: @fromhsc, @gogoxiaoxiao, @huzhengce, @kaitiandu, @leon-wang2021, @liumiao27, @lyhu, @wqianli, @zxstty ,
and any of the committers: @extinctfire, @hypothesiser, @xiangyou_xie, @xujing99 .


门禁正在运行, 您可以通过以下链接查看实时门禁检查结果.
若您对门禁结果含义不清晰或者遇到问题不知如何解决,可参考门禁指导手册
门禁入口及编码规范检查: multiarch/openeuler/trigger/xiaoO/1024


门禁正在运行, 您可以通过以下链接查看实时门禁检查结果.
若您对门禁结果含义不清晰或者遇到问题不知如何解决,可参考门禁指导手册
门禁入口及编码规范检查: multiarch/openeuler/trigger/xiaoO/1026


/lgtm


/approve


当前PR是否有AI参与:
[x] 否
[ ] 是
__1. AI Agent 平台:
__2. AI 模型:
__3. Prompt上下文 :
参考:openEuler社区《生成式AI工具使用与开源贡献政策》
PR功能描述 / 为什么需要这个合入**:
1.1 修改目的
修复守护进程 HTTP API 对浏览器暴露过宽的安全缺陷:旧实现对任意网页都放行跨域访问且允许携带凭证,也拦不住 DNS 重绑定攻击(攻击者让自己的域名解析到 127.0.0.1,让浏览器误以为请求是同源的)。本次将浏览器可达性收紧到本机来源,并在本机监听时校验 Host 头,堵住远程网页读取/调用本机 API 的通道(修复 #137)。
1.2 关键变更点
CorsLayer::very_permissive(),只有本机来源(及显式配置的来源)能拿到跨域响应头。[http].allowed_origins配置项:远程 Web UI 前置部署时可显式放行其来源,默认仅本机。1.3 实现思路与机制原理
背景:守护进程的 HTTP API 会被浏览器直接调用——本地 Web UI 跑在另一个本机端口上。浏览器有个规则叫 CORS(跨域资源共享):网页要读别的来源的接口响应,必须由接口在响应里带上“允许该来源”的头。改动前用的是“超宽松”CORS(任意来源原样反射放行 + 允许凭证);而且 CORS 只管跨域请求,DNS 重绑定伪造出“同源”请求时它完全不生效,此时 Host 头是唯一能识别攻击的信号。
本次建立两道互补防线,配置收敛到新结构
HttpSecurityPolicy(监听地址 + 额外放行来源),随路由构造一路传递:router.rs的cors_layer/origin_is_allowed):每个请求的Origin先查配置的来源列表,再判断是否为 http/https 且主机是回环地址(localhost、127.0.0.0/8、::1,交给标准IpAddr解析以识别0:0:0:0:0:0:0:1等等价写法)。不命中则完全不返回 CORS 头,浏览器便拒绝把响应暴露给该网页。方法仅放行 GET/POST,请求头仅放行 Authorization/Content-Type。router.rs的enforce_loopback_host):仅当监听地址是回环地址且端口具体(非 0)时启用;请求 Host 按 RFC 3986 解析为Authority,主机必须是回环名,带端口时必须等于监听端口,否则 403。这里没有手写split(':'),并专门绕开了Authority::port()无法区分“无端口”与“端口畸形”(如127.0.0.1:80x)的坑(authority_port_segment)。main.rs):主 API 路由在构造时套上两层;MCP 路由是事后 merge 进来的、dashboard 是独立监听,axum 的 layer 不会自动覆盖它们,因此导出apply_loopback_host_guard对这两处单独包裹同一中间件。设计取舍:Host 校验只在本机监听启用——非本机监听本来就必须配 bearer token 才能启动(既有检查
ensure_external_bind_is_authenticated),且常被反向代理前置,Host 不归守护进程管;本机来源免配置放行,因为远程网页伪造不出回环来源,能在本机起网页的进程本就能直连 API,那属于鉴权层的职责。效果示例:
Origin: https://evil.com→ 响应无任何 CORS 头,浏览器不暴露内容Origin: http://localhost:3080(本地 UI)→ 正常反射放行Host: evil.example.com:8080(连接实际落在 127.0.0.1:8080)→ 4031.4 影响范围/兼容性影响
[http].allowed_origins(字符串数组,默认空 = 仅回环来源)。此前依赖“任意来源可跨域访问”的远程网页部署需显式配置,且应配合 bearer token(文档已提示)。HttpSecurityPolicy参数,仓内调用方与测试已同步。该PR关联的issue
fixes #137