1. SSRF漏洞基础与CTF实战价值服务器端请求伪造SSRF一直是CTF比赛中的高频考点也是企业安全测试中的高危漏洞类型。简单来说它允许攻击者通过服务器端应用发起精心构造的请求突破网络边界访问内部系统。去年某大型电商平台的内部数据泄露事件根本原因就是订单查询接口存在SSRF漏洞。在CTF比赛中SSRF题目通常会设置多层限制目标服务器禁止直接访问敏感路径如/flag.php请求参数经过基础过滤如禁用http://等协议头返回结果有内容检测如检查响应是否包含flag{字样我去年参加的一场比赛中就遇到过这样的场景题目提供了一个天气预报查询接口表面上只能输入城市名实则后端会拼接URL访问气象局的API。通过Burp Suite抓包修改参数最终用file://协议读取到了服务器上的配置文件。2. 短链接技术在SSRF中的妙用2.1 短链接工作原理剖析短链接服务如bit.ly或t.cn的核心机制其实很简单用户提交长链接 → https://example.com/very/long/url?withparameters服务端生成短码 → https://bit.ly/3xYzZ1访问短链接时服务端返回302跳转这个过程中有两个关键特性可以被利用域名转换最终请求的Host头是短链接服务商域名路径隐藏真实路径参数在服务端完成解析去年我测试某金融系统时就曾用t.cn短链接绕过其仅允许访问*.bank.com的白名单限制。因为实际发起请求时HTTP Host头显示的是t.cn而非目标银行域名。2.2 实战中的短链接构造技巧以本次金盾杯题目为例解题流程应该是发现目标接口接受URL参数https://114.55.67.167:52263/?url将敏感地址https://114.55.67.167:52263/flag.php转换为短链接提交类似https://bit.ly/xxxxx的格式这里有个细节要注意不同短链接服务对特殊字符的处理方式不同。我推荐使用Google的短链接服务因为它会完整保留原始URL的query参数。测试时可以先用curl验证curl -I https://goo.gl/xxxxx # 查看返回的Location头3. 完整攻击链实战演示3.1 环境探测与信息收集首先用浏览器访问题目环境通常会看到这样的界面输入框提示请输入查询URL底部可能有小字提示仅支持HTTP/HTTPS协议这时候应该先用DNS解析工具获取真实IPdig short target.com nslookup target.com 8.8.8.8记得检查是否有CDN存在。去年一道赛题就故意设置了CloudFront防护实际flag服务器在172.16.0.2这个内网IP上。3.2 短链接生成与利用确认目标地址后建议使用Python的requests库批量测试import requests from urllib.parse import quote target https://114.55.67.167:52263/flag.php short_url generate_short_url(target) # 调用短链接API response requests.get(fhttp://ctf.example.com/api?url{quote(short_url)}) print(response.text)注意这里必须要做URL编码否则特殊字符可能导致请求失败。常见需要编码的字符包括? 转码为 %3F 转码为 %3D 转码为 %264. 防御方案与出题人思路4.1 常见防护手段绕过比赛中常见的防护措施包括协议白名单只允许http/https尝试用http://localhostevil.com/这种认证语法域名黑名单禁止127.0.0.1等使用短链接或域名重定向内容检测检查返回是否包含flag{用分块传输编码绕过检测去年某次比赛中我遇到一个有趣的变种题目要求访问的URL必须包含特定字符串但检测是大小写敏感的。最终用URL编码绕过http://example.com/%46%4c%41%47.php4.2 从出题角度理解考点这类题目的设计通常包含三个层次基础层直接SSRF读取flag进阶层需要组合短链接参数污染地狱层要求构造DNS重绑定攻击建议参赛者多研究历年赛题wp比如下面这个典型payloadhttp://127.1/%2566lag.php这个利用了两次URL解码的特性第一次解码后变成%66lag.php第二次变成flag.php
2024金盾信安杯线上赛：SSRF漏洞实战解析与短链接利用技巧
发布时间：2026/5/22 13:37:50
1. SSRF漏洞基础与CTF实战价值服务器端请求伪造SSRF一直是CTF比赛中的高频考点也是企业安全测试中的高危漏洞类型。简单来说它允许攻击者通过服务器端应用发起精心构造的请求突破网络边界访问内部系统。去年某大型电商平台的内部数据泄露事件根本原因就是订单查询接口存在SSRF漏洞。在CTF比赛中SSRF题目通常会设置多层限制目标服务器禁止直接访问敏感路径如/flag.php请求参数经过基础过滤如禁用http://等协议头返回结果有内容检测如检查响应是否包含flag{字样我去年参加的一场比赛中就遇到过这样的场景题目提供了一个天气预报查询接口表面上只能输入城市名实则后端会拼接URL访问气象局的API。通过Burp Suite抓包修改参数最终用file://协议读取到了服务器上的配置文件。2. 短链接技术在SSRF中的妙用2.1 短链接工作原理剖析短链接服务如bit.ly或t.cn的核心机制其实很简单用户提交长链接 → https://example.com/very/long/url?withparameters服务端生成短码 → https://bit.ly/3xYzZ1访问短链接时服务端返回302跳转这个过程中有两个关键特性可以被利用域名转换最终请求的Host头是短链接服务商域名路径隐藏真实路径参数在服务端完成解析去年我测试某金融系统时就曾用t.cn短链接绕过其仅允许访问*.bank.com的白名单限制。因为实际发起请求时HTTP Host头显示的是t.cn而非目标银行域名。2.2 实战中的短链接构造技巧以本次金盾杯题目为例解题流程应该是发现目标接口接受URL参数https://114.55.67.167:52263/?url将敏感地址https://114.55.67.167:52263/flag.php转换为短链接提交类似https://bit.ly/xxxxx的格式这里有个细节要注意不同短链接服务对特殊字符的处理方式不同。我推荐使用Google的短链接服务因为它会完整保留原始URL的query参数。测试时可以先用curl验证curl -I https://goo.gl/xxxxx # 查看返回的Location头3. 完整攻击链实战演示3.1 环境探测与信息收集首先用浏览器访问题目环境通常会看到这样的界面输入框提示请输入查询URL底部可能有小字提示仅支持HTTP/HTTPS协议这时候应该先用DNS解析工具获取真实IPdig short target.com nslookup target.com 8.8.8.8记得检查是否有CDN存在。去年一道赛题就故意设置了CloudFront防护实际flag服务器在172.16.0.2这个内网IP上。3.2 短链接生成与利用确认目标地址后建议使用Python的requests库批量测试import requests from urllib.parse import quote target https://114.55.67.167:52263/flag.php short_url generate_short_url(target) # 调用短链接API response requests.get(fhttp://ctf.example.com/api?url{quote(short_url)}) print(response.text)注意这里必须要做URL编码否则特殊字符可能导致请求失败。常见需要编码的字符包括? 转码为 %3F 转码为 %3D 转码为 %264. 防御方案与出题人思路4.1 常见防护手段绕过比赛中常见的防护措施包括协议白名单只允许http/https尝试用http://localhostevil.com/这种认证语法域名黑名单禁止127.0.0.1等使用短链接或域名重定向内容检测检查返回是否包含flag{用分块传输编码绕过检测去年某次比赛中我遇到一个有趣的变种题目要求访问的URL必须包含特定字符串但检测是大小写敏感的。最终用URL编码绕过http://example.com/%46%4c%41%47.php4.2 从出题角度理解考点这类题目的设计通常包含三个层次基础层直接SSRF读取flag进阶层需要组合短链接参数污染地狱层要求构造DNS重绑定攻击建议参赛者多研究历年赛题wp比如下面这个典型payloadhttp://127.1/%2566lag.php这个利用了两次URL解码的特性第一次解码后变成%66lag.php第二次变成flag.php
