网页sql注入语句

一个单引号就能让数据库崩溃，网页这听起来像段子，入语但真实发生过无数次。网页我见过一个电商后台，入语搜索框里输入' OR '1'='1，网页整个用户表直接摊在浏览器上。入语那不是网页电影特效，是入语SQL语句被拼接进了查询逻辑。

网页sql注入的网页本质，是入语开发者把用户输入当成代码执行。比如登录框，网页后台可能写着SELECT * FROM users WHERE name='$username' AND pass='$password'。入语你输入admin'--，网页注释符把后面的入语密码验证吃掉了，等于告诉数据库：别管密码，网页直接放行。就这么简单，不需要高深技巧。

更狠的玩法是union查询。假设有个商品详情页，URL参数是id=5，后台查询商品信息。你把id改成0 union select username,password from users，页面可能直接渲染出管理员账号和哈希密码。我亲眼见过一个新闻网站，编辑后台的标题字段没做过滤，攻击者用'; DROP TABLE news;--把整张表删了。那天他们的首页变成空白，运维蹲在机房熬了一整夜恢复备份。

别以为参数化查询能解决一切。我测试过一个金融系统，他们用了预编译语句，但排序字段是直接拼接的。ORDER BY $sort，你把sort参数换成CASE WHEN (SELECT ascii(substr(password,1,1)) FROM admin)>100 THEN id ELSE name END，页面排序结果会悄悄泄露密码字符。这叫盲注，不报错，不显示数据，只通过页面行为差异逐位猜解。慢，但有效。

还有个常见误区是只过滤单引号。有一次我碰到个系统，把'替换成空字符串，但没处理反斜杠。输入\' OR 1=1--，反斜杠转义了后面的单引号，结果过滤器把单引号删掉，反而留下一个裸奔的'，照样注入成功。这种绕过方式，比想象中更常见。

现在很多框架默认做了防护，但老项目、自研接口、第三方插件仍然是重灾区。我上周帮朋友看一个企业内部工具，登录接口用了存储过程，但存储过程内部拼接了字符串。参数化只保护了外层，内层照样裸奔。攻击者把输入写成'; EXEC xp_cmdshell 'whoami'，直接拿到服务器权限。Windows下还能用xp_cmdshell执行系统命令，Linux下可以写webshell，一条语句就能控制整台机器。

说点实际的。如果你在维护一个老系统，至少做两件事：第一，用预编译语句重写所有数据库操作，别偷懒。第二，给数据库账号最小权限，别用sa或root连应用。有个客户觉得内网系统无所谓，结果攻击者通过WiFi进入内网，用注入拿到后台，再提权到域管理员，整个公司电脑都被加密勒索。不是吓唬你，这类案例每年都有。

最后提醒一句，别迷信WAF。我见过很多WAF规则只拦常见关键字，稍微编码一下——比如用char(39)代替单引号，或者用/**/分割关键字——就绕过去了。真正的防线在代码层，输入验证加参数化查询，比一百个安全设备都靠谱。写代码的时候多问一句：这个输入如果包含SQL语法，会发生什么？答案会让你后背发凉。