SQL注入攻击的常见误区是什么？正确防御的思路

正确防御SQL注入需多层措施，包括参数化查询、最小权限原则、输入验证和输出编码。参数化查询将SQL结构与数据分离，防止恶意SQL执行；ORM框架非万能，滥用原生SQL仍存风险；数据库账号应遵循最小权限原则，限制潜在损害；输入验证与输出编码可作为补充防护；定期安全审计与渗透测试能发现未知漏洞，确保系统持续安全。

SQL注入攻击的常见误区在于认为只要过滤了单引号就能高枕无忧，或者过度依赖ORM框架而忽略了底层SQL语句的安全问题。正确的防御思路是多层防御，包括参数化查询、最小权限原则、输入验证和输出编码。

参数化查询/预编译语句

很多人认为只要简单地转义特殊字符，比如单引号、双引号等，就能防止SQL注入。但实际上，这种方法很容易被绕过，而且容易出错。

误区一：只过滤特殊字符就够了

参数化查询（也称为预编译语句）才是王道。它将SQL语句的结构和数据分开处理，SQL引擎会预先编译SQL语句，然后将参数作为数据传递给SQL引擎。这样，即使参数中包含SQL关键字，也不会被当做SQL语句来执行，而是被当做普通的数据。

例如，在Java中使用JDBC的PreparedStatement：

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

在Python中使用psycopg2：

sql = "SELECT * FROM users WHERE username = %s AND password = %s"cursor.execute(sql, (username, password))

这些代码示例中，

?

或

%s

都是占位符，实际的用户名和密码会作为参数传递给数据库，而不是直接拼接到SQL语句中。这从根本上避免了SQL注入的风险。

误区二：ORM框架是万能的

ORM框架，如Hibernate、MyBatis、Django ORM等，可以简化数据库操作，但并不能完全杜绝SQL注入。如果在使用ORM框架时，仍然使用字符串拼接的方式构建SQL语句，或者使用了ORM框架提供的原生SQL查询功能，那么仍然存在SQL注入的风险。

例如，在使用Hibernate时，如果使用HQL或Criteria查询，通常可以避免SQL注入。但是，如果使用

session.createSQLQuery()

方法执行原生SQL查询，那么就需要格外小心。

String username = request.getParameter("username");String sql = "SELECT * FROM users WHERE username = '" + username + "'"; // 存在SQL注入风险SQLQuery query = session.createSQLQuery(sql);List