共计 4705 个字符，预计需要花费 12 分钟才能阅读完成。
Server-side request forgery (SSRF)
在本节中，咱们将解释 server-side request forgery（服务端申请伪造）是什么，并形容一些常见的示例，以及解释如何发现和利用各种 SSRF 破绽。
SSRF 是什么
SSRF 服务端申请伪造是一个 web 破绽，它容许攻击者诱导服务端程序向攻击者抉择的任何地址发动 HTTP 申请。
在典型的 SSRF 示例中，攻击者可能会使服务端建设一个到服务端本身、或组织基础架构中的其它基于 web 的服务、或内部第三方零碎的连贯。
SSRF 攻打的影响
胜利的 SSRF 攻打通常会导致未经受权的操作或对组织外部数据的拜访，无论是在易受攻击的应用程序自身，还是应用程序能够通信的其它后端系统。在某些状况下，SSRF 破绽可能容许攻击者执行任意的命令。
利用 SSRF 破绽可能能够操作服务端应用程序使其向与之连贯的内部第三方零碎发动歹意申请，这将导致潜在的法律责任和名誉受损。
常见的 SSRF 攻打
SSRF 攻打通常利用服务端应用程序的信赖关系发动攻打并执行未经受权的操作。这种信赖关系可能包含：对服务端本身的信赖，或同组织内其它后端系统的信赖。
SSRF 攻打服务端本身
在针对服务端自身的 SSRF 攻打中，攻击者诱导应用程序向其本身收回 HTTP 申请，这通常须要提供一个主机名是 127.0.0.1 或者 localhost 的 URL。
例如，假如某个购物应用程序，其容许用户查看某个商品在特定商店中是否有库存。为了提供库存信息，应用程序须要通过 REST API 查问其余后端服务，而其余后端服务的 URL 地址间接蕴含在前端 HTTP 申请中。因而，当用户查看商品的库存状态时，浏览器可能收回如下申请：
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1这将导致服务端向指定的 URL 发出请求，检索库存状态，而后将后果返回给用户。
在这种状况下，攻击者能够批改申请以指定服务器本地的 URL，例如：
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin此时，服务端将会拜访本地 /admin URL 并将其内容返回给用户。
当然，攻击者能够间接拜访 /admin URL，然而这通常没用，因为治理性能根本都须要进行适当的身份验证，而如果对 /admin URL 的申请来自机器本地，则失常状况下的访问控制可能会被绕过。该服务端应用程序可能会授予对治理性能的齐全拜访权限，因为申请仿佛来自受信赖的地位。
为什么应用程序会以这种形式运行，并且隐式信赖来自本地的申请？这可能有多种起因：
- 访问控制查看可能是另外的一个微服务。当服务器连贯本身时，将会绕过访问控制查看。
- 出于劫难复原的目标，应用程序可能容许来自本地机器的任何用户在不登录的状况下进行治理拜访。这为管理员在失落凭证时复原零碎提供了一种办法。这里的假如是只有齐全可信的用户能力间接来自服务器本地。
- 治理接口可能与主利用是不同的端口号，因为用户可能无奈间接拜访。
在这种信赖关系中，来自本地机器的申请的解决形式与一般申请不同，这经常使 SSRF 成为一个重大的破绽。
针对其余后端系统的 SSRF 攻打
SSRF 利用的另外一种信赖关系是利用服务端与用户无奈间接拜访的外部后端系统之间进行的交互，这些后端系统通常具备不可路由的专用 IP 地址，因为受到网络拓扑构造的爱护，它们的安全性往往较弱。在许多状况下，外部后端系统蕴含一些敏感性能，任何可能与零碎交互的人都能够在不进行身份验证的状况下拜访这些性能。
在后面的示例中，假如后端系统有一个治理接口 https://192.168.0.68/admin。此时，攻击者能够通过提交以下申请利用 SSRF 破绽拜访治理接口：
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin躲避常见的 SSRF 进攻
通常应用程序蕴含 SSRF 行为以及避免歹意攻打的进攻措施，然而这些进攻措施是能够被躲避的。
基于黑名单过滤的 SSRF
某些应用程序禁止例如 127.0.0.1、localhost 等主机名、或 /admin 等敏感 URL。这种状况下，能够应用各种技巧绕过过滤：
- 应用
127.0.0.1的代替 IP 地址示意，例如2130706433，017700000001，127.1。 - 注册本人的域名，并解析为
127.0.0.1，你能够间接应用spoofed.burpcollaborator.net。 - 应用 URL 编码或大小写变动来混同被阻止的字符串。
基于白名单过滤的 SSRF
有些应用程序只容许输出匹配、或蕴含白名单中的值，或以白名单中的值结尾。在这种状况下，有时能够利用 URL 解析的不统一来绕过过滤器。
URL 标准蕴含有许多在实现 URL 的解析和验证时容易被疏忽的个性：
- 你能够在主机名之前应用
@符号嵌入凭证。例如https://expected-host@evil-host。 - 你能够应用
#符号示意一个 URL 片段。例如https://evil-host#expected-host。 - 你能够利用 DNS 命令层次结构将所需的输出放入你管制的规范 DNS 名称中。例如
https://expected-host.evil-host。 - 你能够应用 URL 编码字符来蛊惑 URL 解析代码。如果解决 URL 编码的过滤器的实现不同与执行后端 HTTP 申请的代码，这一点尤其有用。
- 你能够把这些技巧联合起来应用。
通过凋谢重定向绕过 SSRF 过滤器
有时利用凋谢重定向破绽能够绕过任何基于过滤器的进攻。
在后面的示例中，假如用户提交的 URL 通过严格验证，以避免歹意利用 SSRF 的行为，然而，容许应用 URL 的应用程序蕴含一个凋谢重定向破绽。如果用于发动后端 HTTP 申请的 API 反对重定向，那么你能够结构一个满足过滤器的要求的 URL，并将申请重定向到所需的后端指标。
例如，假如应用程序蕴含一个凋谢重定向破绽，例如上面 URL 的模式：
/product/nextProduct?currentProductId=6&path=http://evil-user.net重定向到：
http://evil-user.net你能够利用凋谢重定向破绽绕过 URL 过滤器，并利用 SSRF 破绽进行攻打，如：
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin这个 SSRF 攻打之所有无效，是因为首先 stockAPI URL 在应用程序容许的域上，而后应用程序向提供的 URL 发动申请，触发了重定向，最终向重定向的外部 URL 发动了申请。
Blind SSRF – 不可见 SSRF 破绽
所谓 Blind SSRF（不可见 SSRF）破绽是指，能够诱导应用程序向提供的 URL 发动后端 HTTP 申请，然而申请的响应并没有在应用程序的前端响应中返回。
不可见 SSRF 破绽通常较难利用，但有时会导致服务器或其余后端组件上的近程代码执行。
寻找 SSRF 破绽的暗藏攻击面
许多 SSRF 破绽之所以绝对容易发现，是因为应用程序的失常通信中就蕴含了残缺的 URL 申请参数。而其它状况就比拟难搞了。
申请中的局部 URL
有时应用程序只将主机名或 URL 门路的一部分放入申请参数中，而后，提交的值被合并到服务端申请的残缺 URL 中。如果该值很容易被辨认为主机名或 URL 门路，那么潜在的攻击面可能很显著。然而，因为你不能管制最终申请的 URL，所以 SSRF 的可利用性会受到限制。
数据格式内的 URL
有些应用程序以某种数据格式传输数据，URL 则蕴含在指定数据格式中。这里的数据格式的一个显著的例子就是 XML，当应用程序承受 XML 格局的数据并对其进行解析时，可能会受到 XXE 注入，进而通过 XXE 实现 SSRF 攻打。无关 XXE 注入破绽会有专门的章节解说。
通过 Referer 头的 SSRF
一些应用程序应用服务端剖析软件来跟踪访问者，这种软件常常在申请中记录 Referer 头，因为这对于跟踪传入链接特地有用。通常，剖析软件实际上会拜访 Referer 头中呈现的任何第三方 URL。这通常用于剖析援用站点的内容，包含传入链接中应用的锚文本。因而，Referer 头通常是 SSRF 破绽的无效攻击面。无关波及 Referer 头的破绽示例请参阅 Blind SSRF。
Blind SSRF
在本节中，咱们将解释什么是不可见的服务端申请伪造，并形容一些常见的不可见 SSRF 示例，以及解释如何发现和利用不可见 SSRF 破绽。
什么是不可见 SSRF
不可见 SSRF 破绽是指，能够诱导应用程序向提供的 URL 收回后端 HTTP 申请，但来自后端申请的响应没有在应用程序的前端响应中返回。
不可见 SSRF 破绽的影响
不可见 SSRF 破绽的影响往往低于齐全可见的 SSRF 破绽，因为其单向性，尽管在某些状况下，能够利用它们从后端系统检索敏感数据，但不能轻易地利用它们来实现残缺的近程代码执行。
如何发现和利用不可见 SSRF 破绽
检测不可见 SSRF 破绽最牢靠的办法是应用 out-of-band（OAST）带外技术。这包含尝试触发对你管制的内部零碎的 HTTP 申请，并监督与该零碎的网络交互。
应用 OAST 技术最简略无效的形式是应用 Burp Collaborator(此性能须要付费)。你能够应用 Burp Collaborator client 生成惟一的域名，将这个域名以无效负载的模式发送到检测破绽的应用程序，并监督与这个域名的任何交互，如果察看到来自应用程序传入的 HTTP 申请，则阐明应用程序存在 SSRF 破绽。
留神：在测试 SSRF 破绽时，通常会察看到所提供域名的 DNS 查找，然而却没有后续的 HTTP 申请。这通常是应用程序视图向该域名收回 HTTP 申请，这导致了初始的 DNS 查找，但理论的 HTTP 申请被网络拦挡了。基础设施容许出站的 DNS 流量是绝对常见的，因为出于很多目标须要，然而会阻止到意外目的地的 HTTP 连贯。
简略地辨认一个能够触发 out-of-band 带外 HTTP 申请的不可见 SSRF 破绽自身并没有提供一个可利用的路径。因为你无奈查看来自后端申请的响应，因而也无奈得悉具体的内容。然而，它依然能够用来探测服务器自身或其余后端系统上的其余破绽。你能够自觉地扫描外部 IP 地址空间，发送旨在检测已知破绽的无效负载，如果这些无效负载也应用带外技术，那么您可能会发现外部服务器上的一个未修补的重大破绽。
另一种利用不可见 SSRF 破绽的办法是诱导应用程序连贯到攻击者管制下的零碎，并将歹意响应返回到进行连贯的 HTTP 客户端。如果你能够利用服务端 HTTP 实现中的重大的客户端破绽，那么你兴许可能在应用程序基础架构中进行近程代码执行。
