提取用户提供的URL的安全风险

#1 楼

此特定漏洞确实有一个名称。它称为服务器端请求伪造（SSRF）。 SSRF是指用户可以使服务器端应用程序检索应用程序开发人员不需要的资源，例如内部网络上的其他网页，仅当从环回访问时才可用的其他服务（其他Web服务和API，有时是数据库）服务器），甚至服务器上的文件（file:///etc/passwd）。有关如何滥用它的示例，请参见SSRF圣经和PayloadsAllTheThings。由于它是图像标签，因此大多数情况下可能不会显示，但这仍然是要解决的问题。

该怎么办？您可以参考OWASP SSRF备忘单。您的情况与第二种情况相符，尽管您将无法执行所有缓解措施，例如将请求更改为POST或添加唯一令牌。否则，该指南可归纳为：




允许白名单的协议：允许HTTP和HTTPS，禁止其他所有内容（例如^https?://之类的正则表达式）。

检查所提供的主机名是否公开：IP地址库随附许多语言；检查目标主机名是否解析为非私有和非保留的IPv4或IPv6地址*。
我自己的自定义防火墙规则：运行Web应用程序的系统用户可能会绑定到限制性的防火墙规则，从而阻止所有内部网络请求和本地服务。在使用iptables / nftables的Linux上可以做到这一点。或者，容器化/分离应用程序的这一部分并将其锁定。

也许您还可以在检索时验证文件的MIME类型，以确保它是图像。另外，在获取图像时不要接受重定向，否则请不要对它们执行所有相同的验证。恶意的Web服务器可能只发送3xx响应，将您重定向到内部资源。

此外，您提到您正在根据用户输入的数据生成PDF。除了图像URL，PDF生成器在历史上一直是XXE（XML外部实体注入）和SSRF漏洞的温床。因此，即使您修复了自定义URL，也请确保您的PDF生成库避免了这些问题，或者您自己执行验证。 DEFCON讨论概述了该问题（PDF下载）。

*如评论中所述，DNS响应可能包含多个结果，并且响应可能在请求之间发生变化，从而导致检查时间的缩短。使用（TOCTOU）问题。要缓解，解析和验证一次，并使用最初验证的IP地址发出请求，请附加主机标头以允许访问正确的虚拟主机。

#2 楼

我们存储URL而不是图像。


此外，这会增加信息和隐私风险。让我通过可视演示进行展示。

如果您尝试将任何图像上传到StackExchange，您将注意到该图像由imgur.com托管。 SE服务器会获取图像，并将其副本上传到其专用服务器。

我将使用一个流行且无辜的模因进行实验。让我们从显示的以下URL开始：https://i.imgflip.com/2fv13j.jpg。请注意，我必须使用深层链接才能运行此演示。

我想使用StackExchange上传工具将其附加到此帖子。



让我们更深入地研究一下。请注意，该图像现在源自imgur.com而不是imgflip.com。如果两个网址的名称相似，请耐心等待。通过打开Developer工具，您可以看到图像的指向



隐私问题

当您仅链接任何http（s）时： //在线资源，您的浏览器将启动与该服务器的连接，并发送大量信息。在流量高的网站上，网站所有者获得了大量有关访问此Security SE页面的人的IP地址的信息，以及（如果启用）引荐链接和第三方cookie。考虑到默认情况下启用了第三方Cookie，如果滥用正确方法，这可能会泄露用户身份。

拥有我要上传到帖子的图像，StackExchange可以防止imgflip.com知道谁正在显示他们的图片。

，正如我们将在第二部分中看到的那样，在将来进行更改。

欺骗的风险

考虑到无论您努力部署静态的“首页式”简单网站，服务器始终会在每次请求时解释到远程资源的任何URL。尽管服务器可能以.jpg结尾，但服务器可能正在使用脚本语言来解释请求，最后选择要提供的内容。

现在，您已经配置了访问者的资料，有权选择要为他们实时显示的内容。以Uber-Greyball案为例，以现场欺骗为例。受欢迎的约会应用程序Tinder使用类似的软禁或灰名单技术


当局不知道，他们在应用程序中看到的一些数字汽车并不代表实际的汽车。他们能够称赞的优步司机也迅速取消了。这是因为Uber根据从应用程序收集的数据和其他方式为[...警官先生...]贴上了标签-本质上是将他们当做市政府官员。例如，服务器可以实现这样的逻辑：决定在何处提供无害的模因或不良内容，例如政治广告，基于用户的要求（提醒一些Cambridge Analytic-thing？）。没关系，URL永远都不会改变。 />

request for https://host.com/images/img1.png
if (request comes from any of
      StackExchange moderator or
      Automated content filter or
      Government enforcer or
      Anything you can imagine)
{
    decide to serve innocuous content
}
else if (request comes from a user you want to decept)
{
    decide to serve a targeted advertising or deceptive content somehow
}

看这张图片，看看实时过滤可能会发生什么。一个相同的URL，不同的用户看到不同的内容。感谢Lord Buckethead在政治上保持中立。



在同一URL上，我们现在可以提供与谁要求内容不同的内容。

由于这些原因，您必须考虑获取远程资源，以便获取有关带宽和磁盘空间限制的永久快照。

我不会在这里讨论有关1）保留EXIF标签和2）用您自己的编解码器重新编码图像以防止进一步的有效载荷攻击的问题。

评论

---

感谢您的惊人解释！

–亚历山大·法德耶夫（Alexander Fadeev）
20-04-28在11:10

---

#3 楼

用户可以提供图像的（自托管）URL，而不是上传图像。我们存储URL而不是图像。


您是说这种JPEG吗？

这是一个坏主意。首先，您每次使用图像时都必须检查其有效性。这需要时间。我假设该数据库被其他用户使用，并且您将无法控制为数据库的用户提供哪种恶意JPEG。您担心自己会收到恶意映像，但是您愿意让使用数据库的其他人也得到这样的恶意映像。 />对于您自己，请像对待来自不受信任来源的任何输入一样对待图像。这意味着：检查图像是否正确。您可能需要将其转换为某些标准格式；您可能需要重新编码才能确定。