在此模型中，攻击者和用户都以相同级别的权限开始（非特权网络位置 - 上图左侧），这直接影响暴露的攻击面。这些参与者可以直接与之交互（或攻击）的唯一服务是具有公共和私有 IP 地址的 nginx 实例。还值得指出的是，由于暴露的 nginx 实例使用 vHosts，外部各方也能够与 、 和 服务进行交互www，app尽管link不能直接与机器交互。无论如何，攻击者无法有效控制与 IAM、Redis、Widget 服务和两个 MySQL 实例的交互。
但想象一下，这不是真的。想象一下，作为攻击者，您能够直接与这些服务和系统中的任何一个对话。也许，而且通常情况下，这些内部服务也没有得到保护；这些系统的安全性优先于周边的安全性。对于任何攻击者来说，这将是一个现场日。
在这一点上，我们的故事可能会发生分歧：我们可以讨论 vhost 服务和 nginx 之间对 HTTP 标准的解释差异如何导致 Request Smuggling 漏洞。我们还可以讨论如何从存储在一个服务中并由另一个服务处理的数据中产生二阶 SQLi。我们甚至可以通过注入查询参数破坏字符来讨论针对内部 HTTP 请求的攻击，例如引入新参数或截断它们#。&但是，我想讨论一下 SSRF 如何适应这张图片。
什么是 SSRF？
SSRF 或服务器端请求伪造是一个漏洞，攻击者能够引导处于特权网络位置的系统向另一个具有特权网络位置的系统发出请求。
请记住粗体部分：绝对需要支持攻击者可以引导处于特权网络位置的服务向处于非特权网络位置的系统发出请求的功能。一个完美的例子是Github 或 Dropbox 上的webhook 功能。能够将 webhook 指向您的 burp 协作者实例并不是一个漏洞。
当然，每条规则都有例外。我使用上面这个更严格的定义来帮助将最常见的 SSRF 和人造 SSRF 实例引导到它们各自的确定：有效或无效。举个例子：我曾经遇到过这样一种情况，即能够在没有特权网络位置的情况下将地址更改为攻击者控制的机器，这使我能够读取Authorization标头并窃取内部 api 调用中使用的凭据……所以请注意这一点盐。
查找 SSRF 的典型特征或位置是某些参数包含 url 或域作为值。看到如下的 POST 请求
POST /fetchPage HTTP/1.1
主机：app.example.com
...
内容类型：application/x-www-form-urlencodedurl=http%3A%2F%2Ffoobar.com%2fendpoint
这是一个非常明显的迹象，表明这是一种可能会引入 SSRF 漏洞的功能。还有一些其他类型的功能，例如 HTML 到 PDF 生成器，其中在特权网络位置使用无头浏览器或类似功能来生成预览或 PDF。如果您对这些类型的攻击媒介感到好奇，请阅读Daeken 和 Nahamsec为 DEFCON 制作的幻灯片。
事实上，任何你可以控制另一个系统的地址的地方都是你应该尝试测试 SSRF 的地方。从技术上讲，即使是HOST 标头也可能是易受攻击的参数。
如果它像鸭子一样走路和像鸭子一样说话......
我最初并不打算将这篇博文作为“如何测试 SSRF”指南（其中有很多） ，但是当我为材料绘制大纲时，我觉得我至少应该涵盖一些我在测试 SSRF 时寻找的行为或特征。
我通常对以下问题感兴趣：
我可以阅读回复吗？
我可以阅读回复吗？如果没有，是否根据接收系统的可用性向我提供了任何其他信息？如果端口未打开，是否会返回错误？如果系统不使用 HTTP 但正在接收流量，会发生什么？
如果我可以读取响应，那么证明影响是轻而易举的：我们只需要识别一个内部服务，它响应我们可以访问的任何协议并从中读取响应。如果我们无法读取响应，我们可能必须想出有趣的辅助通道，例如不同的错误消息，或者看看我们是否可以盲目地强制内部服务向 Internet 发出请求。
我们在哪？
易受攻击的服务是在某些基础设施即服务 (IaaS) 平台（如 AWS 或 GCP）上运行，还是我们在不太复杂或更定制的东西上运行？这让我知道我是否能够访问元数据服务，并可能让我了解内部网络中可能运行的系统类型。
我可以重定向吗？
这很简单。重定向的规则是什么？他们总是被拒绝吗？他们总是被处理吗？还是两者之间有一些细微差别？
重定向是绕过 SSRF 缓解措施的一种非常常见的方法。有时，Web 应用程序会检查初始域是否解析为 RFC1918 地址，如果是，则会出错。这些类型的检查通常只在初始请求上执行，并且可以利用 302 重定向来告诉客户端转向内部网络。但是，请注意这些内部 HTTP 客户端前面的代理，因为它们可以正确识别是否应将请求转发到其目的地。
客户端支持哪些协议？
仅 HTTP/HTTPS？FTP？地鼠？？支持其他协议（尤其是 Gopher）将提高影响级别和可供您使用的利用选项。
请记住创造性地思考如何证明您能够成功地与内部系统进行交互。当然，当您可以读取响应时，这会容易得多，但是如果您能够通过侧通道提供此类信息，例如端口被过滤/阻塞时的错误，或者您能够让该服务进行交互由于您的特权消息与外界联系，那么您将更成功地证明 SSRF 的存在。
为了获得灵感，我最喜欢的证明我拥有 SSRF 的方法之一是利用 localhost smtp 服务来证明我能够触发系统向我发送电子邮件。这是我在 HackerOne SSRF 报告中使用过两次的方法。
最后，远离 HTTP 和 HTTPS 协议可以让您绕过前面提到的代理。通常这些代理只处理 HTTP 或 HTTPS 流量，因此能够使用像 Gopher 这样的协议可以让您完全绕过内部代理。
SSRF 和在哪里可以找到它们
如前所述，SSRF 可以出现在系统可寻址字符串出现的任何地方（IP、域名、电子邮件地址等）。虽然我可以开始列举所有可能成为 SSRF 的特征（但仍然错过了大量可能的示例），但我认为更好的学习方法是阅读其他人发现的故事并尝试推断其他类似的攻击向量。
故事 1 — Duck Duck Gopher
（此报告是公开的，请点击此处阅读）
这个故事开始于 2018 年 10 月中旬：我的寻虫生涯的早期阶段。我收到了一位朋友对我收到的任天堂新私人计划邀请的建议（现在是公开的）。我花了好几个小时进行黑客攻击，试图找到任何有趣但又难以取得进展的东西。在几个小时不成功后，我最终放弃了。在关闭它并上床睡觉之前，我将在 Burp Suite 中简要查看我的 HTTP 历史记录。就在那时，我注意到一个请求飞过，这似乎好得令人难以置信。
此时我将 DuckDuckGo 配置为我在 Chrome 中的默认搜索引擎（虽然，不可否认，我几乎总是打开谷歌；隐私保护就这么多¯\_(ツ)_/¯）。有一次，我不小心向 DuckDuckGo 提交了一个搜索查询，并且 burp 拦截了该页面发出的所有请求。引起我注意的是一个请求https://duckduckgo.com/iu。此请求有一个名为的查询参数url，只要该参数包含一个域名为yimg.com
但是，当您尝试其他域时，google.com您会遇到一个错误，表明他们正在执行某种过滤以拒绝对其他域的请求。请注意403 Forbidden此响应中的 与200 OK上述相反。
凭直觉，我决定看看这个服务是否真的在解析白名单的 url，或者他们是否只是在使用string.contains燃料检查。果然，这就是我绕过过滤器并开始调查可能的 SSRF 行为所需的全部内容。
如上所述，我想调查的一些事情是客户端重定向的能力，并在可能的情况下识别它支持的其他协议。
在测试重定向行为后，我确实注意到重定向受到尊重。我将 DuckDuckGo 指向一个端点，该端点将以 302 重定向响应到 burp 协作者实例，并确认重定向有效。之后，我通过在重定向gopher的标头中使用该协议来检查该协议是否受支持。Location该gopher协议将允许我在内部与更多服务进行对话，因此了解该客户端是否支持它（并增加此发现的严重性）很有用。
我能够使用这个 SSRF 执行端口扫描，并发现了许多在 localhost 上运行的服务。其中一项服务在端口 6868 上是 Redis，它在被 HTTP 访问时实际上正在返回一些数据。返回的 json 提到了一个似乎只能在内部解析的域。现在，有了这个 SSRF，我将能够对该服务进行端口扫描并开始识别我可以与之通信的服务。
这是一个图表，可以帮助展示我们在这次攻击中所处的位置。
最终，我注意到端口8091已打开cache-services.duckduckgo.com并正在返回大量数据。我比这早一点开始使用 DuckDuckGo 进行报告，但想看看我还能做些什么来增加影响（和学习）。大约在这一点上，我停止了对目标的攻击，并称之为一天。
后果
不幸的是，DuckDuckGo 不为错误付费，但他们确实提供了一些东西。我最终得到了一件 DuckDuckGo T 恤，一个非常棒的故事，以及一个我非常自豪的公开披露。
故事 2— 在 ursmtp 中
我被邀请参加一个我不抱太大希望的私人项目。这是一种感觉可以被市场上任何其他CRUD 应用程序取代的服务。据我所知，它并没有真正提供太多有趣的行为方式，我对此感到非常厌烦。虽然该范围确实有一个*.允许的域，但我并没有发现太多有趣的东西。
最终，我发现了一个允许用户更新其帐户信息的功能。您可以填写的字段之一是您的个人网站地址（类似于 Twitter 上的地址）。一个有趣的行为是，如果该网站不存在或由于某种原因无法访问，该字段将变为黄色。如果该站点确实存在，该字段将变为绿色。
网站不存在 vs 网站确实存在这种反馈机制让我意识到这不仅仅是一个简单的 CRUD 应用程序，而且该服务必须向指定地址发出 HTTP 请求。我输入了一个 Burp 合作者地址来确认，果然我看到了一个请求。
我能够使用反馈机制执行本地端口扫描，并在网上找到了许多服务：SSH、SMTP、DNS 以及其他一些我无法通过端口识别的服务。为了证明这里的影响，我最终执行了一组与 DuckDuckGo 类似的测试：我检查了重定向和 gopher 行为，很幸运地发现两者都可用。
现在我有了 gopher，我可以通过在 gopher 中制作 SMTP 消息并在localhost:25. 果然，片刻之后，我的收件箱中出现了一封新电子邮件。
后果
我因这一发现获得了 800 美元的奖金，并获得了 3 级的评级high。
故事 3——CMSSRF
我被邀请参加一个最近开放的私人项目。如果您从未被邀请参加过刚刚开放的程序，那么您可能不会意识到您会得到这种“水中的鲜血”的感觉：您知道 您所有的黑客伙伴和朋友也获得了邀请将在接下来的几个小时内开始撕毁这个程序，如果你不想错过任何低垂的果实，你需要快点。
我决定不查看核心域而是跳转到有趣的子域来开始我的过程。我运行sublist3r并发现了他们的域名中提到的几个子cms域。以我的经验，cms服务往往有很多问题，这可能是一个值得一看的好地方。我在这个资产的主页上没有找到太多东西，所以我跑去dirsearch看看这个资产上是否隐藏着任何有趣的东西。
果然，在敲击资产大约 15 分钟后，我发现了一个端点，它提到了一些关于它的内容user management，它将 302 发送到另一个端点。该端点有一个用于某些管理系统的登录页面。更重要的是，有一些 javascript 文件引用了该资产的 API。
在发现该qa资产的子域具有未混淆的 javascript 后，我能够弄清楚如何调用 api 以及我可以使用哪些调用。其中一个调用被命名并在 POST 正文中采用了一个参数。createWebRequesturl
在我的黑客攻击中，我已经知道这个资产在 AWS 上运行，所以我立即尝试向这个 api 端点发出请求以获取 AWS 元数据 IP 地址。果然，我们成功了。
当我在aws cli客户端尝试 AWS 密钥时，我发现我对数十个 S3 存储桶、数十个 EC2 实例、Redis 等的访问级别达到了荒谬的程度。这在任何意义上都是至关重要的。
后果
我得到了 3,000 美元（最高支出），报告被标记为critical.
故事 4——经过身份验证的请求
这是我最近的 SSRF 的故事，并且在某种程度上，是我发现的最有趣的 SSRF。我开始破解我被邀请参加的这个新的私人程序。我开始关注核心资产的问题。此时我发现了一对存储的 XSS，心情非常好。当我查看我打开的 burp collaborator 实例时，我正要结束购物。我所看到的会让我大吃一惊。
顺便说一句：当我注册我要破解的服务时，我做的一件事是我使用 burp collaborator 实例来查看电子邮件。在我完成对服务的黑客攻击后，这对我来说是一种不让烦人的广告污染我的电子邮件帐户的好方法，它还可以让我看看事后是否发生了任何有趣的事情。
无论如何，当我查看 burp collaborator 时，我注意到它收到了一个 HTTP 请求，User-Agent其中提到了我正在攻击的服务。我心想，“我是不是偶然发现了一个容易受到 SSRF 攻击的功能？！”。我开始想办法再次触发它。
好吧，将请求的时间表放在一起清楚地解释了发生的事情。我刚刚通过电子邮件注册了这项服务，user@abc123.burpcollaborator.net几秒钟后收到了 SMTP 消息（电子邮件）和主页的 HTTP 请求。
我再次注册了一个电子邮件地址，想user@1.2.3.4.xip.io看看我是否可以检查 302 行为是否得到尊重。在我的 burp collaborator 实例中接收到转发的请求后，我想确认 gopher 工作正常，因为我注意到这个请求是由 Squid Proxy 处理的（这可能会阻止我访问内部网络的尝试）。
与之前的故事类似，我检查了 302 重定向上的 gopher 协议，并注意到我能够使用它与内部服务进行交互。不幸的是，没有任何形式的反馈，所以我无法在这里执行端口扫描。无论如何，我决定尝试本地主机 smtp 消息，看看我是否能走运。
果然，在制作了一条消息并执行了攻击之后，我在收件箱中收到了一封新电子邮件，证明这个 SSRF 是真实且危险的。
后果
好吧，与以前的故事不同，我还没有因为这个发现而得到报酬。好消息是我的报告已被分类，high所以我只是在等待对支付的最终决定。我可能会在我的 Twitter 上发布它（如果你还没有的话，你应该去关注它）。
故事 5 — 拥有影响力
我希望我可以说这个故事的灵感来自Nahamsec 和 Daeken 在 Defcon 上的 SSRF 演讲，但我在他们的演讲发布大约一年前发现了这一点。我正在为一家金融领域的公司开发一个新程序。这是我以前从未见过（或听说过）的产品，并且大量参与了分析。其中一项功能允许您上传图像并存储它们以用于产品中的其他几个功能。
当然，我想在这里执行的测试之一是“我可以上传 HTML”，如果可以，“如果该 HTML 获取外部资源会发生什么”？
我尝试上传 HTML 文件，但发现服务拒绝了上传。我试图看看我是否可以通过将分段上传中的内容类型更改为“说image/jpeg”并确定它上传了文件很好。
在向其他端点发出请求以更新文档状态后，它将触发内部渲染器/浏览器向attacker.com.
在这种情况下，我会做更多的工作来证明影响力，但在这种情况下很明显，这是超级意外的，如果我有一个地址可以访问，我就可以访问内部系统。我最终报告并获得了赏金。
后果
我为这一发现获得了 1,000 美元的补偿，它被评为中等。回想起来，我应该做更多的事情来看看我是否可以证明额外的影响。我觉得那会让我得到比我更高的补偿。
包起来
SSRF 是我最喜欢的 bug 类，因为它执行简单、难以缓解，并且 SSRF 表现形式的疯狂数量（我什至听说过使用 FTP 触发它的方法）。能够与私人内部网络进行交互对我来说非常有吸引力，我希望在阅读了这篇文章和其中的故事之后，你会感到更有能力去发现和探索为现代世界提供动力的难以访问的网络。
大喊大叫
他的Piercing the Veil帖子启发了我，甚至一开始就开始寻找并着迷于 SSRF。