有没有大神了解 http 请求走私

http 请求走私

昨晚 burp 抓包抓出一个奇怪漏洞,叫 http 请求走私,第一次遇到。有点难搞哦

于是研究了一个通宵,可能是我太菜了,现在还没整明白,所以有了这个帖子(当然有误报的可能)

查看 burp 官方文档得知,burp 扫描利用的是延时测试

CL-TE 测试

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

由于前端服务器使用 Content-Length 标头,因此它将仅转发此请求的一部分,而忽略 X。后端服务器使用 Transfer-Encoding 标头,处理第一个块,然后等待下一个块到达。这将导致明显的时间延迟。

扫描器中的 payload

Transfer-Encoding: chunked
Content-Length: 31
Connection: keep-alive

f
6lrim=x&y9q7p=x
1
Z
Q


返回包的状态 504

image.png

当我修改 payload 为

Transfer-Encoding: chunked
Content-Length: 31
Connection: keep-alive

f
6lrim=x&y9q7p=x
1
Z
0


返回包的状态为 404,时间正常,没有截断

image.png

此处的疑惑是为什么返回包会有截断?

是因为请求超时吗

我百度了一些资料 Transfer-Encoding: chunked,有的资料说结束标示符是 0\n\n 有的资料是 0,所以问题又来了

Transfer-Encoding: chunked 的结束标识符到底是什么?

如果忽略上一问而言

我修改 payload 为

Transfer-Encoding: chunked
Content-Length: 38
Connection: keep-alive

f
6lrim=x&y9q7p=x
1
Z
0


nihao

或者

Transfer-Encoding: chunked
Content-Length: 38
Connection: keep-alive

f
6lrim=x&y9q7p=x
1
Z
0

nihao

那么 nihao 将会出现在下一个用户中的请求头中,成为

nihaoGET / HTTP/1

但是我怎么刷新页面都是 404,问题出在哪儿了(当然前提是这个漏洞存在)

假设这个漏洞不存在,为什么页面会延时返回

  • HTTP
    62 引用 • 123 回帖 • 1 关注
  • 安全

    安全永远都不是一个小问题。

    153 引用 • 803 回帖 • 560 关注
  • BurpSuite
    2 引用 • 9 回帖
  • Q&A

    提问之前请先看《提问的智慧》,好的问题比好的答案更有价值。

    1732 引用 • 11426 回帖 • 583 关注
1 操作
guoguo23333 在 2020-06-28 09:23:40 更新了该帖

赞助商 我要投放

9 回帖
请输入回帖内容 ...
  • 88250

    嗯,所以得拼一个有用点的标头,比如文中后面提到的 cookie。看上去该攻击方式需要很大的运气,但是一旦成功意味着可以执行任何接口操作。

    1 回复
  • 其他回帖
  • guoguo23333

    去掉回车和换行,这样做的目的是什么?trollface

  • guoguo23333

    大概已经知道是误报了,但是现在还有一个疑惑,为什么服务器那边会请求超时

  • 88250

    我觉得可以先找一个确定有漏洞的地方练手,或者自己搭建一下,似乎配置 NGINX 就可以。如果能重现攻击,再找不确定的站点实验。

    1 回复
  • 查看更多回帖