服务器端请求伪造
当用户能够使应用程序向攻击者确定的域发出 HTTP 请求时，就会出现服务器端请求伪造漏洞。如果应用程序可以访问私有/内部网络，则攻击者还可能导致该应用程序向内部服务器发出请求。
我们将通过一些例子来仔细研究这个问题，以更好地理解它在运行中的样子。
假设一个 API，它从用户那里获取一个 URL 并生成用户提供的网址的图片，例如用于预览或导出页面。
ts
让 url = request.params.url;
让响应 = http.get (url);
let render = response.render ();
返回 render.export ();
由于 URL 参数由用户控制，因此它允许攻击者简单地访问他们想要的任何 URL。在某些情况下，根据用于访问URL的库，它甚至可以是使用'file: //'架构的本地文件。
当托管在 AWS 上时，滥用 SSRF 漏洞的一种常见方法是使用它来访问可包含 AWS API 证书的 AWS 元数据 API。这可能会导致进一步访问账户内的其他 AWS 资源，您可以想象，这并不理想。
缓解措施
缓解 SSRF 漏洞有时可能非常棘手，并且在很大程度上取决于相关代码想要实现的目标。根据要求的不同，可以采取不同的缓解措施。
避免使用用户确定的 URL
在某些情况下，你可能能够以不依赖用户提供任意 URL 的方式来实现某个功能。如果这完全可能，那是降低SSRF风险的最有效方法。
尽量减少能力
如果您正在实现 PDF 导出功能，则可能倾向于简单地使用无界面浏览器并截取页面的屏幕截图。考虑到浏览器的复杂性以及浏览器暴露的功能和攻击面数量之多，这并不总是可取的。
为手头的工作使用正确的工具很重要。在某些情况下，一个简单的 HTTP 客户端就足够了。总能采取一些措施来最大限度地减少能力，从而最大限度地减少可用的攻击面/向量。例如，对于 HTTP 客户端：
- 禁用以下重定向
- 禁用 HTTPS 以外的所有方案
有一些陷阱
重定向和 iframe
防范私有资源（IP 地址或内部主机名）上的 SSRF 的一种常见方法是解析用户提供的 URL 并使用 “拒绝列表” 来阻止对敏感资源的访问。
值得注意的是，这种方法在大多数情况下并不有效，因为在客户端遵循HTTP重定向、HTML/JavaScript重定向或可以渲染iframe等复杂元素的场景中，可以绕过这种方法。
攻击者可以通过HTTP 301/302、HTML元重定向、在加载Javascript时设置当前网址或嵌入显示内部资源的iframe向易受攻击的应用程序提供网址，该应用程序托管一个重定向到敏感资源的页面。这实际上绕过了任何验证原始 URL 的尝试。
DNS 重新绑定
另一种 “类型” 的重定向也可以通过 DNS 完成。尝试防止 SSRF 攻击的一种常见方法是执行以下操作：
- 解析提供的 URL
- 获取主机名，然后进行 DNS 查询
- 如果 URL 解析为内部/私有 IP，则拒绝；如果该 URL 是公有 IP，则接受 URL
这种方法并不真正有效，因为它容易受到 “DNS重新绑定” 的影响。DNS 重新绑定之所以有效，是因为当远程主机关闭 TCP 连接时，大多数网络堆栈（例如 Linux 和 Windows 的堆栈）都是标准行为。
当远程主机强制关闭连接时，它将在执行另一次 DNS 查询以重新解析 IP 地址后尝试重新连接。
这允许攻击者执行以下操作：
- 使用公有 IP 地址为 “rebinding.attacker.com” 创建一个 DNS 条目，该地址具有开放的 HTTP 端口，TTL 非常短（生存时间）
- 向易受攻击的应用程序提交 URL（示例：https://rebinding.attacker.com/）。它会进行检查以确保解析的 IP 不是私有的，事实并非如此，然后在相信它是安全的前提下继续执行所请求的操作
- 建立 HTTP 连接后，“rebinding.attacker.com” 的 DNS 条目将更改为内部 IP 地址
- HTTP 连接被强制关闭
- 现在，这会导致应用程序重新解析 “rebinding.attacker.com” 的 IP 地址，该地址现在指向内部 IP 地址
- 由于 IP 解析保护已经发生，而且 DNS 条目的重新解析和重新连接都发生在内核中，因此应用程序不知道 IP 现在已更改的事实
这实际上绕过了防止提供解析为私有 IP 地址的 URL 的保护。
IPv4 与 IPv6
绕过任何 “拒绝名单” 的另一种常用方法是使用 IPv6。由于所有 IPv4 地址都可以用 IPv6 地址表示，因此通常可以使用 IPv6 地址绕过拒绝列表，该地址也映射到人们想要访问的 IPv4 地址。