文件上传功能会触发sql注入，因为系统常将未过滤的文件名等参数直接拼入sql语句；修复关键在于上传后数据库写入操作必须使用参数化查询，并严格校验、重命名文件名。
为什么文件上传功能会触发SQL注入
文件上传本身不直接执行SQL，但很多系统在保存上传记录时，会把文件名、路径、用户ID等信息拼进INSERT或UPDATE语句。如果这些字段没做参数化处理，攻击者上传一个叫test' OR 1=1--.php的文件，就可能让后续的SQL语句提前闭合并注入恶意逻辑。
修复关键：上传后写入数据库的那几行代码
重点不是上传逻辑本身，而是上传成功后调用的数据库写入操作。常见出问题的位置包括：upload.php、select_soft_post.php、edit.inc.php等文件中涉及INSERT INTO或UPDATE的地方。
- 检查所有含
$filename、$userid、$uploadtime等变量参与拼接SQL的地方 - 确认是否用了
mysql_query("INSERT INTO ... VALUES ('$filename')")这类直拼方式——这是高危写法 - 替换为参数化查询：PDO用
prepare()+execute()，MySQLi用prepare()+bind_param() - 若必须用旧式
mysql_query()（已废弃），至少对$filename做mysql_real_escape_string()，但强烈建议升级
别忽略文件名校验这个前置环节
即使SQL写了参数化，如果文件名本身含恶意字符串（如1.jpg'--），且又被用于日志、重命名、或二次拼接，仍可能漏网。DedeCMS的/include/dialog/select_soft_post.php就是典型例子。
- 在
move_uploaded_file()之前，先用正则过滤文件名：preg_match('/^[a-zA-Z0-9._-]+\.([a-zA-Z0-9]{2,4})$/', $filename) - 禁止任何含单引号、分号、注释符（
--、#）的文件名通过校验 - 不要只依赖客户端或表单
accept属性，服务端必须重验后缀和MIME类型 - 重命名文件（如用
uniqid().'.jpg'），彻底剥离用户可控的原始文件名
容易被绕过的坑：多层拼接和缓存污染
有些系统把文件信息先存进数组，再循环拼成SQL；或者把上传数据写进缓存（Redis/Memcached），之后从缓存读出来再入库——这两类场景下，参数化容易漏掉中间环节。
- 检查是否有类似
$sql = "INSERT INTO logs VALUES ('".$data['name']."', ...)"这种“先组装再执行”的模式 - 确认缓存中的值是否经过转义或类型强制转换，比如
(int)$data['uid']比$data['uid']安全得多 - 搜索项目里所有
mysqli_query(、mysql_query(、PDO::query(的调用点，逐个验证输入来源
真正危险的从来不是“上传”动作，而是上传后那一段轻率拼接的SQL——盯住它，比加固整个上传流程更有效。
