非侵入式入侵 —— Web 缓存污染与请求走私
作者：vivo 互联网安全团队- Gui Mingcheng
本文介绍了两种攻击者无需直接接触服务端即可攻击和影响用户行为的安全漏洞 —— Web 缓存污染与请求走私。Web 缓存污染旨在通过攻击者向缓存服务器投递恶意缓存内容，使得用户返回响应结果而触发安全风险。HTTP 请求走私旨在基于前置服务器（CDN、反向代理等）与后置服务器对用户请求体的长度判断标准不一致的特性，构造能够被同一 TCP 连接中其它用户夹带部分恶意内容的攻击请求，从而篡改了受害者的请求与响应行为。两种漏洞均需要通过针对中间件的合理配置与业务接口的合理设计进行排查和防御。
一、Web 缓存污染攻击原理与场景
1.1 什么是缓存？
缓存技术旨在通过减少延迟来加速页面加载，还可以减少应用程序服务器上的负载。一些公司使用像 Varnish 这样的软件来托管他们自己的缓存，而其他公司选择依赖像 Cloudflare 这样的内容分发网络（CDN），缓存分布在世界各地。此外，一些流行的 Web 应用程序和框架（如 Drupal）具有内置缓存。Web 缓存污染关注的是 CDN 等前置服务端部署的缓存服务，还有其他类型的缓存，例如客户端浏览器缓存和 DNS 缓存，但它们不是本次研究的关注点。
1.2 缓存的工作机制？
由 CDN 等代理层服务器根据“缓存键”缓存用户请求对应的响应，并在某个请求再次到来时直接返回相应的响应包。例如如下场景中，红色字体标识了缓存服务器配置的缓存键内容，A 用户访问服务端返回的结果后，B 用户再次访问仅会取得缓存服务器中的内容，因为缓存服务器认为两者是同一个请求，无需再向业务服务端重新请求一次。
1.3 缓存污染具体是如何实现的？
当攻击者的请求中，缓存键和普通用户没有差别，而请求中其它部分存在可体现在响应包中的恶意内容或代码时，该响应被缓存后，其它请求了同一个正常缓存键对应接口的用户会直接得到攻击者提前交给缓存服务器缓存的恶意响应。
以下是一个简单的例子，业务某个接口存在逻辑：获取用户请求 Host 头的内容，拼接至响应包的 js 链接中作为访问域名。此时攻击者注入恶意域名 hack.com，受害者访问缓存资源的时候得到的是和攻击者一样的响应结果。此时攻击者通过 JavaScript 代码几乎劫持了受害者在前端的所有信息和行为，具体的后果则由其中的恶意代码所决定，这与 XSS 的攻击后果是类似的。
Web 缓存能够构造什么样的攻击，取决于在不破坏缓存键的同时，构造能够在响应中体现恶意行为的请求，例如业务逻辑对 Host 头中的值进行校验和请求，但没有校验端口号是否为 443 或 80。此时可以构造请求使得响应跳转至 1337 端口，其它受害者对该接口的访问便不再可用：
拓展学习 —— 攻击者如何确定缓存键的覆盖范围？
首先需要确认是否存在缓存键：
HTTP 头直接返回缓存的相关信息
观察动态内容的变化
返回时间的差异
特定的第三方缓存配置头
如何定位缓存键的覆盖范围：
对请求 A 改动一处成为请求 B，各自响应有所差异。若请求 B 后得到 A 的缓存结果，则说明 A、B 的缓存键相同，也说明了改动之处并非缓存键。
改变请求 A 某处内容发送，响应 cache 头仍然在缓存计时，说明该处内容部分不为缓存键。反之，重新命中，则该处内容包含缓存键。
利用特定的头来查询缓存键，例如：Pragma: akamai-x-get-cache-key, akamai-x-get-true-cache-key。
二、Web 缓存污染防御手段
2.1 禁用缓存配置
对缓存投毒的最强大防御办法就是禁用缓存。
对于一些人来说，这显然是不切实际的建议，但我推测很多网站开始使用 Cloudflare 等服务的目的是进行 DDoS 保护或简化 SSL 的过程，结果就是容易受到缓存投毒的影响，因为默认情况下缓存是启动的。如果对确定哪些内容是“静态”的足够确认，那么只对纯静态的响应进行缓存也是有效的。
2.2 避免从请求中直接获取输入放在响应中
一旦在应用程序中识别出非缓存键的输入，理想的解决方案就是彻底禁用它们。如果不能实现的话可以在缓存层中剥离该输入，或将它们添加到缓存键。建议使用 Param Miner 等审计应用程序的每个页面以清除非缓存键的输入。
三、HTTP 请求走私攻击原理与场景
3.1 HTTP 请求走私的基本原理
在 RFC2616 的第 4.4 节中，规定：如果收到同时存在 Content-Length 和 Transfer-Encoding 这两个请求头的请求包时，在处理的时候必须忽略 Content-Length。但实际处理往往没有遵守该协议。HTTP 请求的开头与结束标志可以通过 Content-Length 来决定，也可以通过声明的 Transfer-Encoding: chunked 对 HTTP 分组来决定。当前置服务器和后置服务器对 HTTP 请求开头和结束标志的判断处理标准不一致时，就可能导致攻击者前一个请求的后半部分在后置被认为是下一个请求的开头，从而出现 HTTP 走私漏洞。
根据前后置服务器的不同请求体长度判断组合模式，有以下攻击场景：
本质原因：
前后置服务器对请求体长度的判断标准存在 Content-Length 和 Transfer-Encoding 两种形式
前置服务器和后置服务器之间存在 TCP 连接重用，混杂多个用户的请求
3.2 Content-Length 和 Transfer-Encoding 请求头如何制定请求体长度？
请求体中每个字符为一个字节的长度，换行符包含 \r 和 \n 两个字节长度，Content-Length 标识请求体从开头到最后一个字符的总长度：
Content-Length
请求体中每个字符为一个字节的长度，换行符包含 \r 和 \n 两个字节长度。每段请求内容分别由一行 16 进制长度值和一行内容本身所组成，例如“q=smuggling”长度为 11（16 进制：b），“q=smuggle”长度为 9（16 进制：9）。内容结束后，以 0 和两个换行符结束请求体：
Transfer-Encoding: chunked
3.3 HTTP 请求走私如何攻击？
基于上面描述的 5 种前后置服务器不同的请求体长度判断模式，这里抽选其中的 CL-TE 和 TE-CL 模式进行举例：
CL - TE
此时，业务前置服务器取用户请求头中 Content-Length 的值为长度判断标准，后置服务器根据 Transfer-Encoding: chunked 解析请求体来判断请求体长度。
如下所示，攻击者构造的请求，前置服务器认为有 6 个字符，包含了 0 和两个换行 以及 G。而后置服务器则根据 Transfer-Encoding: chunked 解析请求体，认为 0 和两个换行符已经是请求的结束标志，字符 G 被滞留在了 TCP 管道中。
此时同一个 TCP 连接中中，一个受害者的请求接踵而至，后置服务器便会将字符 G 拼接至其请求开头，从而使得受害者实际对业务请求了 GGET 方法。
TE - CL
与 CL - TE 类似，前置服务器先根据 Transfer-Encoding: chunked 放行攻击者的整个请求体，经过后置服务器对 Content-Length 的判断，分割前半部分请求体给业务服务端，后半部分由受害者承接。
可以看到，这里攻击者完全可以劫持受害者的请求，从接口地址到请求头以及请求参数，因此具有较大的危害性。
3.4 HTTP 请求走私攻击的效果是什么？
这里举一个例子 —— 捕获其他用户的请求。攻击者发现业务存在 HTTP 请求走私漏洞，同时又找到了评论接口 /post/comment 这种可以回显请求内容的功能点。那么攻击者就可以走私一个 /post/comment 的评论请求，从而让受害者“被迫”以这个请求去访问服务端。受害者的请求则被拼接到评论请求中的 comment 参数后，作为请求内容而出现。
攻击者去查看评论区，发现受害者已经将自己先前的请求（连同 Cookie 等信息）一并发送到了评论区。
踩坑记录
这里受害者的请求中一旦出现 “&” 字符，就会被当做 POST BODY 的参数分隔符从而中止 comment 评论内容参数的解析。因此评论区仅能看到受害者请求中第一个 “&” 字符之前的内容。
四、HTTP 请求走私防御手段
4.1 通用防御措施
禁用代理服务器与后端服务器之间的 TCP 连接重用。
使用 HTTP/2 能够避免请求边界判定标准不一致的问题。
前后置服务器使用同样的 web 服务器程序，保证对请求边界的判断标准是一致的。
4.2 实际问题
以上的措施有的不能从根本上解决问题，而且有着很多不足，就比如禁用代理服务器和后端服务器之间的 TCP 连接重用，会增大后端服务器的压力。使用 HTTP/2 在现在的网络条件下根本无法推广使用，哪怕支持 HTTP/2 协议的服务器也会兼容 HTTP/1.1。从本质上来说，HTTP 请求走私出现的原因并不是协议设计的问题，而是不同服务器实现的问题。因此要严格保证前后置服务器对请求边界的判断标准是一致的来防护该类型风险的出现。
五、实战演示
六、总结
Web 缓存污染和 HTTP 请求走私是两种不太被关注到、但影响力和危害较大的两种安全漏洞类型。其共同点是均脱离业务应用本身，依托于严格规范的运维、网络人员的相关配置，因此在出现问题时对业务逻辑本身的排查往往会偏离实际情况。
Web 缓存污染能够使攻击者批量影响共用了同一缓存资源的所有用户，HTTP 请求走私能够使得攻击者随机在长连接中影响其他同时访问业务用户的请求内容，实际造成的影响取决于存在漏洞的接口和业务本身提供了多少能够利用的权限和功能。
因此，如果说有哪种漏洞能够在不直接攻击业务服务器和受害者电脑就能够实施大批量的攻击利用，从而影响到用户请求和收到的响应内容，则 Web 缓存污染和 HTTP 请求走私会是我们重点关注的核心风险问题。
版权声明: 本文为 InfoQ 作者【vivo互联网技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/bb4aed961030efb7b256ede3e】。文章转载请联系作者。
官方公众号：vivo互联网技术，ID：vivoVMIC 2020-07-10 加入
分享 vivo 互联网技术干货与沙龙活动，推荐最新行业动态与热门会议。
评论