没能复现的学习——DEFCON-HTTP-Smuggling

这篇文章主体框架来自@regilero在DEFCON上的议题-HTTP smuggling is a thing we should know better and care about.

0x00 闲扯Host header

作为重度网络依赖人群，我们每天都使用程序将数百次网页请求抛送到无形的网络空间中去，我们告知网络服务器我们要访问的资源，接受何种格式、何种语言的回应，是否要和服务器维持一段时间的连接，是否需要保存一些状态以及告知服务器你的代理发送人（浏览器或其他）身份。但是我们了解我们发送的这些东西的真正含义吗？

其实作为一次网页请求，理论上我们只要告诉服务器我们要的资源url就可以。那么那些多余的键值大体起什么作用呢？

1. Accept族，这里的一系列字段决定了客户端接收的类型、压缩方式、字符集、语言等。这一类字段似乎是为了客户体验而产生的，它允许客户对自己喜欢的语言、字符集进行选择，并且提供选择因子“q”来界定对不同资源的喜好程度，q值越大越喜爱。而压缩则提供了更小的带宽占用和更快的访问速度。
2. Cache-Control，缓存控制机制
3. Connection,通常的参数会使用Keep-Alive，这个字段实际上算是对HTTP基础的补充，通过这个字段来使客户端到服务端的连接持续有效。而这个字段就是下面所描述问题的基础之一
4. Cookie，用户体验与隐私、安全势不两立的存在，被广泛研究介绍，就不用多说了。
5. User-Agent，这也是一个有意思的参数，它的存在最早是为了允许服务端差异化的提供页面，根据不同的框架提供不同的页面来适配不同的浏览器。最初，UA还是很单纯的，当时某些浏览器拥有了很好的显示效果，于是服务端检测到它们的时候就提供更好的页面，过了一段时间其他浏览器也有了相似的特性，为了也能够得到同样的页面，就会告诉浏览器自己和别人身份其实差不多，请给我优秀的页面，久而久之，大家的身份相互混来混去，于是大家都叫Mozilla了，然后又like上Gecko……就这样，UA不在那么单纯，浏览器们都充满了套路。

0x01 HTTP Pipeline

HTTP管线化是作者提到的又一个漏洞基础，管线化使得多个HTTP请求不需要等待应答即可发送，使用这一技术的初衷是提高页面的载入性能，通过一个数据包来发送多个HTTP请求，也可以减轻网络负载压力。

这是在一次管线化测试中捕获的HTTP包，可以很清晰的看出在这一个TCP包中拥有三个HTTP包。作者把Pipelines称为大多数smuggling问题之源。在我们实际的使用过程中，实际上并没有真正用到这一技术，因为大多数的浏览器默认并不使用HTTP Pipeline。但是实际上根据文档说明，大多数的服务端都应该支持这一技术。

对于Pipeline技术而言，虽然同时发出多个HTTP请求，但实际上它们还是有先后顺序的，而回应顺序与发送的先后顺序一致。

0x02 HTTP Smuggling 协议层面攻击

前面说到了HTTP Smuggling的两个基础是Header中的keep-alive和pipelining技术，而产生矛盾就产生于客户端与服务器通信经过中间代理这样的结构。

client——>middleware——>server

当客户端和代理通信时会使用Pipeline，而代理和服务器通信会保持keep-alive但不会使用Pipeline，而服务端不会意识到这一点，这就会造成两次不一样的请求通过构造会被服务端认为是同一次请求。

所以进行smuggling的过程就是：

• 客户端发送一个Pipelining的包，里面包含一个有效包和若干无效的http包。
• 请求包顺利通过中间件
• 服务端解析分割了请求包
• 由于错误，请求被服务端部分回应后，服务端认为Keep-alive依然连接，并且使用了Pipelining，于是等待下面的包。
• 而下一个包就不一定是攻击者发送来的，但是作为服务端依然把这个包回应给了攻击者。

在这里，作者告诉我们其实早在2005年，就已经有人提到了这种利用手法，最终可以造成的效果包括：

• 一个forbidden回复
• DOS掉一台过程中的机器
• 缓存投毒
• 劫持用户凭证

接下来的是作者的Demo展示，可惜作者在这里使用go语言和Nodejs来编写中间件和服务端，并没能在本地环境复现作者的手法，这个只能等到以后回顾的时候再来复现了。

0x03 期待的工具 HTTPWookiee

作者在最后还许了一个愿，他会在考虑安全因素的条件下在Github上放出一个相关漏洞代理的自动化测试工具，不过已经过去一个月了吧。

看作者的框图，这应该是一个通过发包、接受回应比对来判别代理漏洞利用的工具吧。