复合型网络攻击中SQL注入防护应对技巧

复合型网络攻击里，SQL注入几乎不会单独出现。攻击者通常把它当作突破点，配合XSS、CSRF、文件包含、提权漏洞甚至社会工程学一起打。单纯依赖WAF规则或者手工过滤单引号，已经挡不住这种组合拳。真正有效的防护思路，是把SQL注入放在“攻击链”里看，而不是当成孤立漏洞来修。

先看一个典型场景：攻击者通过一个存在反射型XSS的搜索框，诱导管理员点击携带恶意SQL片段的链接。WAF可能对直接发往数据库的请求有拦截，但对经过浏览器拼接、二次编码或JavaScript动态生成的SQL语句毫无感知。这种“前端拼SQL”的旧代码模式，在复合攻击里是最容易被利用的薄弱环节。所以第一件事不是急着加过滤函数，而是排查应用里所有拼接SQL的位置，尤其是那些数据流从浏览器到服务器再回到浏览器、最终又进入数据库的链路。

很多人以为参数化查询就是“用PreparedStatement代替Statement”，但复合攻击会从非常规入口进入。比如HTTP头里的User-Agent、Referer、X-Forwarded-For，日志系统记录后可能被后台报表模块拼进SQL；又比如上传文件的文件名、EXIF信息、压缩包内目录名，解压入库时如果走拼接，同样触发注入。防护要点是：凡是外部输入，无论来自GET、POST、Cookie、Header还是文件元数据，一律参数化。不能因为某个字段“看起来可信”就跳过。

以Java JDBC为例，正确做法不是手动拼字符串：

String sql = "SELECT * FROM orders WHERE user_id = " + request.getParameter("uid");

而应该是：

String sql = "SELECT * FROM orders WHERE user_id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setInt(1, Integer.parseInt(request.getParameter("uid")));

参数化查询的价值在于把SQL逻辑与数据彻底分离，数据库驱动会负责转义和类型绑定，攻击者无法通过输入改变SQL语法结构。但注意，参数化不能用于表名、列名、ORDER BY方向这类标识符。如果业务确实需要动态排序，必须做白名单映射，例如只允许“id”“create_time”“amount”三个列名，其他输入直接拒绝。

有些团队认为“用了存储过程就安全”，这是错误认知。如果存储过程内部使用EXEC、sp_executesql或者拼接字符串再执行，注入风险完全一样。复合攻击中，攻击者可能先通过低权限注入拿到存储过程名称和参数结构，再构造针对存储过程内部动态SQL的载荷。审计时要把存储过程代码纳入扫描范围，检查所有EXEC和sp_executesql调用点。

复合攻击经常利用二次注入。攻击者第一次提交的恶意数据被安全存储，比如用户昵称设置为“admin'--”，注册时过滤函数可能做了转义，存入数据库的是“admin''--”。但后续某个功能读取这个昵称，拼进新的SQL语句时，如果没有再次转义，原本被转义的单引号又恢复成有效语法。防护原则是：数据在进入数据库前做一次转义或参数化，从数据库读出后再次进入SQL前，必须重新参数化或转义。不能假设“数据库里的数据是安全的”。

编码绕过更常见。WAF可能拦截“union select”，但攻击者用URL双重编码、Unicode编码、十六进制表示、注释符穿插等方式绕过。例如“uni//on sel//ect”在某些宽松规则下能穿透。所以不能依赖黑名单关键字过滤。如果必须使用WAF，要开启规范化解码功能，并在应用层再做一次输入校验。应用层校验的重点不是“拦截恶意字符串”，而是“只允许预期格式”。比如用户ID只允许数字，邮箱只允许正则匹配的格式，排序字段只允许白名单值。

攻击者在组合攻击中，第一步往往是探测数据库类型、表结构、字段名。如果应用直接返回数据库错误堆栈，等于把内部信息送出去。生产环境必须关闭详细错误回显，统一返回模糊错误页面。但仅仅关闭回显不够，还要在日志中记录完整错误信息供安全团队分析。同时，应用层要主动捕获SQLException，避免框架默认行为把敏感信息写入响应体。对于API接口，返回JSON错误时同样不能包含SQL语句或数据库连接信息。

复合攻击里，SQL注入常被用来读取管理员密码哈希、拖库、写Webshell。如果数据库账号权限过大，攻击者一步到位。防护上要拆分数据库账号：前台业务只用SELECT和必要的INSERT/UPDATE，后台管理功能使用独立账号，且禁止使用sa、root、dba这类高权限账号连接应用。对于需要执行DDL或文件操作的场景，单独建立受限账号并限制来源IP。MySQL下可以撤销FILE权限，防止INTO OUTFILE写文件；SQL Server下禁用xp_cmdshell等危险存储过程。

既然攻击是复合型的，防护也要复合。XSS与SQL注入结合时，重点防护输入输出两端：输入做严格类型校验，输出做上下文相关编码。CSRF与SQL注入结合时，关键操作加CSRF Token，避免攻击者诱导管理员执行恶意SQL操作。文件上传与SQL注入结合时，上传目录禁止执行脚本，文件名入库前做参数化处理，并对文件内容做病毒扫描。任何一个单点漏洞被堵住，整条攻击链就可能断裂。

实际案例中，攻击者通过上传一个名为“test.jpg”的文件，文件名中包含SQL片段，应用将文件名存入数据库时使用拼接，导致注入。修复时除了参数化，还应该对文件名做随机重命名，彻底切断“文件名进入SQL”这条路径。这说明防护不能只盯着传统输入框，所有数据入口都要纳入统一输入验证框架。

复合攻击往往分阶段进行，早期会有大量探测请求。如果日志里出现高频的“'”、“--”、“union”、“sleep”等模式，即使WAF没拦下来，也应该触发告警。建议在应用层记录所有SQL执行时间，超过阈值的查询（如超过1秒）单独标记，因为盲注通常依赖sleep或benchmark函数制造时间差。同时监控数据库错误日志，频繁的语法错误可能意味着注入尝试。安全团队要建立基线，区分正常业务波动和攻击行为。

防护技巧最终要落实到代码层面。每季度至少做一次针对SQL注入的专项代码审计，重点检查新上线的功能模块。自动化扫描工具能发现一部分问题，但复合攻击中的逻辑漏洞需要人工分析数据流。渗透测试要模拟真实攻击链，尝试从XSS跳到SQL注入，或者从文件上传跳到SQL注入，验证整体防护是否有效。测试环境尽量与生产一致，避免“测试环境没漏洞、生产环境被打穿”的情况。

最后强调一个容易被忽略的点：数据库连接池配置。如果连接池使用固定账号且应用存在SQL注入，攻击者可以复用这个连接执行任意SQL。建议连接池账号只授予最小权限，并且对连接串中的账号做定期轮换。同时，数据库本身要开启审计功能，记录所有DDL和DML操作，便于事后溯源。

SQL注入防护在复合攻击背景下，核心思路是从“单点过滤”转向“全链路数据流管控”。参数化查询是基础，输入验证是补充，权限最小化是兜底，日志监控是眼睛。只有把这些措施串起来，才能在攻击者组合拳打过来时，不至于第一波就被突破。