我们如何发现 SSRF 漏洞
首先，我们创建了一个新的数字孪生服务——
接下来，我们点击“打开 Azure 数字孪生资源管理器”：
重要说明：远程攻击者无需创建数字孪生资源即可利用此 SSRF。我只是为了这个博客的目的而创建一个。远程用户可以在没有来自任何服务器的任何授权或身份验证的情况下访问端点（我将在后面进一步演示）。
以下弹出警报表示在 Azure 门户中找不到我们的资源。我将点击“关闭”暂时忽略它。正如稍后将解释的那样，即使该服务提醒我们我们没有通过 Azure 门户创建有效的服务，我们仍然能够滥用 SSRF 漏洞。
接下来，我们点击3D 场景按钮：
我们注意到在幕后发送了以下请求：
响应如下：
正如上面的屏幕截图中突出显示的那样，我们注意到以下有趣的点：
• 这是一个基于Express 的应用程序。
• /proxy/blob具有各种查询参数的端点。
• 名为X-Blob-Host 的新标头设置为未定义。
• 内部服务器错误500 揭示了应用程序的各种依赖项和文件。
为了证明滥用 SSRF 功能的概念，我们可以删除除X-Blob-Host和X-ms-Version之外的所有标头。
正如本博客开头所述，由于验证存在漏洞，我们可以修改标头以查看下一个输出是什么。
我们发送了以下请求：
并收到此回复：
我们可以看到，通过提供示例 blob，正在向端点发出请求(getaddrinfo) ，这意味着它确实在检查：
知道这一点后，我们尝试使用精心设计的负载向服务器发送以下请求：
以下是请求以及收到的响应：
从上面的屏幕截图中，您可以看到我们成功地使用主域 IP 地址 (104.45.84.81) 将请求回调到我们的 Collaborator。
正如上面的重要说明中提到的，虽然工作流是在通过 UI 创建数字孪生服务之后启动的，但通过进入数字孪生资源管理器而不通过 Azure 门户，相同的工作流可以更短，这意味着相同的有效负载可以也可以通过 Explorer UI 发送，无需任何身份验证。
然后我们直接进入 3D 场景端点，并收到以下内容：
在查看 Github 中与数字孪生服务相关的各种文件后，我们发现文件BlobAdapter.ts中的设置似乎配置错误，该文件位于以下端点 -
存储库：
https://github.com/microsoft/iot-cardboard-js/blob/d23f87f532182527766f1516ba25870a8175f31e/src/Adapters/BlobAdapter.ts
有两个主要有趣的点——
从上面的截图我们可以看出：
1) blobHostUrl设置为用户在请求标头中设置的任何内容(req.headers['x-blob-host'])
2) 服务然后验证BlobHostUrlObject标头是否以后缀结尾：blob.core.windows.net
由于blobHostUrl可以被操纵，远程攻击者随后可以制作以 SSRF 结尾的请求。
请注意，此用例有一些限制：
来自任何所需远程主机的响应都应采用特定的响应内容类型，即 Json。
使用的端口必须是 443。
完整端点必须采用以下格式“ https://[remote_host]/.blob.core.windows.net/ ”