未经许可，不得转载。
正文
Azure API管理包括三个主要组件：API网关、管理平面和开发者门户。这些组件默认由Azure托管并完全管理。Azure API管理可实现数字化体验、简化应用程序集成，支持新的数字产品，并促进数据和服务的重复使用与广泛访问。
创建一个新的 API 管理服务：
创建服务后，转到主服务页面并查看正在发送的各种请求：
其中，较为特殊的请求为：
上图中，由于API管理开发者门户尚未分配，因此Ocp-Apim-Url默认为null/internal-status-0123456789abcdef
将url参数修改为https://www.ifconfig.me，回显当前服务器 IP：
同时，Burp Collaborator可接受服务器回调：
从以上两个例子看出，Ocp-Apim-Url为SSRF的关键点，因为我们可以发送任意的请求。
知晓漏洞点后，即可进行进一步利用。
漏洞利用
IMDS运行于169.254.169.254上，提供有关当前正在运行的虚拟机实例的信息，但经过尝试，无法访问 IMDS。
因此我们枚举了内部127.0.0.1的端口：
枚举过程如下：
发现开放端口：
下图为示例响应包：
本文主要分享 30005 端口的测试过程，其URL为https://apimanagement-cors-proxy-prd.scm.azure-api.net/
通过浏览器（外部方式）访问可证实这一点：
通过服务器（内部方式）访问也可证实这一点：
不同之处在于，SSRF 漏洞从服务器内部发送请求，才可获取敏感信息。
由于这是一个Kudu Git服务器，可以推测它使用 Git 客户端从门户上传和保存各种部署。
因此，尝试使用git-upload-pack命令获取 Git 对象数据，回显如下：
同理，尝试向远程存储库发送请求以列出 refs：
1、
2、
总而言之，我们能够检索 Git 客户端版本、空的 refs 列表和不同的git-scm功能。
接下来，有几种进一步利用的可能性：
1、尝试上传远程仓库
2、枚举Kudu SCM服务器内的各种敏感文件。
原文出处： https://orca.security/resources/blog/ssrf-vulnerabilities-azure-api-management/
