sql注入复现

sql注入这事儿，入复我见过太多人栽跟头。入复不是入复因为它多难，恰恰相反，入复它简单得让人掉以轻心。入复前两天帮一个朋友排查他公司内部系统的入复漏洞，登录框里输入`' or 入复1=1 --`，直接进了管理后台。入复他愣了半天，入复说这系统外包花了八十万。入复

八十万买不来一个参数化查询，入复这事儿说起来挺讽刺的入复。

复现sql注入，入复环境其实特别好搭。入复你本地起一个mysql，入复再写个十几行的php接收用户输入拼进查询语句里，漏洞就出来了。核心问题就一句话——开发者把用户输入当成了代码执行，而不是数据。

拿个最常见的例子说。登录验证的sql语句长这样：
SELECT * FROM users WHERE username = '$username' AND password = '$password'
如果用户在用户名框里填了admin' --，那整条语句就变成了：
SELECT * FROM users WHERE username = 'admin' --' AND password = '$password'
两个横杠把后面的密码验证注释掉了。攻击者连密码都不用知道，直接以admin身份登录。

我第一次亲手复现这个的时候，在虚拟机里敲完payload，看着终端跳出的用户信息，后背真有点发凉。那种感觉就像你发现自家门锁其实是个摆设，一推就开，只是之前没人试过。

更狠的是union注入。假设有个商品详情页，id参数直接拼进查询：
SELECT name, price FROM products WHERE id = $id
攻击者把id改成0 UNION SELECT username, password FROM users，前端页面就直接把数据库里的账号密码渲染出来了。我见过最离谱的一次演示，是在一个教学靶场上，用这个方法把整个用户表的hash都dump了下来，整个过程不到三分钟。

别觉得只有老掉牙的系统才有这问题。去年我测一个刚上线的移动端API，post请求里的JSON字段照样能拼出注入点。开发者以为用了框架就安全了，结果在某个查询里图省事用了字符串拼接。框架救不了粗心。

防御手段其实不复杂。参数化查询是标配，prepared statement一上，用户输入永远只是参数，不可能变成sql结构。再就是输入校验，白名单过滤，该转义的转义。但真正难的是让每个开发者从骨子里意识到——用户输入是不可信的，永远不可信。

复现这个漏洞的过程，本质上是在跟人性弱点打交道。图省事、想当然、觉得没人会这么干。可攻击者偏偏就专门研究怎么这么干。

写到这里，我想起那个外包系统的登录框。修复方案其实就改三行代码，把字符串拼接换成占位符绑定。但负责维护的团队拖了两周才动手，原因是"需要走变更流程"。你看，漏洞本身不可怕，可怕的是人对漏洞的态度——总觉得自己不会是那个倒霉蛋。

sql注入活了二十多年，未来还会继续活很久。只要还有人写代码，还有人偷懒，它就有生存空间。复现它不是为了炫技，是为了让你记住那种"门没锁"的惊悚感。下次写查询语句的时候，多问自己一句：如果用户在这里填了' or 1=1 --，会怎样？