HTTP请求走私

  • by

描述

HTTP请求走私漏洞是由解析HTTP请求的两台设备(比如反向服务器和后端服务器)间RFC协议差异而导致的。诸如Web服务器、应用防火墙、Web缓存服务器使用不同的方式来解析HTTP请求。

在特定的情况下,一个HTTP请求通道中存在两个或多个HTTP实体,又因为设备见遵循的协议不同,导致之后的HTTP实体被走私到第二台设备中,而第一台设备无法意识到。

常见走私方法

CL不为0

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

比如构造请求:

GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 44\r\n
GET / secret HTTP/1.1\r\n
Host: example.com\r\n
\r\n

前端服务器收到该请求,通过读取Content-Length,判断这是一个完整的请求,然后转发给后端服务器,而后端服务器收到后,因为它不对Content-Length进行处理,由于Pipeline的存在,它就认为这是收到了两个请求,分别是

GET / HTTP/1.1\r\n
Host: example.com\r\n
第二个
GET / secret HTTP/1.1\r\n
Host: example.com\r\n

CL-CL

假设中间的代理服务器和后端的源站服务器在收到类似的请求时,都不会返回400错误,但是中间代理服务器按照第一个Content-Length的值对请求进行处理,而后端源站服务器按照第二个Content-Length的值进行处理,这样便有可能引发请求走私。

CL-TE

CL-TE,就是当收到存在两个请求头的请求包时,前端代理服务器只处理Content-Length这一请求头,而后端服务器会遵守RFC2616的规定,忽略掉Content-Length,处理Transfer-Encoding这一请求头。

TE-CL

TE-CL,就是当收到存在两个请求头的请求包时,前端代理服务器处理Transfer-Encoding这一请求头,而后端服务器处理Content-Length请求头。

TE-TE

TE-TE,当收到存在两个请求头的请求包时,前后端服务器都处理Transfer-Encoding请求头,确实是实现了RFC的标准。不过前后端服务器不是同一种。这就有了一种方法,我们可以对发送的请求包中的Transfer-Encoding进行某种混淆操作(如某个字符改变大小写),从而使其中一个服务器不处理Transfer-Encoding请求头。在某种意义上这还是CL-TE或者TE-CL

实战Lab

体验CL-TE

Lab地址: https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te

这个Lab能够让你直接的体验到CL-TE给其他用户造成“无效的请求方法”的错误。

第一次请求,走私一个字符串“G”

走私的字符串会挂在缓冲区中,后端服务器等待一个新的请求后会进行拼接, 将直接影响下一个请求的发起用户,会变成这样:

GPOST / HTTP/1.1

利用CL-TE

Lab地址:lab-bypass-front-end-controls-cl-te

Lab说明:涉及前后端服务器,且前端服务器不支持TE,admin界面在/admin路径下,通过前端服务器无法访问,需要走私请求访问后台删除carlos用户。

访问/admin,显示”Path /admin is blocked”

利用CL-TE走私请求访问/admin,走私成功后提示需要localhost

添加Host: localhost得到后台页面以及删除用户的url,随即请求删除即可。

这里有点奇怪,Host: localhost后面必须加回车,不然不会当作一个完整的请求提示:

{“error”:”Forbidden: Duplicate header names are not allowed”}

参考: https://paper.seebug.org/1048

发表评论

电子邮件地址不会被公开。 必填项已用*标注