sql注入问题怎么处理

去年有个做电商的入问朋友找我救火，说后台订单数据全乱了，题处用户列表里冒出一堆不认识的入问账号。我上去一看日志，题处好家伙，入问有人在一个查询接口的题处URL参数里塞了 ' OR 1=1 --，直接把整张用户表拖走了。入问这就是题处典型的SQL注入——攻击者把SQL代码伪装成普通数据，骗过应用程序，入问让数据库乖乖执行。题处

问题出在代码怎么拼SQL语句。入问很多早期项目里，题处程序员图省事，入问直接拿用户输入去拼接查询字符串。题处比如 "SELECT * FROM users WHERE name = '" + userName + "'"。入问用户正常输入“张三”，语句没问题；可一旦输入 ' OR '1'='1，整个WHERE条件就变成恒真，所有记录全被捞出来。更狠的还能用分号执行多条语句，删表、改数据、甚至调用系统命令。

处理SQL注入，最有效的一招就四个字：参数化查询。别自己拼字符串，把用户输入当成参数传给数据库驱动。比如Java里用PreparedStatement，Python里用cursor.execute("SELECT * FROM users WHERE name = %s", (userName,))，PHP里用PDO的bindParam。数据库会先把SQL语句的结构编译好，参数只是填进去的值，不会被当成代码执行。这一招能挡掉绝大多数注入攻击。

但光靠参数化不够。有些场景没法用参数化，比如动态表名、动态排序字段。这时候得用白名单校验——用户传过来的排序字段，只允许是“id”“name”“created_at”这几个预设值，其他一律拒绝。别用黑名单过滤，你永远不知道攻击者能想出什么新花样绕过你的正则。

再说个实际案例。我见过一个项目，前端用JavaScript做了输入校验，把单引号转义了。后端程序员觉得稳了，直接拼SQL。结果攻击者抓包改请求，绕过前端，照样注入。所以校验必须在服务端做，前端校验只是提升用户体验，别当成安全防线。

还有个小细节：数据库账号权限要最小化。Web应用连数据库的账号，只给SELECT、INSERT、UPDATE、DELETE这几项，别给DROP、FILE、EXECUTE。万一真被注入了，攻击者也只能在有限范围内折腾，没法直接删库跑路。我习惯给每个应用单独建数据库用户，只授权它需要的那几张表。

错误信息也别直接吐给用户。有些框架默认把SQL异常堆栈打回前端，攻击者一看就知道表名、字段名、数据库版本，省了他们多少探测功夫。统一返回“系统繁忙，请稍后重试”，详细错误写进服务端日志就行。

最后提一句ORM。用Hibernate、MyBatis、SQLAlchemy这些框架，默认就是参数化查询，比手写JDBC安全得多。但别以为用了ORM就万事大吉——要是你非要在MyBatis里写 ${ } 而不是 #{ }，照样注入。工具是死的，用的人得长点心。

说到底，SQL注入不是数据库的锅，是写代码的人偷懒。把用户输入当数据，别当代码，这条原则守住了，九成以上的注入问题就没了。