我们正在考虑将以下功能添加到我们的 Web 应用程序（一个在线产品数据库，如果重要的话）：
到现在为止还挺好。但是，有时我们的 Web 应用程序必须从（外部、用户提供的）URL 中获取图像才能对其进行处理（例如，将图像包含在 PDF 产品数据表中）。
这让我很担心，因为这意味着我们的 Web 服务器将向用户提供的 URL 发送 HTTP 请求。我可以立即想到很多可以用这个来做的坏事（例如，通过输入http://192.168.1.1/...URL 并尝试一些常见的路由器 Web 界面漏洞利用）。这似乎类似于跨站请求伪造，只是不是网络服务器欺骗用户提交网络请求，而是用户欺骗网络服务器。
当然，我不是第一个面临这个问题的人。因此，我的问题：
这个特殊的漏洞确实有一个名字。它被称为服务器端请求伪造（SSRF）。SSRF 是指用户可以使服务器端应用程序检索应用程序开发人员无意中的资源，例如内部网络上的其他网页，仅在从环回访问时可用的其他服务（其他 Web 服务和 API，有时是数据库服务器），甚至服务器上的文件（file:///etc/passwd）。有关如何滥用它的示例，请参阅SSRF Bible和PayloadsAllTheThings 。由于它是一个图像标签，大多数东西可能不会显示，但它仍然是一个需要修复的问题。
该怎么办？您可以参考OWASP SSRF Cheat Sheet。您的情况与第二种情况相符，尽管您将无法执行所有缓解措施，例如将请求更改为 POST 或添加唯一令牌。否则，该指南可归结为：
^https?://）。iptables/是可能的nftables。或者，容器化/分离应用程序的这一部分并将其锁定。也许您还可以在检索时验证文件的 MIME 类型以确保它是图像。此外，在获取图像时不要接受重定向，或者如果接受，则对它们执行所有相同的验证。恶意网络服务器可能只会发送一个 3xx 响应，将您重定向到内部资源。
此外，您提到您正在从用户输入的数据生成 PDF。除了您的图像 URL，PDF 生成器在历史上一直是 XXE（XML 外部实体注入）和 SSRF 漏洞的温床。因此，即使您修复了自定义 URL，也要确保您的 PDF 生成库避免这些问题，或者自己执行验证。DEFCON 演讲概述了这个问题（PDF 下载）。
* 如评论中所述，DNS 响应可以包含多个结果，并且响应可能会在请求之间发生变化，从而导致检查时间使用时间 (TOCTOU) 问题。为了缓解、解决和验证一次，并使用最初验证的 IP 地址发出请求，附加主机标头以允许访问正确的虚拟主机。
我们存储 URL 而不是图像。
此外，这将增加信息和隐私风险。让我用一个视觉演示来展示。
如果您尝试将任何图像上传到 StackExchange，您会注意到该图像由 imgur.com托管。SE 服务器获取图像并将其副本上传到其私有服务器。
我将使用一个流行且无辜的模因进行实验。让我们从以下 URL 开始我们的节目：https://i.imgflip.com/2fv13j.jpg. 请注意，我必须使用深层链接才能使此演示正常工作。
我想使用 StackExchange 上传工具将它附加到这篇文章中。就像问题中的场景一样。
🔝 这是我们新上传的图片！
让我们更深入地调查。请注意，图像现在来自而imgur.com 不是来自。imgflip.com如果两个 URL 名称相似，请耐心等待。打开开发者工具，可以看到图片指向的位置
当您仅链接任何 http(s):// 在线资源时，您的浏览器将启动与该服务器的连接，并发送大量信息。在高流量网站上，网站所有者会获得大量有关访问此 Security SE 页面的人的 IP 地址的信息，以及（如果启用）推荐链接和第三方 cookie。考虑到默认情况下启用了第 3 方 cookie，如果以正确的方式滥用，这可能会泄露用户身份。
通过拥有我要上传到帖子的图片，StackExchange 可以防止 imgflip.com 知道谁在展示他们的图片。
而且，正如我们将在第二部分中看到的那样，在未来对其进行更改。
考虑一下，无论您如何努力部署一个静态的“首页式”简单网站，任何远程资源的 URL 总是由服务器在每次请求时解释。虽然它可能以.jpg服务器结束，但可能会使用脚本语言来解释请求，并最终选择要服务的内容。
既然您已经分析了您的访问者，您就可以选择为他们显示哪些内容，即直播。将 Uber- Greyball案视为现场欺骗的一个例子。流行的约会应用程序 Tinder 使用类似的软禁令或灰名单技术
[...] 当局不知道，他们在应用程序中看到的一些数字汽车并不代表实际车辆。他们能够招呼的优步司机也很快取消了。那是因为优步已经根据从应用程序和其他方式收集的数据标记了[...警察先生...] - 基本上将他们作为城市官员进行灰球化。
例如，服务器可以实现这样的逻辑：根据用户请求决定在哪里提供无害的 meme 或不受欢迎的内容，例如政治广告（提醒一些Cambridge Analytic-thing？）。Neverthles，URL 永远不会改变。
CA 声称的优势是拥有足够的关于每个美国人的数据点来建立广泛的个性档案，其客户可以利用这些数据进行广告的“心理定位”
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
}
查看这张图片，了解实时过滤可能会发生什么。同一个网址，不同的用户看到的内容不同。感谢 Buckethead 勋爵让自己在政治上保持中立。
在同一个 URL 上，我们现在能够提供与请求者不同的内容。
由于这些原因，您必须考虑获取远程资源以便对其进行永久快照，这与带宽和磁盘空间限制有关。
我不会在这里讨论 1) 保留 EXIF 标签和 2) 使用您自己的编解码器重新编码图像以防止进一步的有效负载攻击
用户可以提供图像的（自托管）URL，而不是上传图像。我们存储 URL 而不是图像。
你的意思是这类JPEG？
这是个坏主意。首先，每次使用时都必须检查图像的有效性。这需要时间。我假设该数据库被其他用户使用，您将无法控制为数据库用户提供什么样的恶意 JPEG。您担心自己会获得恶意图像，但您愿意让使用您的数据库的其他人获得这样的恶意图像。
所以，到目前为止还没有那么好。
对于您自己，请像对待来自不受信任来源的任何输入一样对待图像。这意味着：检查图像是否正确。您可能希望将其转换为某种标准格式；您可能需要重新编码以确定。