PortSwigger靶场之SSRF with whitelist-based input filter通关秘籍

解决这个基于白名单输入过滤器的靶场，核心在于利用 URL 解析特性绕过白名单验证，最终访问内部管理界面删除目标用户。

漏洞原理

靶场的库存检查功能通过stockApi参数接收 URL 并发起请求，但开发者部署了基于主机名的白名单过滤（仅允许stock.weliketoshop.net等可信域名）。SSRF 漏洞的关键在于：不同系统对 URL 的解析规则可能存在差异，可通过构造特殊 URL，让前端过滤器认为是合法域名，而后端实际请求的是内部地址（如localhost）。

具体解决步骤

1. 触发库存检查请求访问任意产品页面，点击 “查看库存”，使用 Burp Suite 拦截该请求（包含stockApi参数

2. 验证白名单机制修改stockApi为http://127.0.0.1/，观察到请求被拒绝（白名单拦截内部 IP），说明过滤器会提取并验证 URL 中的主机名。

3. 利用 URL 嵌入式凭据绕过URL 格式支持http://[用户名]@[主机名]的语法。测试发现该格式被白名单接受（因主机名是stock.weliketoshop.net），但后端可能优先解析用户名部分作为实际请求的主机。

4. 通过双重编码#符号截断主机名

   • #在 URL 中是锚点符号，会截断其后的内容，但直接使用#会被过滤器识别为非法字符。
   • 对#进行双重 URL 编码：# → 第一次编码%23 → 第二次编码%2523。
   • 此时 URL 中的%2523在后端解码后会变为#，截断后续的@stock.weliketoshop.net，使实际请求的主机变为localhost。

5. 构造最终攻击 URL将stockApi参数修改为：

   http://localhost:[e-mail]/admin/delete?username=carlos

   • 前端过滤器提取主机名是stock.weliketoshop.net（符合白名单），允许请求通过。
   • 后端解析时，%2523解码为#，截断@stock.weliketoshop.net，实际请求的是http://localhost:80/admin/delete?username=carlos，从而删除用户carlos。

总结

通过利用 URL 的用户名@主机名语法和双重编码#符号，成功绕过白名单对主机名的验证，将请求重定向到内部localhost的管理界面，实现 SSRF 攻击。核心是利用前后端 URL 解析规则的差异，构造 “前端合法、后端实际攻击” 的特殊 URL。