MySQL自定义函数禁止参数化查询且无法防范SQL注入，根本修复方案是将动态逻辑移至应用层，由白名单校验后使用预编译语句执行；函数仅用于纯计算或确定性字符串操作。
MySQL自定义函数里不能用参数化查询
MySQL的CREATE FUNCTION语法不支持预编译占位符（如?或:name），也无法在函数体内调用PREPARE/EXECUTE——这是硬性限制。所以你在函数里写CONCAT('SELECT * FROM users WHERE id = ', id_param)再拼接执行，就等于把SQL注入的门彻底敞开。
常见错误是试图在函数里“手动转义”：比如用REPLACE(input, "'", "''")或ESCAPE子句。但这些操作既不完整（漏掉\、%、_等上下文敏感字符），又无法覆盖所有SQL语义场景（比如LIKE中的通配符、正则表达式、JSON路径等）。
- MySQL函数中
EXECUTE仅允许在存储过程/函数中使用，但要求SQL字符串必须是常量或用户变量，而用户变量本身若来自外部输入，仍会带入风险 -
QUOTE()函数看似安全，但它返回带单引号包裹的字符串（如'admin'' OR 1=1'），若被二次拼接到未加引号的上下文中（如ORDER BY字段名），直接失效 - 函数内无法做类型校验——传入
'1 OR SLEEP(5)'，CAST(... AS UNSIGNED)会静默转成1，但CONCAT拼接时已晚
把动态逻辑移出函数，改由应用层控制
真正可行的修复路径，是承认“自定义函数不适合处理可变、不可信的输入”。把原本想塞进函数里的动态SQL逻辑，拆出来交给应用代码处理：
- 函数只做纯计算或确定性转换，例如
DELIMITER $$ CREATE FUNCTION safe_trim_suffix(s TEXT, suffix TEXT) RETURNS TEXT BEGIN RETURN TRIM(TRAILING suffix FROM s); END$$——这里suffix不参与SQL执行，仅作字符串操作 - 涉及表名、列名、
WHERE条件片段等元数据，必须由应用层白名单校验后，再拼接SQL（例如只允许['user_id', 'email', 'status']作为列名参数） - 若必须复用某段查询逻辑，改写为存储过程，并用
IN参数接收已清洗过的值，再用IF/CASE分支控制流程，避免字符串拼接
比如原函数想实现“按字段模糊查”，正确做法不是CREATE FUNCTION search_by(field VARCHAR(64), val VARCHAR(255))...，而是应用层根据field查白名单，确认合法后生成SELECT * FROM t WHERE email LIKE CONCAT('%', ?, '%')并交由PDO/PreparedStatement执行。
如果非得在函数里拼SQL，唯一勉强可控的方式
极少数遗留系统无法重构，且函数必须动态构造查询（如通用审计日志检索），可考虑以下组合约束，但需清楚这是降级方案，不是根治：
- 输入参数强制声明为
CHAR(n)或VARCHAR(n)，并在调用前由应用层截断长度（如LEFT(val, 32)），杜绝超长payload触发缓冲区异常或绕过检测 - 对关键元数据（如表名、列名）使用
INFORMATION_SCHEMA反查验证：SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = given_table AND COLUMN_NAME = given_col，查不到就RETURN NULL - 禁止任何用户输入进入
ORDER BY、GROUP BY、LIMIT、UNION等易被利用的位置；必须出现时，只允许映射到固定枚举值（如input_sort = 'asc' → 'ORDER BY created_at ASC'）
注意：mysql_real_escape_string这类C API函数在函数内部不可用；ESCAPE只对LIKE有效；REGEXP中的输入若未限定字符集，仍可能被用于ReDoS攻击。
权限隔离是最容易被忽略的最后一道防线
即使函数逻辑有瑕疵，也能大幅压缩攻击面：给运行该函数的数据库账号分配最小权限。
- 撤销
FILE、PROCESS、SUPER等高危权限 - 只授予函数所查表的
SELECT权限，禁用INSERT/UPDATE/DELETE，更不要给mysql系统库权限 - 若函数读取多个表，拆分为多个专用账号，各管一摊，避免横向越权
很多团队修复了代码，却忘了回收旧账号权限——结果攻击者用一个已被遗忘的backup_user账号调用存在漏洞的函数，照样能拖库。权限清理和函数重构必须同步推进。
