RestSharp v112 安全更新全解析：CVE-2024-45302 与 Header 值 CRLF 注入防护

RestSharp v112 安全更新全解析CVE-2024-45302 与 Header 值 CRLF 注入防护【免费下载链接】RestSharpSimple REST and HTTP API Client for .NET项目地址: https://gitcode.com/gh_mirrors/re/RestSharp导读本文围绕 RestSharp v112 系列v112.0 与 v112.1的 changelog 展开深入剖析本次针对 CVE-2024-45302 的安全修复为何 HTTP Header 值中的CRLF字符是致命漏洞RestSharp 如何在源码层拦截恶意输入以及 v112.1 为何又对禁止字符列表做了减法移除\t。读完本文你将理解 Header 注入/请求走私类攻击的成因、RestSharp 的防护实现与测试验证方式并掌握升级到 v112 后如何正确适配AddHeader系列 API 的行为变化。本文以 版本化文档 v112 changelog 为主体结合仓库内 HeaderParameter.cs 源码与 RequestHeaderTests.cs 测试用例进行印证。一、v112 系列改了什么两个小版本一次安全修复v112 的 changelog 内容非常精炼只有两条但每一条都对应一次安全层面的关键变更v112.0针对 CVE-2024-45302 的安全修复Security fix for CVE-2024-45302. Header values cannot containCRLF.v112.0 的核心动作是RestSharp 从此拒绝在 Header 值中包含CRLF即\r\n回车 换行的请求。这属于一次强制性的安全加固——不是警告、不是自动转义而是直接抛异常拒绝构造这样的请求。v112.1对禁止字符列表的修正Follow up on v112.0 security fix: remove\tfrom the list of forbidden characters in headers.v112.1 是紧随其后的修正v112.0 在收紧校验时曾将制表符\t一并列入禁止字符v112.1 将其移出禁止列表恢复\t在 Header 值中的合法性。值得注意的是仓库中的版本化文档为 v112 保留了独立的文档快照见 docs/versions.json 中的v112条目与 version-v112 文档目录说明该版本仍被官方文档体系维护其安全修复也完整同步进了后续版本v113 及以上的 changelog 同样收录了这两条记录例如 version-v113 changelog。二、漏洞背景为什么 Header 值里的 CRLF 是危险的2.1 HTTP 报文结构决定了 CRLF 的特殊地位在 HTTP/1.x 协议中报文由CRLF\r\n作为分隔符请求行与请求头之间、每个 Header 字段之间、Header 与 Body 之间全部依赖\r\n进行切分一个 Header 字段的终止恰好就是它后面的第一个CRLF。这就带来一个经典问题如果应用程序把用户可控的输入直接拼接到 Header 值中且不校验其中是否包含CRLF攻击者就能利用\r\n提前终结当前字段并伪造出新的 Header 字段甚至伪请求体。2.2 攻击场景响应头注入与请求走私结合仓库测试用例中展示的 payload见 RequestHeaderTests.cs一次典型的注入尝试长这样test\r\nUser-Agent: injected header!\r\n\r\nGET /smuggled HTTP/1.1\r\nHost: insert.some.site.here攻击者把一个看似正常的 Header 值通过嵌入\r\n扩展成一个额外的User-Agent: injected header!字段响应头注入 / Header 注入一段以空行\r\n\r\n结尾、接着伪造的GET /smuggled HTTP/1.1请求行HTTP 请求走私的雏形。这类漏洞在真实世界中可能被利用于向响应中注入恶意内容XSS 变体、绕过代理/缓存、污染下游请求甚至将攻击请求走私给后端服务器。CVE-2024-45302 正是 RestSharp 被报告的这一类问题。2.3 修复的直观意义修复后上述 payload 无法通过 RestSharp 的 API 进入 HTTP 管线——AddHeader直接抛出ArgumentException从源头切断注入面而不是依赖HttpClient或下游服务器去兜底。三、源码级验证Header 校验到底在哪里发生3.1 校验入口HeaderParameter 构造函数所有 Header 相关的请求扩展方法最终都会创建 HeaderParameter校验逻辑就集中在它的构造函数与静态方法中public HeaderParameter(string name, string value, bool encode false) : base( EnsureValidHeaderString(Ensure.NotEmptyString(name, nameof(name)), name), EnsureValidHeaderValue(name, value, encode), ParameterType.HttpHeader, false ) { }这里同时校验了两类输入Header 名称不能为空字符串NotEmptyString且同样要经过EnsureValidHeaderString的字符级检查Header 值先做Host字段专项校验CheckAndThrowsForInvalidHost再经EnsureValidHeaderString做字符级检查最后通过Ensure.NotNull拒绝null值。3.2 核心判定IsInvalidHeaderString 只禁 CR 与 LF当前仓库中 IsInvalidHeaderString 的实现 是 v112.1 之后的最终状态static bool IsInvalidHeaderString(string stringValue) { for (var i 0; i stringValue.Length; i) { switch (stringValue[i]) { case \r: case \n: return true; } } return false; }两个值得注意的细节只针对\rCR0x0D与\nLF0x0A判定为非法与 v112.0/v112.1 的安全修复目标完全一致\tHTAB0x09不在禁止列表中这正是 v112.1 移除\t之后的状态——代码里只保留了对 CRLF 的拦截。一旦检测到非法字符EnsureValidHeaderString 会抛出static string EnsureValidHeaderString(string value, string type) !IsInvalidHeaderString(value) ? value : throw new ArgumentException($Invalid character found in header {type}: {value});即ArgumentException(Invalid character found in header value: ...)。3.3 为什么 v112.1 要移除 \t这与 HTTP 规范有关在 RFC 7230 等规范中Header 字段值field-value允许包含可见字符以及HTAB水平制表符与SP空格作为字段内空白。\t本身是合法字符很多既有应用例如配置格式中缩进、多值拼接会依赖它。v112.0 修复时采取的宁严勿宽策略把\t一并禁掉虽然更安全但会误伤合法用例v112.1 随即将其移出禁止列表把防护范围精确收敛到真正危险的 CR/LF 上。从当前源码看最终落地的策略正是这种精确拦截。四、测试如何验证修复从注入 payload 到异常断言安全修复是否生效最终要靠测试兜底。仓库在 RequestHeaderTests.cs 中专门为本次修复补充了测试用例[Fact] public void Should_not_allow_CRLF_in_header_value() { var request new RestRequest(); Assert.ThrowsArgumentException(() request.AddHeader(name, test\r\nUser-Agent: injected header!\r\n\r\nGET /smuggled HTTP/1.1\r\nHost: insert.some.site.here)); }这个测试的要点构造攻击载荷复刻真实的 Header 注入 payload注入User-Agent头 伪造请求行走公开 API通过RestRequest.AddHeader触发校验链路验证的不是某个内部方法而是用户实际调用的入口断言异常类型ArgumentException被抛出证明恶意输入在请求发出前就被拦截。与它同文件的还有一组输入校验测试共同勾勒出 v112 对 Header 输入的完整防护矩阵RequestHeaderTests.cs测试输入期望异常Should_not_allow_null_header_value值为nullArgumentNullException参数名valueShould_not_allow_null_header_name名为nullArgumentNullException参数名nameShould_not_allow_empty_header_name名为空字符串ArgumentException参数名nameShould_not_allow_CRLF_in_header_value值含\r\n注入载荷ArgumentException五、对开发者的影响升级到 v112 需要知道什么5.1 API 层面行为从容忍变为拒绝本次修复没有新增 API而是收紧既有 API 的输入校验。所有创建HeaderParameter的入口都会受影响主要包括 RestRequestExtensions.Headers.cs 中的AddHeader(name, value)/AddHeader(name, values[])/AddHeaderT(name, value, culture)AddOrUpdateHeader(name, value)/AddOrUpdateHeaderT(...)AddHeaders(...)/AddOrUpdateHeaders(...)批量方法。由于这些方法最终都汇聚到HeaderParameter构造因此单一入口校验意味着任何路径下的非法值都会被一致拦截。5.2 代码适配建议如果你的业务代码中 Header 值可能来自用户输入如文件名、URL 参数、日志字段等升级后请检查输入预处理在调用AddHeader前剔除或转义\r、\n例如对换行做替换或直接拒绝异常处理ArgumentException属于同步抛出的编程错误类异常建议在组装请求时统一捕获并转换为业务错误提示避免请求构造失败被当作网络错误误判合法用例回归确认没有依赖\t在 Header 值中的代码——v112.1 之后\t已恢复合法但如果你的代码基于 v112.0 的严格列表做了过滤可以放宽到只处理 CR/LF不要绕过校验不要在构建HeaderParameter之后再手工修改Parameter.Value或直接操作HttpRequestMessage.Headers绕过防护——那会重新打开注入面集成测试也验证了拦截器内直接Headers.Add的行为见 HttpHeadersTests.cs。5.3 服务端配合客户端校验是第一道防线但服务端仍应继续对收到的 Header 做 RFC 合规校验拒绝含 CR/LF 的字段形成纵深防御。RestSharp 的修复解决的是客户端不再可能发出这类请求而非替代服务端的安全策略。六、如何确认你的环境已应用修复判断所使用版本是否包含该修复可以从两个维度核对版本号确认依赖锁定在112.0.0及以上112.0.0已包含 CRLF 拦截112.1.0起\t恢复合法源码特征检查HeaderParameter中IsInvalidHeaderString的switch分支是否仅包含\r与\n两个case——若包含\t分支则处于 v112.0 的严格状态若完全没有 CR/LF 检查则属于修复前的旧版本。仓库中同时保留了 v112 与 v113 的版本化文档docs/versioned_docs/version-v112、docs/versioned_docs/version-v113两份 changelog 均收录了本次修复方便对照各版本的文档基线。结语RestSharp v112 的这次更新虽然只涉及两个小版本、两行 changelog背后却是完整的漏洞发现 → 紧急修复 → 策略修正 → 测试固化闭环v112.0 用最严格的字符黑名单切断 CRLF 注入面v112.1 在安全与兼容之间校准刻度恢复\t源码 HeaderParameter.cs 给出精确到字符级的实现RequestHeaderTests.cs 用真实攻击载荷锁定回归。对开发者而言理解这条修复链路既是升级到 v112 的适配指南也是一堂关于HTTP Header 输入校验的实战安全课。【免费下载链接】RestSharpSimple REST and HTTP API Client for .NET项目地址: https://gitcode.com/gh_mirrors/re/RestSharp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考