SQL注入能否直接提权取决于数据库账户权限是否失控；绝大多数提权源于应用使用root/sa等超级账户连接，而非漏洞本身强度，因此须实施权限最小化策略，禁用高危权限如FILE、CREATE、SUPERUSER等。
SQL注入能直接提权？先看数据库账户权限是否失控
绝大多数SQL注入导致的提权，根本不是漏洞本身有多强，而是应用连数据库都用
或
这类超级账户连接。一旦注入成功，攻击者就等于拿到数据库的“管理员钥匙”。
防不住注入时，权限最小化就是最后一道闸门。
生产环境绝不能用
（MySQL）、
（SQL Server）、
（PostgreSQL）等默认高权限账号连接应用
为每个业务模块创建独立账号，比如
、
，只赋予对应库表的
、
、
权限，禁用
、
、
、
、
确认权限是否生效：用该账号登录后执行
（MySQL）或
+
（PostgreSQL），别只信配置文件里写了啥
为什么 prepared statement 不能代替权限控制
很多人以为用了
（Java）、
（PHP）、
（Python）就万事大吉——其实它只防参数拼接型注入，对动态表名、列名、
子句、
后的结构控制完全无效。这时候如果账号权限过大，照样能拖库甚至写 shell。
—— 第一个
在绝大多数驱动里根本不支持参数化，会直接报错或被忽略
虽然语法上允许，但实际可能绕过类型检查，拼进恶意字段如
即便所有查询都参数化，若账号有
（MySQL）或
（PostgreSQL），仍可能通过注入触发系统命令执行
MySQL 中 FILE 权限是提权高危项，必须显式回收
只要数据库账号有
权限，配合注入就能读取服务器任意可读文件（如
、Web 配置），甚至写入 Web 目录生成一句话木马。这个权限和增删改查无关，却常被忽略。
检查当前用户是否有
：执行
回收命令是
，不是
或注释掉配置
某些云数据库（如阿里云 RDS）默认关闭
，但仍需人工确认账号无
权限，不能依赖平台限制
PostgreSQL 的 public schema 和默认角色要特别当心
PostgreSQL 默认把新用户加进
schema，且
对所有用户可读写。一旦注入点出现在建表、临时表或函数调用场景，攻击者可能创建恶意函数或覆盖已有视图。
执行
，再为必要用户单独授权
避免使用
或
属性，哪怕只给一个运维账号也极危险
检查是否存在未审计的自定义函数，如
—— 这类函数本身就是提权后门
权限控制不是设完就完的事。每次上线新功能、接入新服务、迁移数据库，都要重新核对账号权限清单。最麻烦的是——你永远不知道哪行日志里藏着一句没走参数化的
，所以数据库账号必须从第一天起就按“已被注入”来设计。
rootsarootsapostgresapp_user_orderapp_user_reportSELECTINSERTUPDATEDROPCREATEALTEREXECUTEFILESHOW GRANTS\du+\dpPreparedStatementpg_query_paramscursor.execute(sql, params)ORDER BYUNION SELECTSELECT * FROM ? WHERE id = ??ORDER BY ?id; DROP TABLE users--SELECT INTO OUTFILECOPY ... FROM PROGRAMFILE/etc/passwdFILESELECT * FROM mysql.user WHERE User='app_user' AND File_priv='Y';REVOKE FILE ON *.* FROM 'app_user'@'%';DROPsecure_file_privFILEpublicpublicREVOKE CREATE ON SCHEMA public FROM PUBLIC;CREATEROLESUPERUSERCREATE OR REPLACE FUNCTION exec_cmd(text) RETURNS text AS $$...$$ LANGUAGE plsh;query