渗透攻防实战：反向代理信任边界错误导致的来源 IP 鉴权绕过验证与修复

背景在授权渗透测试中，常见架构是客户端经过 CDN、负载均衡或 Nginx，再访问后端管理接口。后端为了获取真实来源 IP，往往直接读取 X-Forwarded-For 或 X-Real-IP，并据此放行内网地址。问题在于：这些请求头本质上由客户端提供，只有经过受信代理清洗并重写后才可用于鉴权。本文以一个管理接口仅允许 10.20.0.0/16 访问的场景为例，说明如何在不扩大影响面的前提下验证信任边界、定位责任层，并给出 Nginx 与应用侧的修复方法。测试仅应在书面授权范围内进行。场景与初步现象目标入口为 Nginx 转发至 10.30.5.17:8080。访问 /admin/health 时，正常外网请求返回 403；添加来源 IP 请求头后返回 200。此时不能直接断定漏洞成立，还要排除缓存、前端路由差异和偶发会话状态。curl -sk -o /dev/null -w '%{http_code}\n' \

curl -sk -o /dev/null -w '%{http_code}\n' \
-H 'X-Forwarded-For: 10.20.1.25' \

curl -sk -o /dev/null -w '%{http_code}\n' \
-H 'X-Real-IP: 10.20.1.25' \
403、200、403，可初步判断后端主要信任 X-Forwarded-For。问题定位：确认到底是哪一层信任了伪造头第一步是对多个头及地址格式做最小化差分测试。重点不是穷举绕过字符串，而是确认应用取值规则：取列表首项、末项，还是仅使用代理计算后的连接地址。for value in \
'10.20.1.25' \
'198.51.100.44, 10.20.1.25' \
'10.20.1.25, 198.51.100.44' \
'198.51.100.44'; do
printf '%-36s '

这类问题的关键不是“是否读取了 X-Forwarded-For”，而是只有经过可信代理的请求，才允许该头参与客户端 IP 计算。建议先分别从直连入口和反代入口验证，避免只在正常链路里测试：

# 尝试绕过代理直连源站，并伪造来源地址
curl -vk --resolve app.example.com:443:源站IP \
  -H 'X-Forwarded-For: 10.0.0.8' \
  

# 经过正式代理发送相同伪造头，观察代理是否覆盖而不是透传
curl -vk -H 'X-Forwarded-For: 10.0.0.8' \
  
Nginx 源站侧应显式限定可信代理网段，不要配置成 set_real_ip_from 0.0.0.0/0；同时源站安全组只放行反向代理地址：
set_real_ip_from 10.20.0.0/16;   # 实际反代节点网段
real_ip_header X-Forwarded-For;
real_ip_recursive on;

location /admin {
    allow 10.30.0.0/16;
    deny all;
}
代理侧建议覆盖客户端传入的转发头；如果后端并不需要完整代理链，直接传入连接对端地址更容易审计：
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP       $remote_addr;
如果必须保留多级代理链，可使用 $proxy_add_x_forwarded_for，但每一级都要有明确的信任范围，应用也应使用框架提供的“可信代理”配置，而不是手工取列表最左侧。排查时建议临时同时记录原始连接地址、原始头和解析后的地址：
log_format iptrace '$time_iso8601 peer=$remote_addr '
                   'xff="$http_x_forwarded_for" realip=$realip_remote_addr '
                   'uri=$request_uri status=$status';
修复后的验收标准至少包括三项：源站无法被公网直连；客户端自带的 X-Forwarded-For 不能改变鉴权结果；多级代理增删节点后，日志中的连接地址和最终解析地址仍能对应。长期看，管理接口只靠来源 IP 鉴权偏弱，最好再叠加 mTLS、VPN 身份或应用层认证。