X-Forwarded-For头是ERP系统高危入口，因其常被未校验地拼入SQL（如明源Service.asmx日志写入），叠加IP列表含逗号/换行、缺乏类型转换与长度限制，易触发注入；须在接入层（Nginx截首IP）、应用层（IP合法性校验）、数据层（强制PreparedStatement）分层设防，并审计原始头值与调用栈快照。
直接说结论：针对ERP系统的SQL注入，不能只靠一层过滤或一个WAF规则解决。必须在数据进入数据库前的每个关键节点做校验，在每次关键操作后做审计，否则攻击者总能找到绕过路径。
为什么X-Forwarded-For头是ERP系统里的高危入口
很多房地产ERP（比如明源Service.asmx接口）会把X-Forwarded-For头直接写入日志表或用于租户路由判断，但没做类型转换或长度限制。它本该是IP格式字符串，却被当成可执行上下文处理。
- 典型错误逻辑：
INSERT INTO audit_log (client_ip) VALUES ('127.0.0.1, 192.168.0.5')→ 攻击者发X-Forwarded-For: 127.0.0.1', (SELECT SLEEP(5))-- - 负载均衡器转发时可能叠加多个IP，导致原始值含逗号、空格、换行符，未经清洗就拼接进SQL极易触发注入
- Java/.NET中若用
request.getHeader("X-Forwarded-For")后直接传给Statement.execute()，等于主动开放SQL执行通道
分层校验该在哪几层做，每层做什么
不是“加个过滤器就完事”，而是按请求流转顺序逐层设防：
-
接入层（反向代理/网关）：用Nginx或API网关做基础清洗，例如用
map指令截取第一个IP，丢弃逗号后全部内容；禁止X-Forwarded-For含单引号、分号、--、/* -
应用层（业务代码）：收到
X-Forwarded-For后，先调用InetAddress.getByName()（Java）或ipaddress.ip_address()（Python）做合法性校验，失败则拒绝请求；绝不允许该字段参与SQL拼接 -
数据访问层：所有DAO方法强制使用
PreparedStatement，对IP类字段统一用setString()，禁用executeUpdate(String sql)这类裸SQL接口
安全审计不能只查“谁改了数据”，要盯住“谁用了什么输入”
ERP审计常忽略请求头类输入源，导致X-Forwarded-For注入行为无法回溯。真正有效的审计日志必须包含：
- 记录原始
X-Forwarded-For值（非清洗后值），并标记是否触发过校验失败 - 每条数据库操作日志附带调用栈中的HTTP头快照，至少包括
X-Forwarded-For、User-Agent、Referer - 对
audit_log表本身加触发器，当插入含'或;的client_ip时自动告警——这说明某层校验被绕过了
最易被忽略的一点：很多ERP系统把X-Forwarded-For写进数据库后，后续报表导出功能又把它原样拼进另一个SQL查询里。校验只做一次，不等于全程安全。
