什么是服务器端请求伪造 (SSRF)？

黑伞安全

发布于 2022-01-26 14:02:43

1.5K0

发布于 2022-01-26 14:02:43

文章被收录于专栏：黑伞安全

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) 攻击的示例。

<?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 服务器发出请求。

GET /?url=http://localhost/server-status HTTP/1.1
Host: example.com

攻击者还可以使用 SSRF 向 Web 服务器可以访问的其他内部资源发出请求，这些资源是不公开的。例如，他们可以访问 AWS/ Amazon EC2和OpenStack等云服务实例元数据。攻击者甚至可以利用 SSRF 发挥创意并在内部 IP 上运行端口扫描。

GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: example.com

除了http://和https:// URL 架构之外，攻击者可能会利用鲜为人知的或遗留的 URL 架构来访问本地系统或内部网络上的文件。

以下示例使用file:/// URL 架构。

GET /?url=file:///etc/passwd HTTP/1.1
Host: example.com

某些应用程序可能使攻击者能够使用更奇特的 URL 模式。例如，如果应用程序使用 cURL 发出请求，攻击者可以使用dict:// URL 模式向任何端口上的任何主机发出请求并发送自定义数据。

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 应用程序的安全，最好尽可能启用身份验证，即使对于本地网络上的服务也是如此。