带有实际示例的安全性总是很有趣。
今天，我们将讨论SSRF攻击，当您可以强制服务器通过img标签向互联网发出任意请求时。
因此，我最近同时参与了两个项目的渗透测试，其中两个漏洞已被揭示。 屏幕截图直接从报告中获取，因此抹去了所有不必要的信息。
攻击说明
攻击名称：服务器在生成PDF文档期间向Internet发出任意请求。
说明： PDF是在服务器端从具有所有外部资源的完全呈现的html页面生成的。 这些文档包含用户输入的数据。 如果没有适当的过滤，则可以在服务器渲染中替换外部资源。 在这种情况下，将其设为
it-band.by/10gb.blob文件（大小为10 Gb）。
最坏的情况：- 当系统需要下载100 GB的数据进行渲染以便一次渲染多个PDF文档时，Ddos会从内部发起攻击。 结果，这导致网络或内存资源不足，进而导致系统停机。
- 恶意用户可以将服务器用作攻击其他资源的平台。
- 恶意用户绕过Web应用程序防火墙（WAF）和平衡器，获取内部服务器的外部IP地址以进行直接攻击。
风险评估（可能性*影响）：中（5）*高（7）=高（35）（在两个系统中，风险的等级都很高，尽管比率不同）
有趣的是：- 一个系统使用wkhtmltopdf渲染html2pdf，第二个系统运行Firefox，在该页面加载页面并截屏。 无论如何，两个系统都会立即渲染两个页面，在该页面上执行所有代码，然后再从中制作PDF。
- XSS服务器保护已安装在两个系统上，但是两个系统都没有使用输入数据转义，而是使用html净化，清除了所有iframe，脚本，css，表单等。 但是在两个系统中的HTML净化都被认为是
img src="https://it-band.by/10Gb.blob?t=12345.1"/安全的html代码。
现在查看步骤和屏幕截图
1）在本地制作这样的文件，以尝试稍后完全或部分填充它。
2）首先，您需要找到易受攻击的用户字段。
系统1.仅插入一个img标签失败
系统2。我设法立即插入了大约20个标签
3）接下来，我们生成PDF文档。
系统1.生成的PDF
系统2.生成的PDF
4）现在，我们爬到服务器上，查看是否有对我们的10Gb.blob大文件的请求。
系统1.我们获得了用于生成PDF文档的服务器IP地址和软件，nmap通过找到的IP地址显示了另一个未曾见过的开放端口。
系统2。可以看出该服务器尝试下载20个10 GB的文件。 我们还将获得其中一台服务器的地址和所使用的Firefox版本。
结果。 在两个系统中，错误均已修复。 在第一个系统中，在处理用户数据期间和在生成PDF文档期间都进行了转义，而不是进行html纯化。 在第二个系统中，到外部资源的任何绝对链接都会在用户数据处理过程中被切断。
已更新。
当我到达该文章的发布时，添加了来自其他2个系统的案例。另一个系统（让我们称为系统3）没有一次在两个地方通过这种类型的漏洞检查：通过HTML注入和CSS注入。
系统3.进行HTML注入，并下载20次实时图像13 Mb（总计260Mb）
系统3. CSS注入
系统3.呈现PDF时，我们会在攻击服务器上看到什么（成功完成13Mb图片的所有20次下载）
系统3的输出是什么：1）获得了渲染服务器的地址以及它们用于渲染的地址。 在这种情况下，为HeadlessChrome。
2）生成一个PDF文档大约需要5分钟，然后铬就掉了。 想象一下，如果您运行10K此类请求，则原则上一段时间后，生成服务器将停止响应其他用户的请求。
系统 4。SSRF攻击不是通过img标签而是通过XSS进行的，当时我最喜欢的有效负载是在渲染期间在服务器上执行的，并且服务器在生成PDF文档时启动了任意Javascript代码。 与以前的情况相比，可以对其他系统进行更复杂的攻击。
系统4.在服务器端执行带有任意JS代码的PDF呈现
前提1.系统不仅需要开发传入防火墙的规则，还需要开发传出防火墙的规则，或者开发具有单独网段或服务器的基础架构，而这些网络通常无法访问外部。
前提2.即使发现最小的漏洞，也必须始终寻找最坏的情况来使用它并影响业务。 业务只能承受风险，但不幸的是，技术方面对他们没什么兴趣。
以上信息仅出于教育和教育目的而提供，无需进行系统设置。
Denis Koloshko，CISSP，渗透测试仪