咖啡馆实战：网站接入 CDN 与 Nginx 反向代理后的权限边界、源站验证和日志留痕

发布于11分钟前11分钟

背景

网站接入 CDN、WAF 或其他加速器后，外部流量通常会经过“客户端—边缘节点—反向代理—应用服务”这条链路。配置不严谨时，常见问题不是加速效果，而是源站暴露、客户端地址可伪造、管理接口绕过鉴权，以及各层日志无法关联。

下面以已取得授权的网站为例，验证三个具体问题：源站是否能被直接访问、Nginx 是否错误信任 X-Forwarded-For、后台路径能否绕过边缘访问控制。测试前应明确目标域名、源站地址、允许测试的路径和时间窗口，不进行压力测试。

问题定位

假设公开域名为回源到 10.20.30.40:443，源站由 Nginx 转发至 127.0.0.1:8080。先从以下位置收集证据：

DNS 历史记录、证书透明度记录和运维资产清单，用于确认源站地址是否泄露。
CDN 回源地址段与 Nginx real_ip 配置，用于判断代理头是否可信。
Nginx access_log、应用审计日志和边缘请求日志，用于确认请求能否按 request_id 串联。
/admin、/internal、/metrics 等路径的鉴权位置，用于判断控制发生在边缘、源站还是应用层。

技术分析

CDN 并不会自动隐藏源站。如果安全组仍允许任意地址访问 80 或 443 端口，测试人员可以通过固定解析直接连接源站，并携带原站 Host 头访问应用。这会绕开部署在 CDN 上的 WAF、限速和路径规则。

另一个高频问题是无条件记录或使用 X-Forwarded-For。该请求头由客户端控制，只有请求确实来自可信代理时，最右侧或平台规定的地址字段才有意义。若应用依据该头判断“内网地址”“管理员来源”或生成审计日志，就可能产生权限绕过和日志污染。

验证目标应是证明边界配置是否失效，不应借此读取无关业务数据。后台接口返回 401、403、登录页或最小化的状态信息，通常已经足够形成结论。

操作步骤

一、验证源站是否可直接访问

优先使用 curl 的 --resolve 参数固定域名解析。这样可以保持 TLS SNI 与 Host 一致，避免直接访问 IP 时因证书或虚拟主机不匹配得到错误结论。

# 正常经公开 DNS 访问，保存响应头
curl -skD cdn.headers -o /dev/null 

# 在授权范围内将域名固定到源站地址
curl -skD origin.headers -o /dev/null \
  --resolve  \
  

# 比较状态码、Server、缓存头及自定义边缘标识
diff -u cdn.headers origin.headers

如果源站请求成功，且响应正文、会话行为与公开站点一致，说明源站入口至少没有严格限制回源来源。若 /admin 在 CDN 返回 403，而固定到源站后返回 200 或登录页，则可进一步确认边缘规则能够被绕过。

不要仅凭 Server 头判断是否绕过，因为该头可以修改。更可靠的证据包括：边缘请求日志中没有对应记录、源站日志中出现请求、响应中缺少 CDN 注入的请求标识，以及同一受控路径在两条链路上的访问控制结果不同。

二、检查代理地址信任边界

先发送带伪造转发头的普通请求，并记录测试时间和自定义 request_id：

RID="audit-$(date +%s)"

curl -sk \
  -H 'X-Forwarded-For: 127.0.0.1, 10.9.8.7' \
  -H "X-Request-ID: ${RID}" \
  

# 经授权登录服务器后查询对应日志
sudo grep -F "${RID}" /var/log/nginx/access.log
sudo journalctl -u webapp --since '10 minutes ago' | grep -F "${RID}"

重点观察 Nginx 的 remote_addr、http_x_forwarded_for 和 realip_remote_addr。如果 remote_addr 被改写为客户端提交的 127.0.0.1，说明 set_real_ip_from 范围可能过宽，或应用直接信任了未经清洗的代理头。

推荐同时记录原始连接地址、解析后的客户端地址和原始转发头，便于审计：

log_format audit escape=json
  '{"time":"$time_iso8601",'
  '"request_id":"$request_id",'
  '"peer_ip":"$realip_remote_addr",'
  '"client_ip":"$remote_addr",'
  '"xff":"$http_x_forwarded_for",'
  '"host":"$host",'
  '"request":"$request",'
  '"status":$status,'
  '"bytes":$body_bytes_sent,'
  '"upstream":"$upstream_addr",'
  '"upstream_status":"$upstream_status",'
  '"rt":$request_time}';

access_log /var/log/nginx/access.audit.log audit;

三、复核后台与内部接口的鉴权位置

分别经 CDN 和源站访问同一组低风险路径，只使用 GET 或 HEAD 请求。建议检查 /admin/、/metrics、/debug/、/actuator/health 和实际运维约定的内部路径，但应避免访问数据导出、任务执行和配置修改接口。

for path in /admin/ /metrics /actuator/health; do
  printf '\n== %s ==\n' "$path"
  curl -sk -o /dev/null -w 'edge  %{http_code} %{size_download}\n' \
    "
  curl -sk -o /dev/null -w 'origin %{http_code} %{size_download}\n' \
    --resolve  \
    "
done

如果只有边缘层限制后台路径，源站直连就可能绕过控制。正确做法是让应用或源站承担最终鉴权，CDN 和 WAF 只作为附加防护。IP 白名单不能替代登录认证，尤其不能基于客户端可控的 X-Forwarded-For 做授权。

关键配置建议

Nginx 仅应信任实际使用的 CDN 回源网段。下面的地址只是文档示例，部署时必须替换为供应商当前发布并经过核验的网段：

# 只信任明确的回源代理地址段，不要配置 0.0.0.0/0
set_real_ip_from 192.0.2.0/24;
set_real_ip_from 2001:db8:1234::/48;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

# 统一生成或传递请求标识
proxy_set_header X-Request-ID $request_id;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

若 CDN 使用专有客户端地址头，应确认该头会在边缘覆盖而不是追加，并确保源站只接受来自 CDN 地址段的连接。否则攻击者直连源站时可以自行构造同名请求头。

风险判断

现象	风险	建议级别
源站允许公网直连，但应用鉴权一致	可绕过边缘限速、缓存和部分检测	中
源站直连可绕过后台路径限制	管理面暴露，可能导致未授权访问	高
任意来源均可影响真实客户端地址	IP 鉴权绕过、审计失真、封禁规避	高
边缘与源站没有统一 request_id	事件调查困难，无法可靠还原链路	中

修复建议

在云安全组、防火墙或负载均衡器上，仅允许 CDN 官方回源网段访问源站 80、443 端口；管理端口通过 VPN、堡垒机或专用管理网络开放。
源站配置默认虚拟主机，对未知 Host 直接拒绝，避免 IP 直连落入业务站点。
后台和内部接口在应用层实施会话认证、细粒度授权及必要的多因素认证，不把 CDN 路径规则当作唯一控制。
只对可信代理启用 real_ip 模块，定期同步 CDN 地址段；对不可信连接删除或覆盖 X-Forwarded-For 等头。
边缘、Nginx 和应用统一记录 request_id、原始连接地址、解析后客户端地址、状态码、上游状态和耗时；日志集中保存并限制修改权限。
修复后重复执行固定解析测试和伪造请求头测试，同时确认公网直连被网络层拒绝，而不是仅返回一个可绕过的应用错误页。

总结

网站加速链路的核心不是简单隐藏源站，而是明确每一层能信任什么。源站入口应只信任实际回源节点，客户端地址只能由可信代理解析，最终权限判断应落在源站或应用层。验证时用 --resolve 对比访问路径、用 request_id 串联日志，再结合安全组和 Nginx 配置复核，通常能较快定位源站绕过、代理头污染与审计断链问题。

登录