如何从根本上防止 SQL 注入？
虎哥约 5 分钟大家好，我是虎哥。
SQL注入，这个老生常谈的话题依然是许多项目中的隐患，尽管它的解决方案早已存在，但问题依旧层出不穷。
作为一个开发工程师，我常常遇到这个问题。很多人会问，SQL注入的危害为什么不能从根本上杜绝？今天我们就来从技术角度聊聊如何防止SQL注入，以及为什么这种问题多年来依然存在。
首先，SQL注入本质上是由于程序在执行SQL语句时，用户输入的数据未被妥善处理，结果这些输入意外成为了执行的代码。
SQL注入就是黑客利用系统的漏洞，输入恶意的SQL语句，让这些数据不再仅仅是数据，而成为实际被数据库执行的SQL逻辑。
有些朋友可能会说，SQL注入不是有很多防御手段了吗？是的，最常见的手段之一就是参数化查询。
简单来说，就是不把用户的输入直接拼接进SQL语句里，而是把这些输入当作参数传递给SQL引擎，让SQL引擎预先编译SQL语句，再把参数插进去执行。这样，哪怕用户输入再怎么恶意，最终也只是作为普通的数据处理，而不是SQL的一部分。
例如，来看一段最简单的SQL查询代码：
username = "admin'; DROP TABLE users --"
sql = f"SELECT * FROM users WHERE username = '{username}'"
假设这个username是用户输入的，我们直接拼接成SQL语句发送给数据库。执行结果就是：除了查询用户信息外，还会执行DROP TABLE这样的操作，直接把users表删掉。这就是最常见的SQL注入攻击。
如果我们使用参数化查询，代码就可以这样写：
import pymysqldb = pymysql.connect(user="root", password="password", database="test_db")
cursor = db.cursor()
sql = "SELECT * FROM users WHERE username = %s"
cursor.execute(sql, (username,))
在这个例子中，%s是一个占位符，用户的输入只会被当作一个字符串参数传递给SQL引擎，而不是直接拼接进SQL语句，这样就彻底杜绝了SQL注入的风险。用户输入的数据再怎么奇怪，都不会对数据库的查询逻辑产生影响。
这时候你可能会问，既然参数化查询这么有效，为什么这个问题还会一再出现？这是因为，虽然从技术上很容易解决，但许多项目中还是依赖开发人员的自觉。
如果开发者没注意，或者使用的是老旧的代码习惯，问题就会出现。更何况，许多历史遗留系统可能已经用了多年，重构难度和成本极高，所以一些危险的拼接式查询仍然被保留了下来。
至于为什么SQL标准没有直接把参数化查询设为默认实现，这个问题其实和数据库的多样性以及历史包袱有很大关系。SQL语言最初的设计并没有考虑到如今的复杂攻击场景，而是为了简化数据管理。
虽然参数化查询是一个较为现代的防御机制，但为了兼容各种老系统和开发习惯，SQL标准并没有强制要求使用它。
即使数据库厂商在新版本中做了一些改进，比如提供参数化查询的API，老旧系统依然占据了很大的市场份额。数据库厂商很难强制改变所有用户的使用习惯，毕竟业务需求决定了技术的演进节奏。
另外，也有朋友问过，参数化查询会不会影响性能？在大多数实际场景下，这种影响是微乎其微的。相反，参数化查询还可以提高查询效率，因为SQL引擎可以在第一次执行时预编译SQL语句，而后续执行时只需要替换参数即可。
这不仅提高了安全性，还减少了SQL语句的解析时间。所以，性能并不是阻碍参数化查询推广的主要原因。
那么，防止SQL注入是否只有参数化查询这一种方式？并不是。还有其他一些有效的手段可以辅助提升安全性。
首先是输入验证和清理。我们需要确保用户输入的内容符合预期的数据格式。如果预期是数字类型，那就只接受数字。
如果是字符串，就要避免特殊字符（如单引号、双引号）的存在。例如，在处理ID这样的参数时，我们可以用int()函数确保它是一个整数：
user_id = int(input("请输入用户ID:"))
sql = f"SELECT * FROM users WHERE id = {user_id}"
cursor.execute(sql)
这种直接将输入数据进行类型转换的方式，可以有效避免SQL注入，但它也仅限于特定的数据类型，对于字符串这种更为复杂的输入，还是需要依赖参数化查询。
另外，在某些特殊情况下，如果必须拼接SQL语句，我们也可以通过转义特殊字符的方式来防止注入。例如，在Python的pymysql库中，我们可以使用pymysql.escape_string()来转义用户输入的特殊字符：
username = pymysql.escape_string(username)
sql = f"SELECT * FROM users WHERE username = '{username}'"
cursor.execute(sql)
然而，尽管这种方法能起到一定的防护作用，但相较于参数化查询，它显然更加复杂，并且容易出错。因为黑客总能想出各种花样的输入方式，手动转义无法覆盖所有场景。
最后，还有一些数据库层面的安全措施。比如，最基本的数据库用户权限控制。你应该确保数据库用户只拥有最低的权限，避免应用层用户具有删除或修改表结构的权限。这样，即使出现了SQL注入，黑客的操作范围也会受到极大的限制。
总的来说，SQL注入的防御是一个多层次的防线，最有效的当然是参数化查询，再加上输入验证、权限控制等手段，才能全面保障系统的安全。
那么，大家怎么看呢？欢迎在评论区留下你们的看法。
对编程、职场感兴趣的同学，大家可以联系我微信：golang404，拉你进入“程序员交流群”。
资料包含了《IDEA视频教程》、《最全python面试题库》、《最全项目实战源码及视频》及《毕业设计系统源码》，总量高达650GB。全部免费领取！全面满足各个阶段程序员的学习需求。