Laravel 5.4应用uploads目录反复出现unknown_user恶意文件夹求助

先理清楚你的场景：基于Laravel 5.4搭建的博客邮件工具，目前处于小范围测试阶段，之前仅遇到过少量虚假用户，无严重攻击情况，但近期uploads目录反复出现带恶意内容的unknown_user文件夹。这种情况基本可以判定是文件上传环节存在身份验证或权限管控漏洞，下面是一步步的排查和修复方案：

一、先锁死文件上传的身份验证逻辑 #

• 检查处理上传的控制器方法：是否在接收上传请求前强制验证用户已登录？比如有没有给路由加上auth中间件，或者在方法内用auth()->check()做判断？如果未登录用户也能触发上传流程，攻击者完全可以构造请求创建任意文件夹。
• 修正用户ID的获取方式：你提到正常用户文件夹是usr123这类ID命名，要是代码里直接从请求参数（比如$userId = request('user_id')）获取用户ID，那风险极大——攻击者可以随意篡改参数值，甚至传入unknown_user这种自定义名称。正确的做法是从已认证的用户实例中取ID：$userId = auth()->id();，彻底杜绝前端参数篡改的可能。

二、严格限制上传目录的命名规则 #

• 对目录名做强校验：正常用户ID是数字，所以可以用正则preg_match('/^\d+$/', $userId)验证，不符合规则的直接拒绝创建目录。这样即使有非法请求，也没法生成unknown_user这类非数字命名的文件夹。
• 提前创建用户专属目录：不要在上传时动态创建目录，而是在用户注册成功时就自动生成对应的usr{id}文件夹，同时设置好安全权限（比如755，所有者设为web服务器用户）。上传时直接往已存在的目录写入，避免动态创建目录带来的风险。

三、加固uploads目录的权限与执行限制 #

• 设置正确的目录权限：确保web服务器用户（比如www-data、apache）只有写入权限，不能执行目录内的文件。可以执行以下命令：

  chmod -R 755 /path/to/your/uploads
  chown -R www-data:www-data /path/to/your/uploads
  

• 禁止uploads目录执行脚本：如果用Nginx，在配置里添加：

  location ~* /uploads/.*\.(php|php5|php7)$ {
      deny all;
  }
  

  若是Apache，在uploads目录下创建.htaccess文件，写入：

  <FilesMatch "\.(php|php5|php7)$">
      Order Allow,Deny
      Deny from all
  </FilesMatch>
  

  这样即便攻击者上传了恶意脚本，也无法执行。

四、添加上传日志与目录监控 #

• 记录上传请求日志：在上传控制器里添加日志记录，追踪每个请求的用户ID（未认证则标记）、IP地址、上传目录和文件名：

  Log::info('File uploaded', [
      'user_id' => auth()->id() ?? 'unauthenticated',
      'ip' => request()->ip(),
      'directory' => $uploadDir,
      'filename' => $fileName
  ]);
  

  下次出现异常时，就能通过日志定位请求来源，分析攻击路径。
• 定时扫描异常目录：写个简单的Shell脚本配合crontab，定时扫描uploads目录，发现非usr{数字}命名的文件夹就自动删除并报警：

  #!/bin/bash
  UPLOAD_DIR="/path/to/your/uploads"
  for dir in "$UPLOAD_DIR"/*; do
      if [[ ! "$dir" =~ ^$UPLOAD_DIR/usr[0-9]+$ ]]; then
          rm -rf "$dir"
          echo "Removed malicious directory: $dir" | mail -s "Malicious directory detected" your@email.com
      fi
  done
  

五、建议升级Laravel版本（可选但重要） #

Laravel 5.4是非常老旧的版本，官方早已停止安全维护，可能存在一些已知的安全漏洞。如果条件允许，建议逐步升级到较新的稳定版本（比如Laravel 10或11），能大幅提升应用的整体安全性。

最后，先删除现有的unknown_user文件夹，再按照上面的步骤逐一排查修复，应该就能解决这个问题了。

内容的提问来源于stack exchange，提问作者John Toe