冠捎擅姨在2025年10月的微软补丁星期二更新中一个针对 ASP.NET Core 的漏洞 CVE-2025-55315 引起了安全社区的高度关注。该漏洞被美国国家漏洞数据库 (NVD) 评定为 CVSS 3.1 基础分 9.9 (高危)这是一个极其罕见的高分预示着其巨大的潜在风险 。CVSS 9.9 分的严重性是什么概念为了准确理解 9.9 分的严重级别我们可以将其与历史上一些著名的漏洞进行对比Log4Shell (CVE-2021-44228): 这个席卷全球的 Java 日志库漏洞因其影响范围广、利用难度低获得了完美的 10.0 分 。Shellshock (CVE-2014-6271): 这个存在于 Bash shell 中的严重漏洞允许远程命令执行其 CVSS v3.1 评分为 9.8 分 。Heartbleed (CVE-2014-0160): 这个曾导致大规模数据泄露的 OpenSSL 漏洞虽然影响巨大但其 CVSS v3.1 评分仅为 7.5 分 。通过对比可见CVE-2025-55315 的 9.9 分已将其置于与 Log4Shell 和 Shellshock 同等级别的严重威胁行列需要所有.NET 开发者和运维团队给予最高优先级的关注。微软安全项目经理 Barry Dorrans 甚至直言这个漏洞的 CVSS 评分是“我们有史以来最高的” 并不是危言耸听。image简单说这是一个 HTTP 请求走私 (HTTP Request Smuggling, CWE-444) 漏洞 。它发生在 ASP.NET Core 的心脏——Kestrel Web 服务器中。攻击者可以发送一个“畸形”的 HTTP 请求让你的前端代理比如 Nginx、负载均衡器和后端的 Kestrel 服务器对这个请求的“边界”产生误解从而把恶意请求“走私”进去绕过你的所有安全检查 。受影响范围以下.NET版本均受此漏洞影响 .NET 10: ASP.NET Core 10.0.0-rc.1.25451.107 及更早版本。.NET 9: ASP.NET Core 9.0.9 及更早版本。.NET 8: ASP.NET Core 8.0.20 及更早版本。.NET Core 2.x: 引用了 Microsoft.AspNetCore.Server.Kestrel.Core NuGet 包 2.3.0 及更早版本。可以看到这个漏洞影响范围极广从古老的.NET Core 2.3 到最新的.NET 8、.NET 9 乃至.NET 10 预览版几乎是“全家桶”式的沦陷 。.NET 3/4/5/6/7 未提及不是因为没问题只是因为官方已经不再维护了有bug也不会修复不想升sdk可以换成https://docs.herodevs.com/net 的镜像。修复措施微软官方明确指出不存在任何缓解措施或临时解决方案 。唯一的修复途径是升级对于.NET 8, 9, 10 项目: 升级至最新的.NET SDK 版本。对于.NET Core 2.x 项目: 将 Microsoft.AspNetCore.Server.Kestrel.Core NuGet 包的引用更新至 2.3.6 或更高版本 。什么是HTTP 请求走私HTTP 请求走私是一种利用 Web 架构中前后端服务器对 HTTP 请求边界解析不一致的攻击技术。在一个典型的 Web 架构中前端代理如反向代理、CDN会通过一个持久的 TCP/TLS 连接将来自多个用户的请求“管道化”地转发给后端 Kestrel 服务器 。为了正确地分割这些请求前后端必须对每个请求的结束位置达成共识。HTTP/1.1 规范提供了两种定义请求体长度的方式Content-Length 和 Transfer-Encoding: chunked。规范规定当两者同时存在时Transfer-Encoding 头的优先级更高 。然而并非所有服务器实现都严格遵守此规则或在处理被混淆、格式不规范的头时行为不一这就为攻击创造了条件 。攻击者可以构造一个让前端和后端产生不同解析结果的请求导致一部分数据被后端服务器视为下一个独立请求的开始。这个被“走私”的请求由于未经过前端代理的审查可以绕过访问控制、WAF 规则等安全措施 。这对我们开发者来说是个巨大的盲区。因为无论你在中间件里写了多么完美的授权 [Authorize] 和验证逻辑被走私的请求都能完美绕过因为它在 Kestrel 眼里就是一个全新的、合法的请求。如何复现社区里已经有大神放出了复现这个漏洞的 PoC (Proof of Concept) 代码比如这个 GitHub 仓库sirredbeard/CVE-2025-55315-repro。该程序通过原始 TCP 套接字向一个本地 Kestrel 服务器发送构造的畸形 HTTP 请求以验证其解析行为。这个程序做的事情很简单在本地 5000 端口启动一个最基础的 Kestrel 服务器。用原始的 TCP 套接字Socket连接这个服务器发送两个精心构造的、畸形的 HTTP 请求。检查服务器的响应。在打过补丁的环境下服务器应该拒绝这些畸形请求返回 400 Bad Request。如果服务器返回了 200 OK说明它错误地处理了请求漏洞就存在。让我们聚焦于两个测试函数它们是揭示漏洞本质的关键。测试一MultiReadWithInvalidNewlineAcrossReads第一个测试的骚操作就是模拟了一个极其刁钻的网络情况它把一个本该完整的\r\n (回车换行) 拆分到两个 TCP 包里发送。// 关键请求片段var fragments1 new List{//... headers...1;\r // 第一个包发送了块大小和回车符(CR)};//... 发送 fragments1...await Task.Delay(50); // 模拟网络延迟var fragments2 new List{\n // 第二个包发送换行符(LF)};//... 发送 fragments2...根据 HTTP/1.1 的分块传输编码Chunked Transfer Encoding规范每个数据块的大小定义后面必须紧跟一个完整的 CRLF (\r\n)。这个测试故意将 CRLF 拆开模拟了网络分包的极端情况。修复后的 Kestrel会严格遵守规范。当它读到 1;\r 后发现流暂时结束了但没有等到预期的 \n。在下一个包 \n 到达后它能正确地将两者拼接但依然会识别出这是一个跨数据包的、不规范的分块头因此拒绝请求返回 400 Bad Request。有漏洞的 Kestrel对这种边界情况的处理过于“宽容”。它可能会错误地解析这个被拆分的 CRLF或者在处理缓冲区时出现逻辑错误最终接受了这个畸形的请求返回 200 OK。测试二InvalidNewlineInFirstReadWithPartialChunkExtension这个测试则更直接它发送了一个只用 \n 作为换行符的分块头这同样不符合 RFC 规范。// 展示请求的关键部分var fragments new List{GET / HTTP/1.1\r\n,Host: localhost\r\n,Transfer-Encoding: chunked\r\n,\r\n,1;\n // 注意这里直接使用了 LF (\n) 而不是 CRLF (\r\n)};HTTP 协议明确规定行结束符是 CRLF。只用 LF 是不规范的。修复后的 Kestrel会识别出这是一个无效的行结束符直接拒绝请求返回 400 Bad Request。有漏洞的 Kestrel再次表现出它的“宽容”接受了这个不规范的请求。通过对 PoC 代码的分析可以得出结论CVE-2025-55315 的根源在于 Kestrel 的 HTTP/1.1 解析器在处理分块传输编码 (Chunked Transfer Encoding) 时对行结束符的处理过于宽松接受了不符合 RFC 规范的畸形输入。正是这种对协议规范的“宽容”导致了 Kestrel 与严格遵守规范的前端代理之间产生了致命的解析差异从而为 HTTP 请求走私攻击打开了通道。我在github上找到了官方的修复PRFix chunked request parsing从这里能大致看出之前是只判断 \n, 修复的PR更严格了image潜在影响与攻击场景一个成功的请求走私攻击其影响远不止于简单的请求伪造。以下是一些针对典型 ASP.NET Core 应用的真实攻击场景场景一绕过访问控制访问内部接口 攻击者以普通用户身份认证然后走私一个指向高权限接口如 /admin/users的请求。前端代理仅审查外部的合法请求并放行。当这个被走私的请求到达 Kestrel 时它会被附加到连接池中下一个请求的前面。如果下一个请求来自一位已认证的管理员那么这个恶意请求就可能在管理员的会话上下文中被执行从而实现权限提升。场景二会话劫持与数据窃取 攻击者走私一个不完整的 POST 请求。当下一个用户的合法请求包含其 Cookie 或 Authorization 头到达时该用户的整个请求可能被 Kestrel 错误地附加为攻击者走私请求的 Body。如果攻击者走私的请求被设计为将接收到的数据外传他就能成功窃取到受害用户的会-话凭证或敏感数据。场景三Web 缓存投毒 (Web Cache Poisoning) 如果应用前端部署了缓存层如 CDN攻击者可以利用此漏洞进行缓存投毒 。攻击者走私一个请求该请求会触发后端应用返回一个恶意响应例如包含恶意 JavaScript 的页面并将其与一个会被缓存的热门资源如主页或某个 JS 文件的 URL 关联。此后所有请求该资源的用户都将收到被投毒的恶意内容。长期加固策略除了立即应用补丁还应考虑通过架构层面的改进来提供纵深防御以抵御未来可能出现的类似漏洞。端到端使用 HTTP/2 HTTP/2 协议从根本上改变了请求的传输方式它使用确定性的二进制分帧层来界定请求不再依赖 Content-Length 或 Transfer-Encoding 头因此天然免疫经典的请求走私攻击 。应尽可能配置前端代理与 Kestrel 后端之间使用 HTTP/2 进行通信。规范化模糊请求 配置前端代理如 Nginx, HAProxy, Azure Application Gateway 等在将请求转发到后端之前对其进行“规范化”处理。例如拒绝任何同时包含 Content-Length 和 Transfer-Encoding 头的请求或剥离所有不必要的头信息 。结论CVE-2025-55315 是 ASP.NET Core 核心组件中的一个高危漏洞其 9.9 的 CVSS 评分客观反映了其对应用安全构成的严重威胁。鉴于其影响范围广泛且利用门槛较低所有使用受影响版本.NET 的团队都应立即采取行动识别并修复环境中的所有相关资产。此次事件也再次提醒我们现代应用安全是一个全栈挑战。开发者不仅要关注业务逻辑代码的安全性还必须对底层协议、Web 服务器到基础设施的每一个层面有充分的理解和保护。安全不仅是业务逻辑层面的事更是贯穿整个技术栈的挑战。从网络协议到 Web 服务器再到我们的应用程序代码任何一个环节的疏忽都可能导致整个系统的崩溃。