文件上传功能会触发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。

盯住这部分代码，比加固整个上传流程更有效。

《夸克》非常好用的免费AI浏览器

下载APP查看