网站注入命令

一个登录框。网站用户名填 ' OR '1'='1' --，注入密码随便。命令回车。网站后台数据库里那条拼接出来的注入 SQL 语句瞬间被截断，条件永远为真。命令你进去了。网站这不是注入电影桥段，是命令 2024 年还在发生的日常。上个月帮朋友看一个电商站，网站商品详情页的注入 URL 里有个 ?id=1024，我顺手改成 ?命令id=1024 AND 1=1，页面正常；再改成 ?网站id=1024 AND 1=2，商品直接消失。注入闭着眼睛都知道——注入点就在这。命令

SQL 注入的本质就一句话：用户输入被当成了代码执行。程序员写 SELECT * FROM users WHERE name = '" + name + "'，他以为 name 只是个名字，但攻击者递过来的是一把刀。数据库分不清哪段是数据哪段是指令，它只认语法。你给它一个引号，它就去闭合字符串；你给它一个分号，它就去执行下一条语句。这种信任错位，二十年前就有，现在依然遍地都是。

我见过最离谱的一个案例，是某地方政务网站的成绩查询接口。参数 exam_id 直接拼进 SQL，连单引号都没过滤。用 sqlmap 跑一下，三分钟出库名，五分钟出表名，十分钟开始拖数据。系统里存着几万考生的身份证号和手机号。运维的人后来跟我说，他们以为前端做了校验就安全了。前端校验？抓个包改一下参数的事。

注入命令的玩法远不止 OR 1=1。联合查询 UNION SELECT 能把别的表的数据直接搬到页面上显示；报错注入利用数据库的报错信息把数据一点一点吐出来；盲注更磨人，靠页面返回的真假状态，一个字符一个字符地猜，猜完库名猜表名，猜完表名猜字段。时间盲注最绝，用 IF(ASCII(SUBSTRING(...))>100, SLEEP(5), 0) 这种语句，看响应时间就知道猜得对不对。整个过程像在跟数据库玩二十问，只不过问的是它最私密的那些东西。

防御手段其实很成熟，但架不住有人不用。参数化查询——把 SQL 语句的结构先编译好，用户输入只作为数据绑定进去，数据库永远不会把数据当指令。这是根治的办法，所有主流语言都支持。可现实是，很多老系统用着拼字符串的写法，改造成本高，负责人觉得“反正没出过事”。还有一种侥幸心理：觉得自己的站小，没人盯。自动化扫描器可不挑食，全网 IP 段轮着扫，逮到一个算一个。

WAF 能挡一部分，但绕过手法也在进化。注释符变形、大小写混写、内联注释、编码转换，UNION 写成 /*!50000UNION*/，SELECT 拆成 SEL/**/ECT。WAF 规则库更新慢一点，就被绕过去了。所以别把 WAF 当救命稻草，它只是减速带，不是墙。

真正让我警觉的，是现在很多低代码平台和 ORM 框架也会出注入。开发者以为用了框架就万事大吉，结果在 where 条件里手写了一段原生 SQL，参数照样拼。ORM 提供的 raw 方法、execute 接口，用不好就是后门。工具越方便，人越容易松懈。

说到底，网站注入命令这件事，技术层面早就有解。难的是人的惯性。开发图快，运维图省事，产品觉得安全是别人的事。一个引号就能捅穿的系统，背后往往是一整条链路上没人真正在意。下次看到登录框，不妨想想：你输进去的那个单引号，到底被当成了什么。