SSRF拼接新思路 作者: ynnddddd 时间: 2025-03-12 分类: 学业,网络安全,SSRF ### 解释 --- <!--more--> > 攻击者可以控制请求指向的服务端子域名。注意payload末尾的`&x=`，它用于阻止服务器将剩余路径追加到攻击者的URL末尾，而是将其转换为查询字符串中的参数（`?x=`）。 --- #### **技术原理详解** ##### **1. 正常请求处理流程** 假设正常后端处理逻辑如下： ```http 原始请求：http://website.thm/stock?server=api&id=123 后端行为： 1. 读取 `server=api` 参数 2. 拼接子域名生成内部请求：http://api.website.thm/api/stock/item?id=123 3. 向子域名发送请求并返回结果 ``` ##### **2. 攻击者构造恶意payload** 攻击者篡改`server`参数，注入特殊符号： ```http 恶意请求：http://website.thm/stock?server=api.attacker.com&x=&id=123 ``` - **关键Payload**：`&x=` - 作用：强制截断URL路径，将后续内容转为查询参数 ##### **3. 服务端错误解析过程** 服务端错误处理逻辑： ```http 预期拼接：http://{server}.website.thm/api/stock/item?id=123 实际拼接： - server=api.attacker.com&x= 被解析为完整子域名 - 生成恶意请求：http://api.attacker.com&x=.website.thm/api/stock/item?id=123 ``` - **URL解析异常**： - `&x=` 被识别为查询参数分隔符 - 实际请求变为： ```http http://api.attacker.com?x=.website.thm/api/stock/item?id=123 ``` ##### **4. 攻击结果** | 阶段 | 说明 | |-------------------|--------------------------------------------------------------------| | **攻击控制点** | 服务端向 `api.attacker.com` 发起请求（攻击者控制的域名） | | **路径劫持** | 原始路径 `/api/stock/item` 被转为参数 `x`，攻击者可自定义响应内容 | | **数据泄露** | 攻击者返回伪造数据（如数据库信息），服务端误将其作为合法响应返回给用户 | --- #### **防御对比表** | 漏洞成因 | 防御方案 | 实施示例 | |-------------------------|---------------------------------|---------------------------------------| | 未过滤特殊字符（`&`） | 输入白名单校验 | 仅允许字母数字：`[a-zA-Z0-9]` | | URL拼接逻辑缺陷 | 使用安全URL库 | Python的`urllib.parse.urljoin()` | | 信任任意子域名 | 限制访问域名范围 | 只允许`*.website.thm`子域名 | | 未验证响应内容 | 校验响应数据结构 | 检查JSON是否包含必需字段（如`price`） | --- #### **扩展攻击场景** 1. **云环境渗透** ```http server=169.254.169.254&x=/?id= ``` - 访问AWS元数据接口：`http://169.254.169.254?x=...` - 窃取IAM角色凭证 2. **内网服务扫描** ```http server=127.0.0.1:8080&x=/admin ``` - 探测本地管理接口：`http://127.0.0.1:8080?x=/admin` --- ### **总结** 通过`&x=`类payload，攻击者利用服务端的URL解析缺陷，将本应追加的路径强制转换为查询参数，从而： 1. 完全控制请求目标（子域名/IP） 2. 绕过服务端对固定路径的校验 3. 实现SSRF攻击链的完整控制 防御需从**输入过滤**、**安全拼接**、**输出验证**三个层面建立纵深防护体系。 标签: none