解读

在国内 CouchDB 生产环境中，_users 库 保存了所有账号、角色与密码哈希，是权限治理的核心。一旦允许匿名读取，攻击者可直接拖库撞库，进而横向移动到其他系统。因此面试官想确认两点：

1. 你是否知道 CouchDB 的默认安全策略；
2. 你能否用最轻量级、可脚本化的手段给出“铁证”，而不是简单地说“看文档”。

知识点

• CouchDB 安全层级：服务器级 → 数据库级 → 文档级，_users 库默认带有 members.roles = [] 与 admins.roles = []，即拒绝任何人（包括匿名）的读/写。
• 认证方式：Basic Auth、Cookie（Set-Cookie: AuthSession）、JWT（企业版扩展）。
• 匿名请求特征：不带 Authorization 头且未携带有效 AuthSession Cookie。
• 关键返回码：
  – 401 Unauthorized：匿名被挡，符合预期；
  – 200 OK：匿名可访问，属于高危配置失误。
• 国内合规：等保 2.0 要求“默认拒绝”，若 200 出现即视为高风险项，需立即整改。

答案

1. 零配置验证（最常用）
   在一台可直连 CouchDB 的测试机执行：

   curl -D - http://<host>:5984/_users
   

   若返回头包含 HTTP/1.1 401 Unauthorized 且正文 "error":"unauthorized"，即证明匿名已被拒绝；若返回 200 则违规。

2. 带凭据对比（排除网络层误报）
   先创建临时管理员：

   curl -X PUT http://<host>:5984/_node/_local/_config/admins/interview \
        -d '"Test@123!"'
   

   再分别执行：

   # 匿名
   curl -D - http://<host>:5984/_users
   # 带权
   curl -u interview:Test@123! http://<host>:5984/_users
   

   只有后者返回 200 即可交叉验证：_users 库仅对认证用户开放。

3. 自动化脚本（适合 CI）

   #!/bin/bash
   CODE=$(curl -o /dev/null -s -w "%{http_code}" http://localhost:5984/_users)
   [ "$CODE" = "401" ] && echo "PASS: 匿名被禁止" || echo "FAIL: 匿名可访问"
   

   将该脚本接入 GitLab-CI，每次镜像构建后自动巡检，满足国内 DevSecOps 审计要求。

拓展思考

• “禁止匿名” ≠ “禁止读取”：若业务需要开放注册，可将 _users/security 中的 members.names 设为 "all"，但务必同步开启 HTTPS 并做 WAF 限流，防止批量撞库。
• 云厂商托管版（如阿里云 CouchDB）可能把 _users 映射到控制台子账号体系，此时 401 不一定来自 CouchDB 本身，需结合 X-CouchDB-Header 追踪真实来源。
• 渗透测试场景：可进一步尝试 /_users/_all_docs?include_docs=true 与 /_users/_changes 两个高危端点，若任一返回 200，即可判定数据库级权限失守，需立即上报安全团队并触发应急响应。