sql注入实验

我把一个带搜索框的入实网站当靶子打。输入框里填了 ' OR 1=1 -- ，入实回车，入实本该显示“无结果”的入实页面，哗啦啦吐出了整个用户表。入实那一刻我后背发凉——这破站上线三年，入实居然没人试过这一下。入实

SQL注入说白了就一句话：网站把用户输入直接拼进SQL语句，入实没过滤。入实你输入的入实不再是“关键词”，而是入实“代码”。我见过最蠢的入实例子，后台登录框这样写：SELECT * FROM admin WHERE name='$user' AND pwd='$pass'。入实那我用户名填 admin' -- ，入实密码随便打，入实注释符把后面的密码校验全吞了。登录成功，进后台，权限跟真管理员一模一样。

别觉得这是老古董漏洞。2023年某电商平台被拖库，几百万条订单信息泄露，根因还是注入。开发换了三拨人，框架从PHP换到Java，但SQL语句还是字符串拼接的老写法。技术债这东西，不还的时候不觉得，爆雷的时候直接要命。

实验里我试了三种注入手法。第一种是报错注入，故意让数据库报错，错误信息里会带出字段值。比如输入 ' AND extractvalue(1, concat(0x7e, database())) -- ，页面直接显示数据库名。第二种是盲注，页面不显示任何报错，只能靠“有结果”和“无结果”来判断条件真假。写个脚本逐字符猜，慢是慢点，但总能猜完。第三种最狠，union注入，直接把查询结果合并到正常结果里，想查哪张表就查哪张表。

最让我意外的是，很多防护措施形同虚设。有些系统加了WAF（Web应用防火墙），但规则写得稀烂。我换个编码方式，或者用注释符分割关键字，WAF就识别不出来了。比如把 UNION 写成 UN/**/ION ，不少正则直接漏过去。还有的只过滤了单引号，那我用十六进制编码字符串，照样能打。

防御手段其实不复杂。第一，用参数化查询或预编译语句，让SQL语句结构固定，用户输入只当数据传参，永远变不成代码。第二，对输入做白名单校验，比如只允许数字、字母、下划线，其他字符直接拒绝。第三，数据库账号权限最小化，应用连库的账号别用root，只给SELECT权限，就算被注入了，最多查数据，删不了表。

但问题在于，很多团队直到出事才想起补课。我见过一个项目，上线前安全测试报告里写着“存在SQL注入风险”，项目经理说“排期紧张，先上线后修复”。后来呢？后来那个系统被扫了三个月，数据被拖了两次，才终于有人认真对待那条报告。

实验做完，我把自己写的注入脚本存了个档。不是为了留着干坏事，是提醒自己：写代码的时候，永远默认输入是恶意的。这个习惯，比任何安全工具都管用。

本文地址：http://www.79wt.cn/news/62d0599932.html