相比单纯删除函数，禁用 CREATE FUNCTION 权限更关键。原因在于，只要这个权限仍然存在，攻击者就可以随时重新注册新的 UDF，并上传恶意 .so 文件；而删除函数只是清理现有记录，无法从根源上阻止其再次创建。
为什么禁用 CREATE FUNCTION 权限比删函数更重要
很多人在谈到 MySQL UDF 提权漏洞时，第一步往往是检查 mysql.func 表，然后删除 sys_eval 或 lib_mysqludf_sys.so 等可疑项。但这样做更像是清除了表面痕迹，并没有真正切断风险来源。只要攻击者仍然拥有执行 CREATE FUNCTION 的权限，就可以立即重新注册恶意函数；如果文件系统依旧可写，恶意 .so 动态库也能被再次上传并利用。
真正有效的防护重点在于权限控制：
CREATE FUNCTION是注册 UDF 的前置条件，必须从所有业务账号中完全收回- 检查命令：
SHOW GRANTS FOR 'app_user'@'%';，重点确认是否包含CREATE ROUTINE（它会隐含CREATE FUNCTION） - 回收权限时必须执行：
REVOKE CREATE ROUTINE ON *.* FROM 'app_user'@'%';（注意不能写成ON mydb.*） - 即便应用账号只是只读场景，也不能授予
EXECUTE权限——因为它允许调用已经存在的 UDF
secure_file_priv 不是摆设，但配置错等于没设
@@secure_file_priv 用于限制 SELECT ... INTO OUTFILE 与 LOAD DATA INFILE 的文件读写路径。它并不是简单的“启用/禁用”开关，而更像是一道目录边界。如果配置不当，不但起不到防护作用，反而容易造成错误的安全判断。
常见错误配置及修复方法：
- 值为
NULL或空字符串：虽然 MySQL 8.0+ 已禁止这种设置，但在旧版本中依然可能存在，必须在my.cnf中显式指定有效目录（如/var/lib/mysql-files/）并重启服务 - 设为
/或/tmp：攻击者可以直接写入类似/tmp/lib_pwn.so的恶意文件，再通过符号链接绕过插件目录限制（MySQL 8.0.29+ 已禁用符号链接，但旧版本仍需手动排查） - 正确做法：将其设置为仅允许
mysql用户写入的空目录（如/var/lib/mysql-udf-block/），然后执行chown mysql:mysql /var/lib/mysql-udf-block && chmod 700 /var/lib/mysql-udf-block - 验证命令：
SELECT @@secure_file_priv;和SELECT @@plugin_dir;必须分别检查，确保两个路径既不重叠，也不存在可交叉写入的风险
UDF 文件本身要清理，但得按规则删
MySQL UDF 提权通常依赖两个关键对象：一是数据库中的注册记录（mysql.func 表），二是磁盘上的共享库文件（如 .so 或 .dll）。如果只删除表记录而不清理文件，后续仍可通过 CREATE FUNCTION 直接复用；如果只删除文件而不清空注册项，MySQL 启动时虽然通常不会崩溃，但会产生报错，同时攻击者仍有机会重新上传恶意文件。
因此，清理流程必须形成闭环：
- 先检查注册项：
SELECT name, dl FROM mysql.func;，对每条结果执行DROP FUNCTION IF EXISTS `name`; - 再定位文件：
find /var/lib/mysql* -name "*.so" -o -name "lib_mysqludf_*" 2>/dev/null，逐一执行rm -f删除 - 检查插件目录权限：
ls -ld $(mysql -Nse "SELECT @@plugin_dir")，确认属主为mysql，权限不高于755（写权限仅保留给mysql用户） - 重启 mysqld 后，再次执行
SELECT name FROM mysql.func;，确认结果为空
应用层 SQL 注入才是真正的入口，配置加固只是延缓器
归根结底，大多数 MySQL UDF 提权漏洞的起点，并不是 DBA 忽略了某项配置，而是 Web 应用存在 SQL 注入风险，把用户输入直接拼接进了 SQL 语句。即使 secure_file_priv 配置得很严格，CREATE FUNCTION 权限也被收得很彻底，只要代码里还保留类似 WHERE id = " . $_GET['id'] 这样的拼接方式，攻击者仍然可以借此入侵：通过 UNION SELECT 写文件、利用报错注入窃取敏感数据，甚至进一步拿到 shell。
修补这一入口没有捷径：
- PHP 必须使用
PDO::prepare()+bindValue()，禁用mysql_query()和mysqli_query()直接拼接 SQL - Python 应使用
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])，拒绝任何形式的f-string或.format()拼接 SQL - Ja va 使用
PreparedStatement，严禁Statement.execute(sql + input) - 在 ORM 框架中禁用高风险原生 SQL 接口：例如 Django 的
extra()、SQLAlchemy 的text()如果包含变量拼接，应一律视为高危操作
还有一个最容易被忽视的问题：很多开发者以为“用了 ORM 就天然安全”，但在日志埋点、动态排序字段、IN 查询拼装等场景中，又重新回到了字符串拼接。恰恰这些细节位置，往往才是 MySQL UDF 提权攻击最常利用的突破口。
