关于HTTP请求走私和Http响应拆分这件事

第一部分：Http响应拆分

在 HTTP 标头中包含未经验证的数据允许攻击者指定浏览器呈现的整个 HTTP 响应。当 HTTP 请求包含意外的 CR（回车，也由 %0d 或 r 给出）和 LF（换行，也由 %0a 或 n 给出）字符时，服务器可能会以被解释为两个不同的输出流进行响应HTTP 响应（而不是一个）。攻击者可以控制第二响应并发动攻击，例如跨站点脚本攻击和缓存中毒攻击。

在以下情况下，可能会出现 HTTP 响应拆分弱点：

那么我们举一个栗子

以下代码段从 HTTP 请求中读取博客条目作者的姓名 author 并将其设置在 HTTP 响应的 cookie 标头中。

String author = request.getParameter(AUTHOR_PARAM);...Cookie cookie = new Cookie("author", author);cookie.setMaxAge(cookieExpiration);response.addCookie(cookie);

假设在请求中提交了由标准字母数字字符组成的字符串，例如“Jane Smith”，则包含此 cookie 的 HTTP 响应可能采用以下形式：

HTTP/1.1 200 OK...Set-Cookie: author=Jane Smith...

但是，由于 cookie 的值是由未经验证的用户输入形成的，因此只有在为 AUTHOR_PARAM 提交的值不包含任何 CR 和 LF 字符时，响应才会保持这种形式。如果攻击者提交恶意字符串，例如：

Wiley HackerrnHTTP/1.1 200 OKrn

那么 HTTP 响应将被拆分为以下形式的两个响应：

HTTP/1.1 200 OK...Set-Cookie: author=Wiley Hacker HTTP/1.1 200 OK...

显然，第二个响应完全由攻击者控制，并且可以使用所需的任何标题和正文内容构建。攻击者构造任意 HTTP 响应的能力允许产生各种攻击，包括：

我们可以到在文章头部的时候我们就要注意换行字符了，这边在粘贴下来，可以对照数据包中的URL路径：当 HTTP 请求包含意外的 CR（回车，也由 %0d 或 r 给出）和 LF（换行，也由 %0a 或 n 给出）字符时，服务器可能会以被解释为两个不同的输出流进行响应HTTP 响应（而不是一个）

%0d 回车符

GET /xxx/xxx/http/839ak%0d%0d6bfk/xxxx/xxxxx.html HTTP/1.1Host: 192.168.0.1Upgrade-Insecure-Requests: xAccept-Encoding: xxxxxxxxAccept: */*Accept-Language: xxxxxxUser-Agent: xxxxxxxxxxxConnection: xxxxxxxxCache-Control: xxxxxxxx

响应包中的Set-Cookie

Set-Cookie: ANbookmark="http/839akd6bfkxxx/xxxx/xxxx.html"; path=/

那么我们还要记住一点就是如果发现响应可以进行拆分，必定也是可能存在HTPP请求走私，请求走私我们在平常渗透测试或者在挖掘SRC当中很少有这种，我也确定是否厂商是拒绝收这类漏洞，还是怎样，可以说在国内当中很少看见有这类漏洞厂商的报告披露出来，SO我们也只能在其中接触一下吧。

第二部分：HTTP 请求走私

HTTP 请求走私是一种通过干扰前端和后端服务器之间的请求处理来进行的攻击技术。攻击者通过修改请求以在第一个请求的正文中包含另一个请求来利用该漏洞。这是通过滥用 Content-Length 和 Transfer-Encoding 标头来完成的。攻击成功后，第一个请求正文中的第二个请求被走私处理。

我们看一下大概的标头：

以下是一个完整的示栗过程：

首先我们要了解两个标头的含义和输出：

Content-Length 标头：请求正文的大小（以字节为单位）。

Transfer-Encoding 标头：指定为分块，以便请求正文将分块发送（由换行符分隔），0 用于结束一个块。

在上面的第一张图和第二张图的请求中，我们可以看到该标头的样子

那么下面我翻译到一段其它文章来给大家详细的了解一下，这里也把原文链接给大家放出来。https://cobalt.io/blog/a-pentesters-guide-to-http-request-smuggling

HTTP走私当满足以下条件时，此攻击有效：

需要注意的是一个请求包中带有两个请求才能达到或满足攻击的需求，在Burp suite官方中有靶场环境我们也可以前往去实操一下。

上述请求被解释为 2 个不同的请求：

此漏洞需要对攻击方法有专门的了解。请注意，HTTP Smuggling 不会利用目标 Web 应用程序中的任何漏洞。通过利用 Web 服务器解释 HTTP 消息的方式，此漏洞可用于以下影响：

攻击类型：

下面给出了不同的攻击场景以及相应的 PoC。

HTTP 请求走私，基本 CL.TE 漏洞

偷偷向后端服务器发送一个请求，观察后端服务器处理的下一个请求似乎使用了 NEWPOST 方法。

HTTP 请求走私，基本 TE.CL 漏洞

偷偷向后端服务器发送一个请求，观察后端服务器处理的下一个请求似乎使用了 AAPOST 方法。

HTTP 请求走私，混淆 TE 标头

偷偷向后端服务器发送一个请求，观察后端服务器处理的下一个请求似乎使用了 AAAPOST 方法。

HTTP 请求走私，通过差异响应确认 CL.TE 漏洞

偷偷向后端服务器发送一个请求，观察下一个请求给出了 404 响应码。

HTTP 请求走私，通过差异响应确认 TE.CL 漏洞

偷偷向后端服务器发送一个请求，观察下一个请求给出了 404 响应码。

利用 HTTP 请求走私绕过前端安全控制，CL.TE 漏洞

向后端服务器发送一个请求并观察它是否可以访问管理面板

利用 HTTP 请求走私绕过前端安全控制，TE.CL 漏洞

向后端服务器发送一个请求并观察它是否可以访问管理面板

向后端服务器发送一个请求，观察它会删除一个用户。

利用 HTTP 请求走私来传递反射型 XSS

向后端服务器发送一个请求，观察下一个用户的请求会收到执行 XSS 负载的响应。

那么在以上的内容中我们也可以看到比较详细的攻击过程，包括HTTP请求走私漏洞利用和攻击的类型，那么这方面我们是需要实操才能真正的去理解这个漏洞的过程。

大概视频我后续会发出来，所以尽情期待叭！