防止SQL注入的核心思路不是单靠一层防御，而是把应用层的关键字拦截和数据库层的权限管控、参数化查询联动起来，形成一套纵深防御体系。具体做法是：在应用层对用户输入做正则过滤和关键字黑名单检测，同时在数据库层通过参数化查询（PreparedStatement）、最小权限原则、存储过程封装等手段，让即使绕过应用层的恶意SQL也无法真正执行破坏性操作。下面我会把这套方案从原理到落地，一步步讲清楚。
一、为什么单靠应用层拦截不够
很多开发团队觉得在前端或后端加一个关键字过滤就万事大吉了，比如把"DROP"、"UNION"、"SELECT"这些词全部屏蔽掉。但这种做法有三个致命缺陷：第一，攻击者可以用大小写混写、双写绕过（比如"SeLeCt"）、URL编码、十六进制编码等方式绑过关键字检测；第二，有些正常业务输入本身就包含类似关键字的内容，比如用户名叫"O'Connor"，直接拦截会误杀；第三，应用层的代码一旦被逆向或者出现逻辑漏洞，过滤规则就形同虚设。所以，应用层拦截只能作为第一道防线，绝不能是唯一防线。
二、应用层关键字拦截的正确姿势
应用层拦截要做得聪明，不能简单粗暴地做字符串匹配。正确的做法是分三步走：
第一步，建立动态关键字库。不只是"DROP"、"DELETE"这种明显的危险词，还要包含"OR 1=1"、"WAITFOR DELAY"、"xp_cmdshell"等变形攻击模式。关键字库需要定期更新，根据最新的攻击样本来补充。
第二步，使用正则表达式做模式匹配，而不是简单的字符串包含。比如下面这段Java代码，用正则去匹配常见的SQL注入模式：
public boolean isSqlInjection(String input) {
String[] patterns = {
"(?i)(\\\\b(union|select|insert|update|delete|drop|alter|create|truncate|exec|execute)\\\\b)",
"(?i)(\\\\b(or|and)\\\\s+\\\\d+\\\\s*=\\\\s*\\\\d+)",
"(?i)(--|;|\\\\/\\\\*|\\\\*\\\\/|\\\\bxp_\\\\w+)",
"(?i)(\\\\bwaitfor\\\\s+delay\\\\b)",
"(?i)(\\\\bchar\\\\s*\\\\(\\\\s*\\\\d+\\\\s*\\\\))"
};
for (String pattern : patterns) {
if (Pattern.compile(pattern).matcher(input).find()) {
return true;
}
}
return false;
}
第三步，拦截之后要做安全处理，而不是直接拒绝。对于可疑输入，可以做HTML实体编码、转义特殊字符后再传入下一层。对于明确的恶意输入，直接返回错误提示并记录日志。
三、数据库层联动防御的四大核心手段
应用层拦截是"拦"，数据库层联动是"防"。即使有恶意SQL穿透了应用层，数据库层也要让它执行不了、破坏不了。具体有四个核心手段：
1. 参数化查询（PreparedStatement）彻底杜绝拼接
这是最重要的一条。参数化查询的本质是把SQL语句的结构和数据分开传输，数据库引擎在编译阶段就确定了SQL结构，用户输入的内容只会被当作参数绑定，永远不会被当作SQL指令执行。下面是Java中使用PreparedStatement的示例：
// 错误写法：字符串拼接，存在SQL注入风险 String sql = "SELECT * FROM users WHERE username = '" + username + "'"; // 正确写法：参数化查询 String sql = "SELECT * FROM users WHERE username = ?"; PreparedStatement ps = connection.prepareStatement(sql); ps.setString(1, username); ResultSet rs = ps.executeQuery();
不管username里写什么，哪怕是"' OR '1'='1"，数据库也只会把它当成一个普通字符串去匹配，不会改变SQL的逻辑结构。这一招能挡住99%以上的SQL注入攻击。
2. 数据库最小权限原则
应用程序连接数据库时，不要用root或者sa这种最高权限账号。应该为每个应用模块创建独立的数据库用户，只授予它完成业务所需的最小权限。比如一个只做查询的模块，就只给SELECT权限；一个需要写数据的模块，只给对应表的INSERT、UPDATE权限，绝对不给DROP、ALTER、TRUNCATE权限。这样即使攻击者注入了恶意SQL，由于权限不够，也执行不了破坏性操作。
-- 创建只读用户 CREATE USER 'app_readonly'@'%' IDENTIFIED BY 'StrongPass123!'; GRANT SELECT ON mydb.orders TO 'app_readonly'@'%'; GRANT SELECT ON mydb.products TO 'app_readonly'@'%'; FLUSH PRIVILEGES; -- 创建写操作用户（不给DROP权限） CREATE USER 'app_writer'@'%' IDENTIFIED BY 'StrongPass456!'; GRANT SELECT, INSERT, UPDATE ON mydb.orders TO 'app_writer'@'%'; -- 注意：不授予 DROP、ALTER、TRUNCATE、CREATE 权限
3. 存储过程封装业务逻辑
把核心的数据库操作封装成存储过程，应用层只调用存储过程名和传入参数，不直接拼接SQL。存储过程内部的逻辑对应用层是不可见的，攻击者即使知道存储过程名，也无法通过参数注入来改变存储过程内部的SQL结构。比如：
-- 创建存储过程
DELIMITER //
CREATE PROCEDURE GetUserByName(IN p_username VARCHAR(50))
BEGIN
SELECT id, username, email FROM users WHERE username = p_username;
END //
DELIMITER ;
-- 应用层调用（参数化）
CALL GetUserByName(?);
这种方式特别适合复杂业务场景，比如订单处理、支付流程等，把SQL逻辑锁在数据库里，应用层只负责传参。
4. 数据库层面的输入校验和审计
在数据库层面也可以加一道防线。比如MySQL可以通过触发器（Trigger）来监控异常操作，当检测到某个用户在短时间内执行了大量查询或者尝试了敏感操作时，自动触发告警甚至临时锁定该账户。同时，开启数据库的慢查询日志和审计日志，记录所有SQL执行情况，方便事后追溯和分析。
四、应用层和数据库层联动的架构设计
真正有效的防SQL注入方案，是把上面说的所有手段串成一条链。我推荐的架构是这样的：
第一层：前端输入校验。在用户提交表单时，前端做基本的格式校验，比如长度限制、特殊字符提示，但不要依赖这一层做安全防护，因为前端代码可以被绕过。
第二层：后端应用层拦截。通过正则匹配关键字、编码检测、参数类型校验等手段，过滤掉明显的恶意输入。这一层要记录所有被拦截的请求，用于后续分析攻击趋势。
第三层：参数化查询 + 存储过程。所有数据库操作必须走参数化查询或者存储过程调用，禁止任何形式的SQL字符串拼接。这是硬性规定，代码审查时要重点检查。
第四层：数据库权限管控。每个应用模块使用独立的低权限数据库账户，敏感操作需要二次验证。
第五层：监控与告警。通过数据库审计日志、WAF（Web应用防火墙）联动、异常行为检测等手段，实时发现和响应攻击行为。
五、容易被忽视的几个细节
第一，ORM框架不等于绝对安全。很多人觉得用了MyBatis、Hibernate就不会SQL注入了，但如果在MyBatis里用了${}而不是#{}，照样会注入。${}是直接拼接字符串，#{}才是参数化。这个细节很多人踩坑。
第二，二次注入问题。有些场景下，用户输入先被存进数据库，后续从数据库读出来再拼接到SQL里使用，这时候如果没有做转义，就会触发二次注入。解决办法是：从数据库读出的数据，在再次用于SQL时，同样要走参数化查询，不能直接拼接。
第三，编码问题导致的绕过。攻击者可能用UTF-8编码、Unicode编码、URL编码等方式来隐藏关键字。应用层的拦截规则要考虑到这些编码形式，在检测前先做统一的解码处理。
第四，日志脱敏。记录被拦截的恶意输入时，不要把完整的攻击载荷明文存到日志里，防止日志本身成为信息泄露的渠道。应该只记录攻击类型、时间、来源IP等摘要信息。
六、总结与建议
防止SQL注入从来不是一个单一技术能解决的问题，而是一个系统工程。应用层的关键字拦截是"第一道门"，能挡住大部分自动化扫描和初级攻击；数据库层的参数化查询、最小权限、存储过程是"核心堡垒"，让穿透的攻击也无计可施；监控审计是"眼睛"，让你知道有没有人在尝试攻击。三者联动，才能构建真正有效的防御体系。建议团队在开发规范里明确禁止SQL拼接，代码审查时把SQL注入作为必检项，同时定期做安全渗透测试来验证防御效果。安全这件事，没有一劳永逸，只有持续迭代。
