```html

2019年夏天，入攻某地一家小型电商网站的控制运维人员发现数据库里多了一张表，表名是网站一串乱码。打开一看，服务里面整整齐齐存着他们网站所有用户的入攻手机号、收货地址，控制甚至包括部分用户的网站登录密码明文。攻击者没有黑进服务器操作系统，服务也没有拿到SSH密钥——他只是入攻在一个商品筛选框里输入了一段精心构造的SQL语句。

这就是控制SQL注入的可怕之处。它不需要你开放多余的网站端口，也不需要你安装什么后门程序。服务只要你的入攻网站有输入框，并且后端代码把用户输入直接拼接到SQL查询里，控制攻击者就能通过这个入口，网站把数据库的操作权攥在手里。数据库一旦失守，服务器往往就是下一块多米诺骨牌。

很多人以为SQL注入只能“读数据”，比如拖库、猜表名、爆字段。那是早期玩法。现在的注入攻击可以做到更狠的事：写文件、执行系统命令、提权。举个例子，MySQL有一个INTO OUTFILE语句，如果数据库用户权限够大，攻击者能把查询结果写成一个PHP文件，放到网站根目录下。然后他访问这个文件，服务器就会执行里面的代码。这时候，他控制的已经不是数据库了，而是整台Web服务器。

我见过一个真实案例。某公司的后台登录接口存在注入点，攻击者先通过报错注入拿到了数据库版本和当前用户，发现是root@localhost。接着他用LOAD_FILE()读取了/etc/passwd，确认了系统是Linux。然后他构造了一条SELECT ... INTO OUTFILE '/var/www/html/shell.php'，写入了一个一句话木马。整个过程不到二十分钟。等他连上菜刀，服务器上的所有网站、所有数据库、所有配置文件都暴露了。运维人员后来查日志，只看到几个奇怪的HTTP请求，连个明显的扫描都没有。

为什么SQL注入能走到这一步？根子在于权限没管住。很多开发者图省事，连接数据库直接用root，或者给Web应用分配了FILE、SUPER这类高危权限。数据库和Web服务器又常常跑在同一台机器上。这就等于把保险柜的钥匙和保险柜放在同一个抽屉里。攻击者只要撬开一个输入框，就能顺着这条线一路摸到操作系统。

还有一种更隐蔽的路径：利用数据库的扩展功能。比如SQL Server的xp_cmdshell，默认关闭，但如果攻击者通过注入拿到了sysadmin权限，就能把它重新打开，然后直接执行whoami、net user这些系统命令。微软后来默认禁用它，但很多老旧系统或者配置不当的实例仍然开着。我曾在一次渗透测试里遇到一个内网系统，注入点在一个不起眼的日期筛选参数上，最后通过xp_cmdshell直接反弹了一个shell到外网。客户当时就愣住了。

防御SQL注入，参数化查询是底线，但光靠这个不够。数据库账号必须最小权限，Web应用连接数据库的账号绝不能有FILE、CREATE、DROP这些权限。数据库和Web服务器最好分开部署，至少别让数据库用户能往Web目录写文件。还有，别把详细的数据库报错信息返回给前端——攻击者就是靠报错来推断表结构和权限的。把这些信息藏起来，攻击成本会高很多。

说到底，SQL注入不是数据库一个人的问题。它是一条链：输入过滤不严、权限过大、数据库与Web服务器混布、错误信息泄露。任何一环断了，攻击者都很难从注入点走到服务器控制权。但现实是，很多网站这几环全断了。你随便找个老旧的CMS或者外包做的后台，输入个单引号，报错页面能把数据库版本都告诉你。这种站点，离被控只差一个INTO OUTFILE的距离。

```