【juice-shop】★ Exposed Metrics：暴露的监控指标
目录
【juice-shop】★ Exposed Metrics：暴露的监控指标
0x01 任务简报
💡 核心线索 (Hints)
- 尝试猜测后端可能使用什么 URL。
- 果汁店将指标数据发布在 Prometheus 预期的默认路径上。
- 猜测路径的速度，可能和查阅 Prometheus 官方文档 一样快。
0x02 实战：复现漏洞
根据提示，线索指向 Prometheus 文档。快速翻阅文档后，找到了 Prometheus 暴露指标的默认路径，直接访问：
http://127.0.0.1:3000/metrics页面成功返回了大量监控数据，漏洞确认。
0x03 源码审计：编码挑战
🔍 找到它 (Find It)
漏洞位于第 4 行：/metrics 路由没有任何鉴权中间件，所有人（包括未登录用户）均可直接访问。
🛠️ 修复它 (Fix It)
| 选项 | 处理方式 | 安全评价 | 结论 |
|---|---|---|---|
| Fix 1 | security.denyAll() |
❌ 彻底封死，管理员也无法访问，功能被破坏 | 矫枉过正 |
| Fix 2 | security.isAdmin() |
✅ 只有管理员可访问，功能保留，权限收紧 | 真·修复 |
| Fix 3 | metrics.serveMetrics() |
❌ 端点还在，数据只是停止更新，漏洞依然存在 | 钝角（啥都没干） |
Fix 2 才是正确答案的原因：安全修复的目标是"让正确的人能访问，让不该访问的人无法访问"，而不是把功能一刀切掉。denyAll 是懒惰式修复——它确实消除了漏洞，但同时也把合理的需求一起毁掉了，实际工程中不可接受。
三个选项的防护强度排序：denyAll > isAdmin > 无防护（原始漏洞）。