暴露的数据库备份：当 /backup.sql 可被访问时会发生什么
数据库备份——.sql 文件、压缩转储、数据库的 zip 归档——有时会直接创建在可通过 Web 访问的目录中，并被遗留在那里。只需一次成功请求 /backup.sql 或 /dump.sql，攻击者就能拿到每张表的每一行数据，完全不需要触及你的应用逻辑。
这是什么
备份脚本、主机控制面板和手动导出工具通常会用可预测的名称写入转储文件：backup.sql、dump.sql、database.sql、db.sql.gz、backup.zip。当这些文件落入 Web 根目录而服务器又没有明确阻止它们时，它们就成了普通的可下载文件。攻击者会运行自动化扫描，对每个能访问到的主机请求数十个这类常见文件名。
AppSafe 会检查最常见的路径——/backup.sql、/dump.sql、/database.sql、/db.sql.gz 等——并标记任何返回 200 响应且内容看起来像 SQL 转储或归档文件的路径。该检查可以同时识别纯文本 SQL 和压缩格式。
为什么重要
SQL 转储包含生成时每张表中的每一行数据：用户账户、密码哈希、电子邮件地址、个人身份信息、会话令牌、支付记录以及应用内部状态。下载转储只需一次 HTTP 请求，而且不会在应用日志中留下任何痕迹——Web 服务器会像提供任何静态文件一样提供它。
与泄露的 API key 不同，泄露的数据库无法轮换。一旦有人拿到了你的用户表副本，对这些用户来说泄露就是永久性的。根据转储的内容，你可能需要依据 GDPR、CCPA 或 HIPAA 履行强制性的数据泄露通知义务，还要承担通知每一位受影响用户的运营成本。
如何修复
正确的修复方法是将备份文件写入 Web 服务器无法访问的目录——例如 /var/backups/ 或带私有 ACL 的对象存储桶，而不是 /var/www/ 的子目录。检查所有 cron 任务和备份脚本，并更新目标路径。
作为纵深防御措施，无论文件存储在哪里，都应在服务器层面拒绝对 SQL 文件和常见归档扩展名的请求。
location ~* \.(sql|sql\.gz|bak|dump|tar|tar\.gz|tar\.bz2|zip)$ {
deny all;
return 404;
}如果发现暴露的文件，请立即删除。然后排查它是如何出现在那里的——修复放置该文件的脚本或流程，以免它在下一次计划运行时再次出现。
清理完成后，确认常见路径已被阻止。
for path in /backup.sql /dump.sql /database.sql /db.sql.gz; do
code=$(curl -so /dev/null -w "%{http_code}" "https://yourdomain.com$path")
echo "$path → $code"
done
# Every line must print 404常见问题
攻击者怎么会想到在我的网站上尝试 /backup.sql？
他们并不是专门针对你。自动化扫描器会持续不断地对数百万台主机请求数十个常见的备份文件名。存在的文件会返回 200，并在你意识到需要检查之前就被下载。
这个文件只存在了一个小时。损害已经造成了吗？
有可能。自动化扫描全天候运行，文件通常在出现几分钟内就会被发现。如果你有访问日志，请检查该路径是否被请求过——如果有，请将其视为已确认的数据泄露。
我可以只给文件加上密码保护，而不是移动它吗？
对单个文件使用 Basic 认证很脆弱，也容易配置错误。正确的做法是将该文件彻底移出任何可通过 Web 访问的位置。备份应存放在 HTTP 服务器无法访问的地方。