浅析HTTP走私攻击

如今攻击手段日益层出不穷，令企业防不胜防，因此企业不能再以原有的防守思维去防守。基于攻击者的视角，了解攻击者的攻击手法才能更好地做好防守。本次介绍的是攻击者常用的一种攻击手法“HTTP请求走私”，它可以使攻击者能够绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。本文由锦行科技的安全研究团队提供，旨在通过剖析“HTTP请求走私”的攻击过程，帮助企业进一步了解攻击者的攻击思路，做好应对策略。

什么是HTTP请求走私？

在复杂的网络环境下，不同的服务器以不同的方式实现RFC标准，利用前后端服务器对数据包的边界了解不一致，向一个请求数据包中插入下一个请求数据包的一部分，从前端服务器角度看来，它属于一个完整的请求，而在后端服务器看来，它属于两次请求，前端请求的一部分被后端服务器解释为下一个请求的开始。因此，它使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。

产生的原因

在HTTP1.1后，增加了一个特殊的请求头Connection: Keep-Alive，建立tcp持续通道，进行一次tcp握手，就能传送多个请求。但这样只能是请求一次响应一次。为了提高数据传输的效率，减少阻塞。后来就有了HTTP Pipelining（管线化）字段，它是将多个http请求批量提交，而不用等收到响应再提交的异步技术。如下图就是使用Pipelining和非Pipelining

这意味着前端与后端必须短时间内对每个数据包的边界大小达成一致，否则，攻击者就可以构造发送一个特殊的数据包，在前端看来它是一个请求，但在后端却被解释为了两个不同的HTTP请求。这就导致攻击者可以在下一个用户发送的合法数据包前恶意添加内容。如图，走私的内容（“前缀”），以橙色突出显示：

假设前端考虑的是内容长度头部(Content-Length)值作为数据包结束的边界，后端优先考虑的是Transfer-Encoding头部。那么从后端角度看，如下图蓝色部份字体属于一个数据包，而红色部份字体属于下一个数据包的开始部份。这样就成功从前端“走私”了一个数据包。

攻击类别

01 CL不为0的GET请求
假设前端代理服务器允许GET请求携带请求体，而后端服务器不允许GET请求携带请求体，它会直接忽略掉GET请求中的Content-Length头，不进行处理。这就有可能导致请求走私。

比如发送下面请求：

GET / HTTP/1.1
Host:example.com
Content-Length:44
GET /socket HTTP/1.1
Host: example.com

前端服务器通过读取Content-Length，确认这是个完整的请求，然后转发到后端服务器，而后端服务器因为不对Content-Length进行判断,由于Pipeline的存在,它认为这是两个请求，分别为：
第一个
GET / HTTP/1.1
Host: example.com
第二个
GET /socket HTTP/1.1
Host: example.com
则相当于走私了请求。

02 CL-CL
在RFC7230规范中，规定当服务器收到的请求中包含两个Content-Length，而且两者的值不同时ÿ