Introduction
本文翻译http://acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
服务器端请求伪造 (SSRF) 是唯一在OWASP 2021 年前 10 名 列表中拥有自己类别的漏洞类型 。近年来发生的几起重大网络安全漏洞，包括 Capital One和MS Exchange 攻击，都涉及使用 SSRF 作为入侵技术之一。
SSRF 漏洞使攻击者可以从易受攻击的应用程序的后端服务器发送精心设计的请求。犯罪分子通常使用 SSRF 攻击来针对位于防火墙后面且无法从外部网络访问的内部系统。攻击者还可以利用 SSRF 访问通过被利用服务器的环回接口 (127.0.0.1) 提供的服务。
当攻击者完全或部分控制 Web 应用程序发送的请求时，就会出现 SSRF 漏洞。一个常见的例子是攻击者可以控制 Web 应用程序向其发出请求的第三方服务 URL。
以下是 PHP 中易受服务器端请求伪造 (SSRF) 攻击的示例。
代码语言：javascript复制<?php
/**
* Check if the 'url' GET variable is set
* Example - http://localhost/?url=http://testphp.vulnweb.com/images/logo.gif
*/
if (isset($_GET['url'])){
$url = $_GET['url'];
/**
* Send a request vulnerable to SSRF since
* no validation is being done on $url
* before sending the request
*/
$image = fopen($url, 'rb');
/**
* Send the correct response headers
*/
header("Content-Type: image/png");
/**
* Dump the contents of the image
*/
fpassthru($image);}访问如图：
在上面的例子中，攻击者完全控制了url参数。他们可以向 Internet 上的任何网站和服务器 ( localhost ) 上的资源发出任意 GET 请求。
在以下示例中，攻击者向启用了mod_status（默认启用）的 Apache HTTP 服务器发出请求。
代码语言：javascript复制GET /?url=http://localhost/server-status HTTP/1.1
Host: example.com攻击者还可以使用 SSRF 向 Web 服务器可以访问的其他内部资源发出请求，这些资源是不公开的。例如，他们可以访问 AWS/ Amazon EC2和OpenStack等云服务实例元数据。攻击者甚至可以利用 SSRF 发挥创意并在内部 IP 上运行端口扫描。
代码语言：javascript复制GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: example.com除了http://和https:// URL 架构之外，攻击者可能会利用鲜为人知的或遗留的 URL 架构来访问本地系统或内部网络上的文件。
以下示例使用file:/// URL 架构。
代码语言：javascript复制GET /?url=file:///etc/passwd HTTP/1.1
Host: example.com某些应用程序可能使攻击者能够使用更奇特的 URL 模式。例如，如果应用程序使用 cURL 发出请求，攻击者可以使用dict:// URL 模式向任何端口上的任何主机发出请求并发送自定义数据。
代码语言：javascript复制GET /?url=dict://localhost:11211/stat HTTP/1.1
Host: example.com上述请求将导致应用程序连接到端口 11211 上的localhost并发送字符串stat。端口 11211 是Memcached使用的默认端口，通常不会暴露。
请注意，SSRF 漏洞利用通常允许攻击者使用其他危险技术进行跟进。例如，您可以将 盲 SSRF 升级为 远程代码执行 (RCE) 。
检测服务器端请求伪造
要自动检测服务器端请求伪造，您需要依赖中介服务。检测此类漏洞需要带外和时间延迟向量。Acunetix 通过使用AcuMonitor作为中介服务解决了这个问题。
在扫描期间，Acunetix 发出包含唯一 AcuMonitor URL 的请求。如果 AcuMonitor 收到对这些唯一 URL 之一的请求，它会将通知发送回 Acunetix。它会导致 Acunetix 发出 SSRF 警报。
以下是使用 AcuMonitor 进行 Acunetix 扫描的结果，该扫描检测到服务器端请求伪造。警报包含有关 HTTP 请求的信息。它包括发出请求的服务器的 IP 地址和请求中User-Agent使用的字符串（如果有）。此信息可以帮助开发人员确定问题的根源并进行修复。
减轻服务器端请求伪造
应用于用户输入的简单黑名单和正则表达式是缓解 SSRF 的糟糕方法。一般来说，黑名单是一种较差的安全控制手段。攻击者总会找到绕过它们的方法。在这种情况下，攻击者可以使用 HTTP 重定向、通配符 DNS 服务（例如xip.io），甚至是替代 IP 编码。
白名单和 DNS 解析
避免服务器端请求伪造 (SSRF) 的最可靠方法是将应用程序需要访问的主机名（DNS 名称）或 IP 地址列入白名单。如果白名单方法不适合您并且您必须依赖黑名单，那么正确验证用户输入非常重要。例如，不允许向具有私有（不可路由）IP 地址的端点发出请求（详见 RFC 1918 ）。
但是，在黑名单的情况下，要采用的正确缓解措施因应用程序而异。换句话说，SSRF 没有通用的解决方案，因为它高度依赖于应用程序功能和业务需求。
响应处理
为防止响应数据泄露给攻击者，您必须确保收到的响应符合预期。在任何情况下都不应将来自服务器发送的请求的原始响应正文传递给客户端。
禁用未使用的 URL 架构
如果您的应用程序仅使用 HTTP 或 HTTPS 发出请求，则仅允许这些 URL 架构。如果您禁用未使用的 URL 模式，攻击者将无法使用 Web 应用程序使用具有潜在危险的模式（例如file:///、dict://、ftp://和gopher:// ）发出请求。
内部服务认证
默认情况下，Memcached、Redis、Elasticsearch 和 MongoDB 等服务不需要身份验证。攻击者可以使用服务器端请求伪造漏洞来访问其中一些服务，而无需任何身份验证。因此，为了保护您的敏感信息并确保 Web 应用程序的安全，最好尽可能启用身份验证，即使对于本地网络上的服务也是如此。
经常问的问题
什么是服务器端请求伪造 (SSRF)？
SSRF 是由不良编程引起的危险网络漏洞。SSRF 允许攻击者将请求从服务器发送到其他资源，包括内部和外部，并接收响应。
有关 SSRF 攻击的示例，请阅读有关 Capital One 漏洞的更多信息。
SSRF 有多常见？
幸运的是，SSRF 并不是一个非常常见的漏洞。根据最新的 Acunetix Web 应用程序漏洞报告，它平均存在于 1% 的 Web 应用程序中。
了解有关网络安全当前状态的更多信息。
SSRF有多危险？
SSRF 是一个非常危险的漏洞，可能会导致严重的安全漏洞。这是避免防火墙和访问原本无法访问的内部资源的一种非常方便的方法。SSRF 通常用于进一步升级攻击。
了解如何使用 SSRF 进行内部端口扫描以升级攻击。
如何检测SSRF？
检测 SSRF 的唯一方法是使用带外漏洞扫描程序。您无法使用传统扫描仪检测到它。Acunetix 使用 AcuMonitor 作为其先进的带外检测技术。
了解有关 AcuMonitor 和带外扫描的更多信息。
如何避免SSRF？
为了避免 SSRF，永远不要相信用户输入。如果您的应用程序需要在请求中传递 URL，请使用 IP 地址和域的白名单，并始终验证响应是否具有预期的格式和内容。
阅读有关一般安全编程习惯的更多信息。
上述内容来自
acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
建议少用扫描器！！！
