Web View

_book/Chapter10/10-5.md

@@ -0,0 +1,60 @@
+### 如何判断 SSRF 的流量是否攻击成功
+
+**1. 基于DNS记录判断**
+
+这是最常见也最简单的方法之一，利用 **DNS 带外通信**来判断
+
+**原理：** 攻击者在一个可以记录 DNS 解析的域名服务器上，为每个攻击目标生成一个唯一的子域名。然后，在 SSRF 的payload 中，让服务器去请求这个子域名
+
+**如何判断成功：** 如果攻击成功，服务器会尝试解析这个子域名。攻击者的 DNS 服务器会收到一个来自服务器 IP 的 DNS解析请求，从而证明 SSRF 漏洞确实存在，并且服务器执行了我们的请求
+
+**举例：**
+
+- 攻击者在 `attacker.com` 上部署 DNS 服务
+- 攻击者构造 payload：`http://vulnerable.com/ssrf?url=http://test12345.attacker.com`
+- 如果 SSRF 成功，攻击者的DNS服务器会收到来自 `vulnerable.com` 服务器 IP 的 `test12345.attacker.com` 域名解析请求
+
+**2. 基于 HTTP 请求判断**
+
+如果漏洞允许，我们可以让服务器去请求一个我们控制的 HTTP 服务器
+
+**原理：** 攻击者搭建一个 HTTP 服务器，并在 SSRF 的 payload 中让服务器请求该服务器
+
+**如何判断成功：** 如果 SSRF 成功，攻击者的 HTTP 服务器会收到一个来自目标服务器 IP 的 HTTP 请求。通过查看请求的User-Agent、来源 IP 等信息，可以进一步确认漏洞的存在
+
+**举例：**
+
+- 攻击者在公网IP `1.1.1.1` 上搭建 HTTP 服务（如`nc -lvp 80`）
+- 攻击者构造 payload：`http://vulnerable.com/ssrf?url=http://1.1.1.1:80/check.txt`
+- 如果 SSRF 成功，攻击者的 HTTP 服务器会收到一个来自 `vulnerable.com` 服务器的 HTTP 请求
+
+**3. 基于时间差判断**
+
+这种方法利用服务器处理特定请求所需的时间来判断，常用于**盲SSRF**场景，即服务器不会返回请求结果
+
+**原理：** 攻击者构造一个SSRF payload，使其请求一个需要耗费较长时间的资源，例如一个不存在或响应很慢的端口，或者一个非常大的文件
+
+**如何判断成功：** 如果 SSRF 成功，服务器的处理时间会显著增加。通过对比执行正常请求和 SSRF 请求的响应时间，如果后者明显更长，则可以初步判断 SSRF 攻击成功
+
+**举例：**
+
+- 构造SSRF payload让服务器请求一个不存在的端口：`http://vulnerable.com/ssrf?url=http://127.0.0.1:65535`
+- 正常请求响应时间：`100ms`
+- SSRF请求响应时间：`3000ms`（因为连接超时）
+- 响应时间明显增加，表明服务器执行了内部请求
+
+**4. 基于错误信息判断**
+
+一些配置不当的应用程序会在 SSRF 失败时，直接返回服务器内部的错误信息
+
+**原理：** 攻击者故意构造一个错误的 SSRF 请求，例如请求一个私有 IP 地址或本地文件，并观察应用程序返回的错误信息
+
+**如何判断成功：** 如果应用程序返回的错误信息包含服务器内部的路径、IP 地址或内部错误代码，如 `Failed to connect to 127.0.0.1` 或 `Permission denied`，则可以确认服务器确实尝试执行了该请求，并且 SSRF 漏洞存在
+
+**5. 基于响应内容判断**
+
+如果 SSRF 漏洞是**可回显**的，攻击者可以直接从服务器的响应中判断攻击是否成功
+
+**原理：** 攻击者构造一个 SSRF payload，让服务器请求内部资源，如 `http://127.0.0.1/` 或 `file:///etc/passwd`
+
+**如何判断成功：** 如果服务器的响应中包含了目标资源的内部内容，例如本地 Web 服务器的欢迎页面、`/etc/passwd` 文件的内容等，那么 SSRF 攻击成功