[i=s] 本帖最后由 zeke 于 2025-9-9 14:40 编辑 [/i]
WEB渗透测试工程师系统班250303期
第35节课作业
1.实操课程内讲解的相关靶场（截图）
Less-2 GET中URL参数
如果目标服务器存在 SSRF 漏洞，它将会发起对http://127.0.0.1:8787/ssrf/flag的 GET 请求。攻击者可以通过这种方式获取敏感信息、绕过防火墙，甚至攻击内部资源。
Less-3 SSRF POST 中 URL 参数
用户可以通过 POST 请求提交一个 URL，然后服务器将该 URL 作为目标发起 HTTP 请求，而没有充分的验证。
在提交表单时，攻击者可以将恶意 URL 作为参数，从而导致服务器发起未经授权的请求，从而触发 SSRF 漏洞。
Less-4 SSRF POST 中 URL 参数 (DNS Rebinding)
DNS Rebinding 攻击是一种通过在恶意网站和受害者之间建立一个恶意的 DNS 记录来绕过同源策略的攻击。攻击者可以利用这种漏洞来访问本地网络、绕过防火墙访问内部服务、窃取敏感信息等。
攻击流程解析：
第1步：搭建攻击基础设施
①配置DNS重绑定记录：
在 ceye.io 的管理面板中，为子域名 r.xxxx.ceye.io 设置一条A记录。
这条记录的关键是设置一个非常短的TTL（例如5秒），并配置两个IP地址：
第一个IP：你的VPS的公网IP地址。
第二个IP：目标内部IP 110.110.2.1。
DNS服务器会按照配置的顺序返回这两个IP。由于TTL极短，浏览器会频繁重新查询。
②在VPS上部署重定向脚本：
在VPS上创建 index.php 文件，内容为：
<?php header("Location: http://127.0.0.1:8787/ssrf/flag"); ?>
这行代码的作用是：当有人访问这个PHP脚本时，服务器会返回一个302重定向响应，指示浏览器跳转到 http://127.0.0.1:8787/ssrf/flag。
重要：使用PHP内置服务器在一个非标准端口（如7777）启动Web服务：
php -S 0.0.0.0:7777
0.0.0.0 表示监听所有网络接口。
使用非80/8080端口是为了避免与VPS上可能存在的其他服务冲突。
第2步：发起攻击
构造请求：
假设受害者服务有一个功能，它会获取你提供的URL的内容（这就是SSRF漏洞的本质）。
你向该服务提交的URL就是：http://r.xxxxx.ceye.io:7777
第3步：攻击发生过程（核心）
这个过程是异步且自动的，以下是浏览器/受害者服务后端在访问你提供的URL时发生的事：
①第一次DNS查询：
受害者服务器（或浏览器）收到URL，开始解析 r.xxxx.ceye.io。
攻击者控制的DNS服务器返回第一个IP：VPS的地址。
受害者服务器于是向 [VPS_IP]:7777 发起HTTP请求。
②第一次HTTP交互：
VPS上的PHP服务器（监听7777端口）收到了请求。
index.php 脚本被执行，返回一个 302重定向响应，响应头中包含 Location: http://127.0.0.1:8787/ssrf/flag。
请注意：此时的 127.0.0.1 指的是受害者服务器自己的环回地址，而不是攻击者的VPS！这个重定向指令是在受害者服务器端被解释的。
浏览器/受害者服务遵循重定向：
收到302响应后，受害者服务会自动向 Location 头中指定的新URL (http://127.0.0.1:8787/ssrf/flag) 发起第二次请求。
③第二次DNS查询（重绑定发生！）：
为了请求 http://127.0.0.1:8787/ssrf/flag，不需要DNS解析（因为用的是IP）。
但是，在某些复杂的SSRF场景或浏览器环境中，初始请求可能持有了一个到 r.xxxx.ceye.io 的长连接，或者重定向逻辑本身会重新解析主机名。更典型的利用方式是，恶意脚本驻留在浏览器中，等待TTL过期后重新请求自己的域名，此时DNS解析结果变为内网IP。这个流程是一个混合利用方式，巧妙地结合了：
DNS Rebinding： 将域名解析到内网IP。
SSRF + 重定向： 利用服务端会跟踪重定向的特性，将请求“跳转”到真正的目标。
⑤访问目标，获取Flag：
最终，受害者服务向 http://127.0.0.1:8787/ssrf/flag 发出的请求，成功访问了其自身网络环境中的Docker容器服务。
该服务返回flag的内容，受害者服务可能会将这个内容显示给你（攻击者），或者被你的工具（Yakit）截获。
注：爆破数据包的意义
“爆破数据包至出现flag”。这是因为网络 timing 可能存在不确定性。
为什么需要“爆破”？ DNS重绑定的成功依赖于第二次请求发生时，DNS缓存恰好过期，并且DNS服务器返回的是第二个IP（110.110.2.1）。这个过程存在竞争条件，不是100%一次成功。
“爆破” 意味着持续地、高频率地向 http://r.xxxx.ceye.io:7777 发送请求。
在大量尝试中，总会有几次请求的 timing 符合条件：第一次解析到VPS拿到重定向指令，第二次解析或后续请求时域名被重绑定到 110.110.2.1，从而成功访问到内网服务并拿到flag响应。
Less-8 完全开放重定向
完全开放重定向漏洞是一种常见的安全漏洞，发生在应用程序中对外部用户提供的重定向功能上。攻击者可以通过构造恶意的重定向链接，将用户导向恶意网站或恶意内容，从而进行钓鱼攻击、会话劫持等恶意行为。这种漏洞通常发生在没有对用户提供的重定向目标进行充分验证的情况下。
Less-9 完全开放重定向(无限重定向)
完全开放的重定向漏洞是一种安全漏洞，它允许攻击者通过构造恶意的重定向链接，将用户重定向到任意的 URL。在这个特定的案例中，重定向是无限的，会导致服务器不断地将用户重定向到同一个 URL，形成一个无限重定向循环，最终可能会导致服务不可用或资源耗尽。
Less-10 完全开放重定向
完全开放重定向漏洞是一种存在于应用程序中的安全漏洞，攻击者可以利用该漏洞通过构造恶意的 URL 来将用户重定向到恶意网站或内容。在这种情况下，重定向是通过 JavaScript 的location.href属性实现的，使页面在一定时间后自动进行重定向
Less-11 完全开放重定向（JS location.replace）
在这个特定的案例中，漏洞利用了 JavaScript 中的 location.replace 方法，将用户重定向到指定的 URL。
Less-12 完全开放重定向（JS location.assign）
完全开放重定向是一种安全漏洞，它允许攻击者通过构造恶意链接将用户重定向到任意 URL。在本例中，我们将介绍使用 JavaScript 的location.assign方法来实现完全开放重定向。
Less-13 完全开放重定向（meta 延迟跳转）
通过在 HTML 文档中插入标签的http-equiv属性，可以控制浏览器在一定时间后自动重定向到新的 URL。这类似于用户访问一个网页后，该网页会在一段时间后自动跳转到其他页面。
Less-14 完全开放重定向（meta）
完全开放重定向是一种Web应用程序中的安全漏洞，攻击者可以利用它将用户重定向到任意URL，该漏洞通常出现在未正确验证或过滤用户提供的重定向目标的情况下。
Less-15 安全的重定向(只重定向 path)
安全的重定向是一种避免完全开放重定向漏洞的安全方法，它仅允许重定向目标为同一站点内的路径，而不是完整的 URL。通过只重定向路径而不是整个 URL，可以有效减少跳转到恶意网站或其他不受信任站点的风险。
2.SSRF绕过方法有哪些
一、基于URL解析的绕过
这类方法利用的是校验例程和请求库解析URL时的差异。
①.使用其他协议
目的：绕过黑名单过滤（如禁止http://和https://）。
方法：尝试使用其他可能被支持且能泄露数据的协议。
file://：读取本地文件。file:///etc/passwd
dict://：获取端口指纹信息。dict://127.0.0.1:22/info
gopher://：一个非常强大的协议，可以构造任意格式的TCP数据包，用于攻击内网Redis、Memcached、FastCGI等服务。
gopher://127.0.0.1:6379/_...（构造的Redis命令）
ldap:// / tftp://：在某些特定场景下有用。
②.利用URL解析歧义
目的：混淆URL解析器，让校验部分看到的是合法域名，而请求库实际连接的却是内网IP。
方法：
使用@：http://example.com@127.0.0.1 → 实际连接的是127.0.0.1，因为@是用户信息的分隔符。校验例程可能看到的是example.com。
使用#：http://127.0.0.1#.example.com → #是片段标识符，部分校验代码可能会忽略它之后的内容，认为域名是example.com，而请求库实际请求的是127.0.0.1。
使用奇怪的域名：注册一个类似 127.0.0.1.xip.io 的域名（xip.io是一个通配符DNS服务，127.0.0.1.xip.io会解析到127.0.0.1）。校验例程看到的是外网域名，但解析后是内网IP。
利用封闭式数字IP格式：IP地址可以有多种表示形式。
十进制：2130706433 → 127.0.0.1
八进制：0177.0.0.1 → 127.0.0.1（前导0）
十六进制：0x7f.0x0.0x0.0x1 → 127.0.0.1
混合：127.1 → 127.0.0.1（省略的段被视为0）
IPv6绕过：
使用IPv6地址::1代表本地主机。
使用IPv6压缩格式[::]。
使用IPv6兼容IPv4的地址::ffff:127.0.0.1。
③.利用重定向
目的：通过一个合法的、允许访问的外部域名，间接跳转到内网目标。
方法：
在自己控制的服务器上设置一个重定向（301/302），将请求跳转到http://127.0.0.1:8080。
提交你控制的服务器URL。校验通过，但在实际请求时，服务器会跟随重定向，访问内网资源。
DNS重绑定（高级重定向）：见下文。
二、基于防御逻辑缺陷的绕过
①.绕过黑名单
目的：绕过对敏感词（如localhost, 127.0.0.1, 192.168., 10., 172.16.）的过滤。
方法：
大小写混淆：LOCalHOST, 127.0.0.0.1
双写：127.0.0.1.0.0.1（如果过滤函数只替换一次）
添加端口：127.0.0.1:80（黑名单可能只匹配:80前的部分）
使用URL编码：127.0.0.1 → %31%32%37%2E%30%2E%30%2E%31 或 %6c%6f%63%61%6c%68%6f%73%74（localhost）
添加多余字符：127.0.0.1.example.com（如果校验是前缀/后缀匹配）
使用反向代理域名：127.0.0.1.nip.io （解析到127.0.0.1）
②.绕过白名单
目的：绕过只允许访问特定域名（如api.trusted.com）的限制。这通常更难。
方法：
利用@：http://api.trusted.com@evil.com → 实际请求的是evil.com，但校验可能只看到api.trusted.com。
利用路径：http://api.trusted.com/evil.com → 有些粗陋的校验只检查主机名部分。
利用子域名：控制trusted.com的一个子域名？或者利用同形异义字攻击（IDN Homograph Attack），注册一个看起来像api.trusted.com的域名（如使用西里尔字母аpi.trusted.com）。
利用解析差异：在你的控制下，将一个子域名指向内网IP，例如ssrf.trusted.com A记录指向 192.168.1.1。然后提交该子域名。因为它属于白名单域名，所以校验通过，但最终解析到的却是内网IP。
三、高级技巧：DNS重绑定
这是绕过IP黑名单/白名单的“终极武器”之一。
原理：利用DNS解析和实际请求的时间差。
你注册一个域名evil.com，并完全控制其DNS服务器。
你设置该域名的TTL（存活时间）为0或一个极短的值（如5秒）。
你向目标提交URL：http://evil.com/payload。
目标服务器进行校验：
它会对evil.com进行一次DNS查询。
你的DNS服务器返回一个合法的、允许的外网IP（比如你的VPS IP）。
校验通过（IP不在黑名单内/在白名单外）。
目标服务器开始真正发起请求：
由于TTL极短，第一次DNS解析的结果很快失效。
目标服务器需要再次查询evil.com的IP。
这次，你的DNS服务器返回一个内网IP（如192.168.1.1）。
目标服务器实际连接的是内网IP 192.168.1.1，攻击成功。
四、利用云元数据服务
这在攻击云服务器（AWS, GCP, Azure, Aliyun等）时特别有效。
原理：云平台通常提供一个内网的元数据服务，通过一个固定的IP（如169.254.169.254）可以获取当前实例的敏感信息，包括临时安全凭证（Token）。
方法：直接尝试访问 http://169.254.169.254/ 或类似路径。很多SSRF漏洞的最终目标就是这个端点，因为拿到凭证后就可以完全控制整个云服务器实例。
五、利用URL参数污染或SSRF链
目的：利用应用程序其他部分的解析特性。
方法：有时应用程序有多个组件处理URL。一个组件可能使用X-Forwarded-Host头，另一个使用Host头。你可以尝试注入额外的参数来覆盖最终使用的目标。例如：url=https://expected.com&next=internal.ip。
3.SSRF修复方法有哪些
SSRF的修复比较复杂，需要根据业务实际场景来采取不同的方案，例如前面说到的python中不同url库对url的解析就不一致，所以对于有条件的公司，建立一个代理集群是比较可靠的方案，将类似请求外部url的需求整理出来，分为纯外网集群和内网集群进行代理请求。
如果需要从代码层面来修复的话，需要注意一下几点：
- 去除url中的特殊字符
- 判断是否属于内网ip
- 如果是域名的话，将url中的域名改为ip
- 请求的url为3中返回的url
- 请求时设置host header为ip
- 不跟随30x跳转（跟随跳转需要从1开始重新检测）
一、笔记标题：WEB渗透系统班-SSRF服务端请求伪造（三）+SSRF服务端请求伪造（四）
二、文章内容：
1.课程内容概要
主要知识点1：yakit靶场SSRF部分
主要知识点2：SSRF绕过方法
主要知识点3：SSRF修复方法
2.重点知识与细节
概念解析
概念1：DNS Rebinding 攻击
DNS 重绑定攻击是一种利用浏览器同源策略缺陷的攻击技术。攻击者通过控制DNS解析，将一个恶意域名在短时间内解析到不同的IP地址（先是攻击者的服务器，后是目标内网设备的IP），从而绕过同源策略，直接访问并攻击用户内部网络中的设备。
同源策略：同源策略是浏览器最核心的安全模型之一。它规定：一个网页（来自源 A）的脚本（如 JavaScript）不能访问另一个源（源 B）的资源，除非这两个源是“同源”的。
如何判断同源：协议、域名、端口三者必须完全相同。
目的：防止恶意网站读取你其他网站（如邮箱、网银）的敏感数据。
例如：https://example.com 的脚本无法读取 http://internal-server.local 的数据，因为它们域名不同
攻击流程：
第1步：攻击者搭建陷阱
攻击者注册一个域名，比如 evil-site.com，并完全控制该域名的DNS服务器。他搭建一个恶意的网站，上面包含一些恶意JavaScript代码。
第2步：设置短暂的DNS TTL
攻击者为其域名 evil-site.com 设置一个非常短的 TTL。TTL是“存活时间”，告诉DNS缓存这个域名解析结果可以保存多久。极短的TTL（比如几秒钟）意味着浏览器和系统会频繁地重新查询这个域名的IP地址，而不是使用缓存。
第3步：诱骗受害者访问
攻击者通过钓鱼邮件、恶意广告等方式，诱骗受害者访问 http://evil-site.com。
第4步：初次解析 - 指向攻击者服务器
当受害者的浏览器第一次访问 evil-site.com 时，会向DNS服务器查询这个域名对应的IP。此时，攻击者控制的DNS服务器返回一个合法的、攻击者自己的服务器IP（例如 1.2.3.4）。
浏览器与 1.2.3.4 建立连接，加载了恶意网页和JavaScript脚本。此时，脚本的“源”被认为是 evil-site.com（其IP是 1.2.3.4）。
第5步：脚本执行与DNS重绑定
恶意脚本开始执行。它通常会试图访问用户内部网络中的设备（比如家庭路由器的管理界面 192.168.1.1，或者智能家居设备）。
脚本可能会使用 XMLHttpRequest 或 Fetch API 去连接 http://192.168.1.1。
然而，根据同源策略，来自 evil-site.com 的脚本不能访问 192.168.1.1，因为域名不同。但是，攻击在这里发生了巧妙的变化：
恶意脚本不会直接请求 192.168.1.1，而是再次请求它自己的域名，例如 http://evil-site.com/api/data。
此时，由于之前设置的短TTL已经过期，浏览器会再次向DNS服务器查询 evil-site.com 的IP地址。
关键一步：这次，攻击者控制的DNS服务器不再返回自己的IP (1.2.3.4)，而是返回一个内部网络的IP地址，例如 192.168.1.1。
第6步：绕过同源策略
浏览器不知道DNS解析结果已经变了。它认为它正在访问的仍然是 evil-site.com（因为域名没变）。
于是，浏览器向 192.168.1.1 发送请求，但它在HTTP请求头中的 Host 字段仍然写着 evil-site.com。
对于浏览器来说，这次请求的“源”仍然是 evil-site.com，所以同源策略允许恶意脚本读取这次请求的响应！
这样，恶意脚本就成功地绕过了同源策略，读取到了内部设备 192.168.1.1 返回的数据（例如路由器登录页面）。
第7步：实施攻击
攻击者的脚本可以：
窃取信息：读取内部设备的敏感信息或配置。
进行未授权操作：如果设备存在默认密码或漏洞，脚本可以模拟用户点击，更改路由器设置（如开启DMZ、修改DNS）、操控智能设备等。
进一步渗透：以该内部设备为跳板，扫描和攻击网络中的其他设备。
概念2：无
关键步骤（SSRF攻击步骤）
步骤1：探测 (Probing) - 确认漏洞存在
找到目标应用中哪些功能点可能会让服务器发起网络请求。
1.1识别参数：寻找接收URL或主机名作为输入的参数。
常见参数名：url, path, image, load, file, host, api, endpoint, redirect, view。
常见功能点：
社交媒体分享预览
文档/图片处理（从URL下载）
数据采集（价格监控、网页翻译）
Webhook配置
API接口（如/api/fetch?url=xxx）
步骤2：利用 (Exploitation) - 发动攻击
找到入口点后，攻击者会提交各种测试载荷（Payload），根据响应判断漏洞是否存在及类型。
2.1 测试基本Payload
回环地址：http://127.0.0.1, http://localhost
文件协议：file:///etc/passwd (Linux), file:///C:/windows/system.ini (Windows)
观察响应：如果响应中包含了本地文件内容或内部服务的页面，说明存在有回显的SSRF。
2.2 测试盲SSRF (Blind SSRF)
如果应用没有直接输出响应内容，攻击者需要借助外部工具来检测。
使用外带通道(OAST)：这是最关键的一步。使用Burp Collaborator、Interact.sh或DNSlog.cn生成一个唯一域名。
Payload：http://your-subdomain.burpcollaborator.net
原理：如果服务器端发起了请求，攻击者会在外带平台看到DNS查询和HTTP请求记录，从而证实漏洞存在。
2.3 尝试绕过防御
如果请求被拦截，尝试各种绕过技巧：
IP编码：
十进制：127.0.0.1 → 2130706433
十六进制：127.0.0.1 → 0x7f000001
URL编码：对://、/等字符进行编码。
使用重定向：提供一个URL，该URL返回一个302 Redirect到127.0.0.1。
域名重绑定：利用DNS重绑定服务（如rbndr.us）绕过黑名单。
步骤3：利用 (Exploitation) - 发动攻击
确认漏洞后，攻击者会根据漏洞类型（有回显/盲）进行利用。
3.1 利用有回显的SSRF
扫描内部网络：访问http://192.168.1.1:8080等常见内网地址，根据响应判断服务。
读取敏感文件：继续使用file://协议读取系统配置文件、源代码等。
攻击云元数据：直接访问云平台的元数据端点。
AWS: http://169.254.169.254/
Aliyun: http://100.100.100.200/
3.2 利用盲SSRF
即使没有回显，危害也可能很大。
端口扫描：通过响应时间差异判断内网端口是否开放（请求开放端口通常更快超时）。
使用更强大的协议：尝试利用gopher://或dict://协议发起更深入的攻击。
例如：gopher://127.0.0.1:6379/_... （构造Redis命令，写入Webshell）。
步骤4：影响升级 (Impact Escalation) - 扩大战果
这是最终阶段，目的是将SSRF漏洞的危害最大化。
1.攻击内网服务：
Redis/Memcached：利用未授权访问，执行命令，写入Webshell。
数据库：攻击MySQL、MongoDB等，尝试未授权访问或弱口令爆破。
管理后台：访问Jenkins、Docker API、K8s Dashboard等，获取服务器权限。
2.窃取云凭证（最危险的场景）：
如果服务器在云上，通过访问元数据API获取临时的Access Key和Secret Key。
攻击链：SSRF → 获取云元数据IAM角色凭证 → 使用AWS CLI/Aliyun CLI接管云服务器 → 完全控制云上资源。
3.组合拳攻击：
将SSRF与其他漏洞结合。例如，先通过SSRF发现一个内部Jenkins服务，再利用Jenkins的漏洞获取Shell权限。
相关代码：无
3.实操练习和解析
如作业
4.个人总结
本节课最大的收获是：学习了SSRF的各种场景，了解了绕过和防御方式
仍然存在疑问的地方：暂无
需要课后深入学习的内容：暂无
