我见过太多人觉得拼SQL没啥问题。自己写的代码自己清楚，测试也能跑通，何必多此一举。这种想法我以前也有过，直到亲眼看见一个同事负责的项目被攻破。
用户登录框里正常输入账号密码，对方却直接拿到了数据库里所有人的手机号和密码明文。文章源自网吧系统维护-https://www.58pxe.com/12957.html
那个项目的登录代码是这样的。取出用户输入的用户名和密码，直接赋值给一个字符串变量。然后把这个变量拼到SQL语句里，送到数据库执行。看起来没问题，对吧？文章源自网吧系统维护-https://www.58pxe.com/12957.html
真正的问题在于，用户输入的内容会被当成SQL命令的一部分来执行。文章源自网吧系统维护-https://www.58pxe.com/12957.html
比如输入用户名是 admin' OR '1'='1。这个单引号会提前结束原本SQL里的字符串，后面的条件就成了永远成立的真值。数据库根本分不清哪部分是用户输入，哪部分是程序控制的逻辑。它只会忠实地执行整条语句。文章源自网吧系统维护-https://www.58pxe.com/12957.html
更危险的是有人可以直接在输入框里写 '; DROP TABLE users; --。这种操作会把整张表删掉。系统崩了，老板找你谈话，工资扣完，还得赔数据恢复的钱。文章源自网吧系统维护-https://www.58pxe.com/12957.html
拼SQL字符串等于把数据库的安全大门直接拱手让人。你完全放弃了对语句结构的控制权。文章源自网吧系统维护-https://www.58pxe.com/12957.html
解决办法不复杂。参数化查询就是把这扇门重新锁上。它的核心逻辑是把SQL的骨架和用户提供的数据分开处理。文章源自网吧系统维护-https://www.58pxe.com/12957.html
用参数化查询时，你先告诉数据库“我要查users表里的记录，条件是id等于一个问号”。这个问号是一个占位符，不是用户输入的原文。然后你单独提交用户的输入值，数据库知道占位符位置只能放数值，不能放命令。它会把输入当纯粹的数据处理，就算里面塞了 OR '1'='1' 这种内容，也只会当作一个普通的字符串去匹配，不会影响SQL的逻辑结构。文章源自网吧系统维护-https://www.58pxe.com/12957.html
用代码写起来也简单。C里用SqlCommand对象，设置好CommandText，再往Parameters集合里添加参数。Java里用PreparedStatement。PHP有PDO或者mysqli的参数绑定功能。Python的sqlite3同样支持问号占位符。这些写法都不需要学新东西，五分钟就能改好。文章源自网吧系统维护-https://www.58pxe.com/12957.html
有些人觉得参数化查询性能比拼字符串慢。其实恰恰相反，数据库能缓存参数化查询的执行计划，执行速度反而更快。文章源自网吧系统维护-https://www.58pxe.com/12957.html
还有一种情况容易让人放松警惕。有人觉得自己用存储过程就安全了。但存储过程里如果还是拼字符串执行，风险一点没少。正确做法是存储过程里也用参数传入，别在过程体内拼接。文章源自网吧系统维护-https://www.58pxe.com/12957.html
其他场景也得注意。比如把数据导出成Excel或CSV文件时，如果直接把用户提供的内容放进文件名，也可能被利用。不过防SQL注入最基础还是防住数据库这一关。文章源自网吧系统维护-https://www.58pxe.com/12957.html
我见过有人为了省事，说自己只是内网使用，没人攻击。内网被攻击的例子多得是，同事误操作，测试账号泄露，随便一个场景都能出问题。不要赌运气。文章源自网吧系统维护-https://www.58pxe.com/12957.html
记住一句话，用户输入的内容永远不能直接参与SQL语句的拼接。哪怕你觉得这个用户很安全，哪怕你加了各种过滤，哪怕你用了特殊字符转义。过滤和转义总有疏漏，只有参数化查询是从根本上切断了注入的可能。文章源自网吧系统维护-https://www.58pxe.com/12957.html
写代码的人要对数据负责。数据泄露不是小事，轻则罚款整改，重则老板进去你背锅。花五分钟改掉拼字符串的习惯，能省下未来无数的麻烦。文章源自网吧系统维护-https://www.58pxe.com/12957.html 文章源自网吧系统维护-https://www.58pxe.com/12957.html
评论