网站静态资源被替换为恶意文件的检测

网站静态资源被恶意替换，本质上是一种持久化的供应链攻击。攻击者通过篡改服务器上的JS、CSS、图片或可执行文件，将恶意代码直接注入到每一个访问者的浏览器中。与传统的SQL注入或XSS不同，这种攻击的隐蔽性极强，因为被篡改的文件往往在文件名和路径上没有变化，只是文件内容的哈希值发生了改变。很多运维人员习惯盯着日志中的404错误或异常请求，却忽略了200 OK响应背后可能已经返回了被挂马的资源。

检测的第一步不是去扫描病毒，而是建立一套绝对可信的文件指纹数据库。你需要对生产环境所有静态资源的哈希值进行全量采集。建议使用SHA-256或SHA-512算法，不要使用已证明存在碰撞漏洞的MD5。这个过程不是一次性的，而是要集成到CI/CD流水线中。每次发版后，立即运行脚本计算所有静态文件的哈希值，并将这份清单存入只读数据库或加密存储中。这份基线清单是后续所有检测工作的唯一参照物。

有了基线，就可以部署定时巡检任务。巡检脚本的核心逻辑很简单：遍历静态资源目录，计算当前文件的哈希值，与基线进行比对。如果出现不匹配，立即触发告警。这里有一个容易被忽视的细节：不要只比对内容，还要比对文件元数据。攻击者有时会保留文件内容不变，但修改文件的修改时间或权限位，为后续攻击做准备。因此，巡检脚本应同时记录文件的inode、修改时间和权限掩码。

#!/bin/bash
# 简易静态资源哈希巡检脚本示例
BASELINE_FILE="/secure/path/baseline.sha256"
SCAN_DIR="/var/www/html/static"

while IFS="  " read -r hash filepath; do
    full_path="${SCAN_DIR}/${filepath}"
    if [ -f "$full_path" ]; then
        current_hash=$(sha256sum "$full_path" | awk '{print $1}')
        if [ "$current_hash" != "$hash" ]; then
            echo "ALERT: Hash mismatch for $filepath"
            # 此处可接入钉钉、企业微信或邮件告警
        fi
    else
        echo "ALERT: Baseline file missing: $filepath"
    fi
done < "$BASELINE_FILE"

对于图片和字体这类二进制资源，攻击者常使用隐写术或直接在文件末尾追加恶意代码。单纯比对哈希值能发现变化，但无法定位恶意代码的注入点。建议在检测流程中加入结构分析工具。对于PNG、JPEG、GIF等图片格式，可以使用专门工具检查文件结构是否完整，是否存在异常的数据块。一个正常的JPEG文件，其文件尾应该是固定的字节序列，如果文件末尾被追加了PHP或JavaScript代码，结构分析工具会直接报出文件结构损坏或存在尾随数据。

服务器端的检测可能存在时间窗口盲区，因此需要在浏览器端部署资源完整性校验机制。Subresource Integrity是首选方案。在引用外部或关键静态资源的HTML标签上添加integrity属性，浏览器会在执行脚本或应用样式前自动计算哈希值，与属性值比对。如果不匹配，浏览器会阻止资源加载并在控制台输出错误。这不仅能防御静态资源被篡改，还能防止CDN节点被攻陷后分发恶意文件。你需要将基线哈希值同步到HTML模板的构建过程中，确保integrity属性值与生产文件严格对应。

很多静态资源替换事件并非来自外部直接上传漏洞，而是服务器内部某个进程被控制后发起的写操作。部署文件完整性监控守护进程，实时监听静态资源目录的inotify事件。当检测到CLOSE_WRITE或MOVED_TO事件时，不要立刻判定为恶意，而是交叉验证写入进程的PID和父进程。如果写入进程是合法的发布脚本或编译进程，则放行；如果写入进程是www-data、nobody这类Web服务运行账户，且父进程是nginx或apache，这极大概率是Webshell或远程代码执行漏洞被利用。这种基于进程链的审计比单纯的文件监控准确率高得多。

如果你的静态资源通过CDN分发，源站文件完好不代表用户访问到的文件是安全的。攻击者可能通过CDN的回源劫持、中间人攻击或直接攻破CDN边缘节点来替换缓存内容。你需要定期从不同地理区域的探测节点发起HTTP请求，获取CDN边缘缓存的实际内容，并计算哈希值与基线比对。探测时务必使用与实际用户相同的请求头，包括Accept-Encoding和User-Agent，因为某些CDN会根据请求头返回不同版本的文件。同时，检查CDN返回的Age和X-Cache头信息，确认当前命中的是边缘缓存还是回源响应。

静态资源被替换后，往往会在访问日志中留下细微痕迹。被注入恶意代码的JS文件体积通常会变大，导致响应体大小字段出现异常增长。你可以编写日志分析脚本，按资源路径分组统计一段时间内的平均响应大小和标准差。当某个资源的响应大小突然偏离历史均值超过一定阈值时，即使文件哈希尚未被巡检发现，也可以提前发出预警。此外，关注静态资源请求的User-Agent分布。正常情况下，图片和CSS请求的User-Agent应该以浏览器为主。如果某个静态资源突然被大量非浏览器User-Agent请求，可能是恶意代码在自动化下载执行。

一旦确认静态资源被替换，首要操作不是立即删除文件，而是保留现场。使用cp命令将恶意文件复制到隔离区，并用stat记录文件的完整时间戳和inode信息。然后立即切换流量到备用源站或回退到上一个安全的版本。恢复时不要用旧文件直接覆盖，因为攻击者可能已经在服务器上留下了定时任务或后门，直接覆盖会再次被替换。应该先下线受感染节点，从干净镜像重建环境，再将基线文件部署上去。事后分析恶意文件的代码逻辑，提取C2域名、远控地址或窃密接口，用于威胁情报更新和日志回溯。

很多静态资源被替换的根源不在生产服务器，而在开发环境或第三方依赖。攻击者通过污染npm包、篡改CDN提供的第三方库，或入侵设计师的电脑替换切图资源，将恶意代码注入到项目源码中。你需要在构建流水线中加入依赖项哈希锁定机制，对所有从npm、CDN引入的外部资源进行完整性校验。使用私有化仓库缓存经过审计的第三方库，避免每次构建时直接从公网拉取。对于设计师交付的图片资源，在提交到代码仓库前使用自动化脚本剥离所有元数据和不必要的注释块，消除隐写空间。

从根本架构上解决这个问题，可以考虑将静态资源托管到对象存储，并开启版本控制和合规保留策略。每次发版生成带有内容哈希的新文件名，旧版本文件保留但不对外暴露。前端页面引用时使用带哈希的文件名，这样即使某个文件被替换，攻击者也无法预测新的文件名。同时，对象存储的访问策略应设置为只允许通过CI/CD服务的IAM角色进行写入，彻底关闭任何直接上传的入口。这种架构下，攻击者即使获取了Web服务器的权限，也无法篡改静态资源，因为Web服务器本身就没有写入对象存储的权限。

静态资源完整性检测不是一次性工程，而是一个需要持续运行的闭环流程。建议将哈希巡检脚本部署为定时任务，频率根据业务敏感度设定，核心交易类网站建议每15分钟巡检一次。同时，将文件完整性监控接入SIEM系统，与登录审计、漏洞扫描结果进行关联分析。当多个低风险告警同时出现时，例如非工作时间的管理员登录加上静态资源哈希异常，应立即升级为高危事件。定期进行红蓝对抗演练，模拟静态资源被替换的场景，检验从检测到恢复的全流程响应时间是否满足业务要求。