kb: expand authorized lab coverage and intel automation

07-framework-security/frontend-js/cases/axios-ghsa-jr5f-v2jv-69x6.md

@@ -0,0 +1,71 @@
+---
+title: "Axios absolute URL handling SSRF mapping"
+published_date: "2025-03-07"
+affected_versions:
+  - ">= 1.0.0, < 1.8.2"
+  - ">= 0.8.1, < 0.30.0"
+fixed_versions:
+  - "1.8.2"
+  - "0.30.0"
+severity: "high"
+exploit_status: "See official advisory; treat as SSRF-prone request construction bug"
+stack:
+  - "Axios"
+  - "Node.js"
+  - "frontend-backend bridge"
+attack_type:
+  - "ssrf"
+primary_source: "https://github.com/axios/axios/security/advisories/GHSA-jr5f-v2jv-69x6"
+secondary_sources: []
+target_types:
+  - "lab-local"
+  - "lab-public"
+  - "authorized-third-party"
+public_target_allowed: true
+authorization_required: true
+minimum_validation: "Use a lab service that joins user input with baseURL and validate only against controlled endpoints."
+prohibited_use: "Do not turn this into arbitrary external SSRF probing."
+---
+
+# Axios 绝对 URL / 协议相对 URL SSRF 映射
+
+## 事件层
+
+- 官方来源: [GHSA-jr5f-v2jv-69x6](https://github.com/axios/axios/security/advisories/GHSA-jr5f-v2jv-69x6)
+- 发布时间: 2025-03-07
+- 影响范围: 1.0.0 至 1.8.2 之前，0.8.1 至 0.30.0 之前
+- 修复版本: 1.8.2、0.30.0
+
+该问题的核心是：应用以为 `baseURL` 限定了请求目标，但当调用方允许用户传入绝对 URL 或协议相对 URL 时，实际请求可能被重定向到意料之外的位置。
+
+## 实验层
+
+### 适用目标类型
+
+- `lab-local`
+- `lab-public`
+- `authorized-third-party`
+
+### 实验思路
+
+1. 构造一个测试服务，内部代码类似 `axios.get(userInput, { baseURL: "http://internal-api.test" })`。
+2. 在隔离环境中把 `userInput` 分别替换为相对路径、绝对 URL 和协议相对 URL。
+3. 仅将目标指向你方控制的测试接收器，以验证请求是否越过预期边界。
+4. 升级到修复版本后再次比对行为，并决定是否显式设置 `allowAbsoluteUrls`。
+
+### 推荐的最小化验证
+
+- 所有验证都指向你方控制的测试接收器，而不是外部第三方站点。
+- 只记录是否越界、请求头差异和最终请求目的地。
+- 如果应用位于公网测试环境，优先在 staging 或隔离租户中复现。
+
+### 观测点
+
+- `baseURL` 是否被绝对 URL 或 `//host/path` 绕过
+- 服务端转发层、代理层和 allowlist 是否进一步放大风险
+- 是否有令牌、内部头或源地址信息随请求一并泄露
+
+## 回填建议
+
+- 将命中的代码模式加入依赖审查清单。
+- 对内部 HTTP 客户端封装统一限制“绝对 URL 输入”和“协议相对 URL”。

07-framework-security/frontend-js/cases/nextjs-ghsa-f82v-jwr5-mffw.md

@@ -0,0 +1,72 @@
+---
+title: "Next.js middleware authorization bypass mapping"
+published_date: "2025-03-21"
+affected_versions:
+  - ">= 11.1.4, < 13.5.9"
+  - ">= 14.0.0, < 14.2.25"
+  - ">= 15.0.0, < 15.2.3"
+fixed_versions:
+  - "13.5.9"
+  - "14.2.25"
+  - "15.2.3"
+severity: "critical"
+exploit_status: "See official advisory; treat as high-priority authorization bypass"
+stack:
+  - "Next.js"
+  - "middleware"
+attack_type:
+  - "authorization bypass"
+primary_source: "https://github.com/vercel/next.js/security/advisories/GHSA-f82v-jwr5-mffw"
+secondary_sources: []
+target_types:
+  - "lab-local"
+  - "lab-public"
+  - "authorized-third-party"
+public_target_allowed: true
+authorization_required: true
+minimum_validation: "Use an isolated vulnerable app and compare unauthorized access behavior before and after upgrading."
+prohibited_use: "Do not try bypass paths against unowned or unapproved public deployments."
+---
+
+# Next.js 中间件授权绕过映射
+
+## 事件层
+
+- 官方来源: [GHSA-f82v-jwr5-mffw](https://github.com/vercel/next.js/security/advisories/GHSA-f82v-jwr5-mffw)
+- 发布时间: 2025-03-21
+- 影响范围: 11.1.4 至 13.5.9 之前，14.0.0 至 14.2.25 之前，15.0.0 至 15.2.3 之前
+- 修复版本: 13.5.9、14.2.25、15.2.3
+
+该事件的关键点不是“某个单一路径绕过技巧”，而是把授权逻辑放在 Next.js middleware 中时，路径匹配、标准化或边界处理一旦出问题，就可能让前置授权失效。
+
+## 实验层
+
+### 适用目标类型
+
+- `lab-local`
+- `lab-public`
+- `authorized-third-party`
+
+### 实验思路
+
+1. 在隔离环境部署一个存在受保护路由的 Next.js 应用，例如 `/admin` 完全依赖 middleware 做访问控制。
+2. 保持后端业务处理层不做二次鉴权，以便观察“只靠 middleware”时的风险。
+3. 在易受影响版本与修复版本之间对比未授权访问表现。
+4. 把请求路径、重定向、状态码、缓存行为和服务端日志写入测试记录。
+
+### 推荐的最小化验证
+
+- 仅使用未授权访问对受保护路由做行为对比。
+- 只在实验环境或明确授权目标上复现官方公告所述边界问题。
+- 验证完成后立即升级到修复版本，并补上服务端二次鉴权。
+
+### 观测点
+
+- 仅依赖 middleware 保护的路由是否能被未授权访问
+- 反向代理、缓存层或重写规则是否放大了边界问题
+- 升级后是否仍存在“前置鉴权失效、后端无兜底”的设计风险
+
+## 回填建议
+
+- 若案例命中，应在 [测试记录模板](/Users/x/websafe/09-scope-and-targeting/test-record-template.md) 中记录修复前后差异。
+- 在 [08-threat-intel](/Users/x/websafe/08-threat-intel/subscription-catalog.md) 中把 Next.js 官方安全公告列为高优先级订阅源。