共计 4175 个字符，预计需要花费 11 分钟才能阅读完成。
作者：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
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
申请体中每个字符为一个字节的长度，换行符蕴含 \r 和 \n 两个字节长度。每段申请内容别离由一行 16 进制长度值和一行内容自身所组成，例如“q=smuggling”长度为 11（16 进制：b），“q=smuggle”长度为 9（16 进制：9）。内容完结后，以 0 和两个换行符完结申请体：
- Transfer-Encoding: chunked
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded Transfer-Encoding: chunked
b
q=smuggling
9
q=smuggle
0
[\r\n]
[\r\n]
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 申请走私可能使得攻击者随机在长连贯中影响其余同时拜访业务用户的申请内容，理论造成的影响取决于存在破绽的接口和业务自身提供了多少可能利用的权限和性能。
因而，如果说有哪种破绽可能在不间接攻打业务服务器和受害者电脑就可能施行大批量的攻打利用，从而影响到用户申请和收到的响应内容，则 Web 缓存净化和 HTTP 申请走私会是咱们重点关注的外围危险问题。
