网站数据安全核心之SQL注入防护指南

SQL注入至今仍是网站数据泄露事故里占比最高的攻击方式之一。很多人以为只有老旧系统才会中招，实际上近年暴露的案例里，不少用了现代框架的项目依然被注入成功，原因不在工具本身，而在开发者对拼接点的判断失误。要真正防住SQL注入，必须理解它的触发条件不是“使用了数据库”，而是“把不可信输入当成了SQL语句的一部分执行”。

SQL注入的本质是输入数据改变了SQL语句的语法结构。比如登录验证时，如果代码写成“SELECT * FROM users WHERE username='$user' AND password='$pass'”，当用户输入的用户名是 admin' -- ，整个语句就变成只校验用户名而不校验密码。这个单引号闭合了原本的字符串，两个减号把后面的条件注释掉了。攻击者不需要知道数据库结构，只需要判断哪个参数能影响语句逻辑，然后逐层试探。

预编译语句（Prepared Statement）是目前最有效的防注入手段。它的原理是把SQL语句结构和数据分开处理，数据库先解析语句模板，再把用户输入当作纯参数绑定进去，参数永远不可能改变语法。以Java的JDBC为例：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, username);
ps.setString(2, password);
ResultSet rs = ps.executeQuery();

这里的问号是占位符，setString方法传入的值即使包含单引号、分号或注释符，也只会被当作字符串内容处理。PHP的PDO、Python的PyMySQL、Go的database/sql都支持类似机制。需要注意，预编译不是简单地把引号转义，转义方案历史上被绕过太多次，不能作为主要防线。

很多团队认为用了Hibernate、MyBatis、Entity Framework这类ORM就安全了，这是常见误区。ORM生成的常规查询确实会参数化，但涉及动态排序、动态表名、动态分组字段时，开发者往往为了灵活直接拼接字符串。例如MyBatis里使用${}而不是#{}，就会把参数直接嵌入SQL文本。正确的做法是：所有值类型的参数一律使用#{}，对于必须动态变化的表名或字段名，采用白名单校验，从预设的合法集合中选择，而不是接收用户原始输入。

存储过程并不天然免疫SQL注入。如果存储过程内部使用EXEC或拼接字符串执行动态SQL，外部传入的参数照样可以改变执行逻辑。例如SQL Server中“EXEC('SELECT * FROM users WHERE name=''' + @name + '''')”就是典型的危险写法。存储过程的安全性和普通代码一样，取决于是否对输入进行了参数化处理。

很多教程教人过滤单引号、删除SELECT、屏蔽UNION等关键字，这种方法有两个问题。第一，过滤规则很难穷尽，攻击者可以用十六进制编码、双重编码、大小写混合、注释符插入等方式绕过。第二，过度过滤会影响正常用户输入，比如用户昵称里包含单引号或“select”字样时会被误伤。正确的思路是：输入过滤用于业务规则校验，比如手机号必须是数字、邮箱必须符合格式，而SQL安全交给预编译处理。两者职责不同，不能互相替代。

攻击者在探测注入点时，很大程度上依赖数据库返回的错误信息来判断语法是否正确、字段数量是多少、表名是什么。生产环境必须关闭详细错误回显，将数据库错误记录到服务端日志，前端只显示统一的友好提示。但关闭错误显示不等于修复注入，只是增加攻击难度。如果代码本身存在注入点，攻击者依然可以通过盲注、时间延迟等手法获取数据，只是效率低一些。

很多网站的应用数据库账号拥有root或db_owner权限，一旦被注入，攻击者可以直接读取系统表、执行系统命令或拖走整库。正确做法是为每个应用创建独立数据库账号，只授予必要的SELECT、INSERT、UPDATE、DELETE权限，不授予DDL权限和系统存储过程执行权限。对于敏感表，比如用户密码和支付记录，可以进一步使用视图或字段级权限控制。这样即使某个查询点被注入，攻击者能接触的数据范围也受到限制。

有一种容易被忽视的情况是二次注入。用户输入在第一次入库时被参数化处理，安全存入数据库，但后续某个功能读取该数据后，又将其拼接到新的SQL语句中执行。比如用户注册时昵称设置为“test' OR '1'='1”，注册本身安全，但后台某个统计功能把昵称直接拼进查询条件，就会触发注入。防止二次注入的关键是：任何从数据库读出的数据，在进入新的SQL语句时，同样必须参数化处理。数据来源是否可信，不取决于它是否已经存在数据库里，而取决于它是否可能曾经来自用户输入。

Web应用防火墙可以拦截大量自动化注入尝试，对已知攻击特征有较好的识别率。但WAF是黑名单思路，面对新型绕过手法或业务逻辑层面的注入时可能失效。WAF适合作为纵深防御的一层，不能因为部署了WAF就放弃代码层面的修复。安全团队应当定期分析WAF拦截日志，反向定位应用中的真实注入点，推动开发修复。

要确认系统是否存在SQL注入，不能只靠扫描器。扫描器能发现一部分明显漏洞，但业务逻辑复杂的地方往往需要人工验证。常见的验证手法包括：在参数值后追加单引号观察是否报错，追加“AND 1=1”与“AND 1=2”对比返回结果差异，使用“ORDER BY 数字”判断列数，使用UNION SELECT判断可回显字段位置。对于盲注场景，可以使用“AND SLEEP(5)”或“WAITFOR DELAY”观察响应时间。这些测试应当在测试环境或授权范围内进行。

SQL注入防护不能只靠上线前扫描，需要在开发阶段就建立规范。代码评审时重点关注所有SQL执行点，检查是否使用了参数化，是否存在字符串拼接。对于动态SQL，要求开发人员说明拼接来源并展示白名单校验逻辑。CI/CD流水线中可以集成静态代码扫描工具，自动标记可疑的拼接模式。测试阶段增加安全用例，覆盖特殊字符、超长输入、编码绕过等场景。

数据库安全是一个体系，SQL注入只是其中一环，但这一环处理不好，其他安全措施可能被直接绕过。核心原则只有一条：永远不要把用户输入当作SQL代码执行。围绕这个原则，预编译是主要手段，最小权限和错误处理是辅助防线，WAF和日志监控是补充层。把这几个层面落实到位，SQL注入的风险可以降到很低的水平。