这可能是最详细的解析HTTP走私攻击的文章

前言

HTTP Desync Attacks也就是HTTP走私攻击,是我见到的比较有趣的一种攻击方式,这里来对这种漏洞进行介绍。

TL;DR

HTTP走私攻击利用了HTTP协议本身的问题:HTTP中存在两种方式来指定请求的结束位置。因此,相同的HTTP请求,不同的服务器可能会产生不同的处理结果,这样就产生了了安全风险。

具体分析

HTTP/1.1

在HTTP协议中,存在两种Header来指定请求的结尾,分别是Content-Length以及Transfer-Encoding。Content-Length用来指明发送给接收方的消息主体的大小,后面的数字就代表了这个消息的大小;Transfer-Encoding指明了将实体安全传递给用户所采用的编码形式,常见的值有chunked,compress,deflate,gzip等,其中chunk表示消息体使用分块编码(Chunked Encode),也就是整个请求会分块发送,由多个消息组成,整个消息体以大小为0的块结束,也就是说解析遇到0数据块就结束,因此带来了一种新的判断结尾的方式。
这两个Header都源于RFC 7230也就是HTTP/1.1,在之前的版本中HTTP协议规定浏览器与服务器只保持短暂的连接,服务器完成请求即断开连接。显然,这种方式是有问题的,因此HTTP 1.1支持持久连接,在一个TCP连接上可以传送多个HTTP请求和响应。同时这个规范也带来了Content-Length以及Transfer-Encoding这两个Header,虽然协议明确说明以Transfer-Encoding为准,但是仍然存在很多服务器没有完全遵守规范,从而导致不同的服务器对结尾的判断不同,也就导致了这种漏洞。

CDN和代理

其实该漏洞早在2005年就有人提出,不过随着内容分发网络(CDN)的兴起,CDN本质上是一个反向代理,缓存了大量的静态网站数据,如果用户访问静态数据,直接从代理服务器中就可以获取到,不用再从源站所在服务器获取,从而提高访问速度并且降低网络拥塞,一个典型的CDN结构如下图:

可以看出,CDN的出现,使得大量用户会先访问CDN服务器,CDN服务器会判断是否有动态请求或者没有命中缓存的情况,如果存在,CDN会先代替用户请求,最后将封装好的请求返回给用户。可以看到,如果请求一个动态内容如查询等,CDN此时相当于一个代理,会讲用户的请求发送给服务器,如果这两者没有正确处理结尾,就会导致HTTP走私的出现。当下CDN的大量使用使得这种漏洞的重新兴起。

分类

我们可以将这种情况抽象为前端和后端两种服务器,根据前后服务器处理方式的差异,HTTP走私共分为三种:
– CLTE:前端服务器使用 Content-Length 头,后端服务器使用 Transfer-Encoding 头
– TECL:前端服务器使用 Transfer-Encoding 标头,后端服务器使用 Content-Length 标头。
– TETE:前端和后端服务器都支持 Transfer-Encoding 标头,但是可以通过以某种方式来诱导其中一个服务器不处理它。

CLTE

对于CLTE类型,如果构造如下请求,由于pipeline特性,会导致下一个请求的开头多了个PP

POST / HTTP/1.1\r\n
Host: example.com\r\n
...
Connection: keep-alive\r\n
Content-Length: 6\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
pp

前端由于是从Content-Length获取结尾,因此会讲全部作为一个包发送,但后端会在0处截断,从而导致认为pp是下一个包的开始,导致下一个请求的开头多了个pp

CL/CL

CLCL是构造一个包含两个Content-Length的包,根据规范此时应当返回400错误,但如果没有正确遵守规范,且前端按不同的CL进行处理,这可能会导致HTTP走私,例子如下:

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 8\r\n
Content-Length: 7\r\n
12345\r\n
a

该例子的过程和上一节类似

TE/TE

该种方式是前后端服务器都支持并且默认使用te来处理,使用某种方式导致一端不识别te块来达到,cl-te或者te-cl的方式。例子如下:

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-length: 4\r\n
Transfer-Encoding: chunked\r\n
Transfer-encoding: cow\r\n
\r\n
5c\r\n
aPOST / HTTP/1.1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 15\r\n
\r\n
x=1\r\n
0\r\n
\r\n

可以看到前后的Transfer-Encoding,E的大小写不同,因此可能导致识别的不同。

TE/CL

TE-CL指前端服务器处理 Transfer-Encoding 请求头,而后端服务器处理 Content-Length 请求头。

POST / HTTP/1.1\r\n
Host: example.com\r\n
...
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
\r\n
12\r\n
aPOST / HTTP/1.1\r\n
\r\n
0\r\n
\r\n

前端全读,后端只读一部分

DEFCON CTF QUAL 2020 uploooadit

该题给了两个接口,一个是POST /文件/,该接口用于上传文件,会返回文件的id。另一个是GET /files/<guid>,该接口用于请求保存的文件。
同时我们可以看到前端服务器是一个haproxy 1.9.10,后端是Flask。
通过测试发现存在CL/TE类型的HTTP Desync,因此构造

这个的解析流程是,haproxy看到了187,便将整个请求发送给了后端,而后端只看TE,因此在0处截断,并将后面的内容看作第二个包,后面的部分只有CL,因此后端会继续读内容知道达到385长度为止,如果此时有别人传文件,文件内容会被我们的2aaaaa-aaaaa-aaaaa-aaaaaaaaaa读取到。
这个题目是存在一个不断上传flag的机器人,因此我们只要一直发送这样的包,读取我们上传的文件,就有可能获取到机器人上传的内容,最后我们GET /files/2aaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa,读取到了机器人上传的flag

总结

HTTP走私是源于服务端没有正确按照HTTP规范行事从而导致的漏洞,因此解决方案也很简单,按照HTTP/1.1规范正确处理请求,或者尽量避免服用连接就可以解决该漏洞。

Posted in WEB

发表评论