确认页面是否被篡改需三步：一比对线上html与ci/cd可信产物的sha256哈希；二检查异常script标签、隐藏注释及base64载荷；三溯源src属性、内联js拼接、构建注释和危险meta标签，同时排查服务器日志、webdav/ftp权限及部署凭证泄露。
静态 HTML 页面被篡改，通常意味着服务器文件系统或部署流程已被入侵，而非运行时漏洞。它不依赖后端逻辑，所以常规的 SQL 注入、XSS 扫描工具基本无效；真正要查的是「谁改了文件」「怎么改的」「改了哪些」。
如何快速确认页面是否被篡改
不要只比对当前页面和本地备份——攻击者可能只动了某几行、某个 script 标签或隐藏的 base64 载荷。重点看三类痕迹：
- 用
curl -s https://example.com/index.html | shasum -a 256计算线上文件哈希，与可信构建产物哈希比对（不是开发机上的“原始”文件，而是 CI/CD 流水线最后输出的 artifact） - 检查 HTML 中是否存在异常的
<script></script>块：比如域名非常规（cdn[.]jssrv[.]xyz）、无 src 却含大段混淆 JS、或使用document.write动态加载外部域 - 查看页面末尾或注释区是否藏有可疑字符串，如
<!-- injected by attacker -->、/* v2.1.7 */（版本号与你项目无关）、或 base64 编码的 JS 片段（eval(atob("..."))）
从 HTML 源码反向溯源修改路径
静态页面本身不记录修改者，但它的内容结构会暴露攻击入口点。重点关注以下四类可写位置：
- 所有带
src属性的标签：检查<script src="..."></script>、<img src="...">、<iframe src="..."></iframe>的 URL 是否指向非你控制的域名，尤其是用了协议相对路径（//evil.com/x.js）或短链跳转 - 内联 JavaScript 中的动态拼接：比如
location.href = '/page?ref=' + document.referrer—— 若 referrer 可控且未过滤，就可能被诱导写入恶意重定向 - HTML 注释中嵌入的构建信息：有些 CI 工具会把 commit hash 或 branch 名写进注释（
<!-- build: main-abc123 -->），若该 hash 在你 Git 记录里不存在，说明文件被外力覆盖 - meta 标签中的危险配置：如
<meta http-equiv="refresh" content="0;url=https://phish.site">，这种重定向无法通过 CSP 拦截，只能靠人工识别
为什么不能只靠文件时间戳判断
攻击者上传篡改后的 HTML 时，几乎总会用 touch -d "2024-01-01" index.html 重置 mtime/atime，让 ls -la 看起来毫无异常。更可靠的方式是：
- 检查 Web 服务器访问日志中对应路径的 PUT / POST 请求（尤其 Nginx 的
access_log中出现"PUT /index.html HTTP/1.1"） - 排查是否启用了 WebDAV、FTP 匿名登录、或 CMS 后台的「模板编辑」功能（即使页面是静态的，后台仍可能直写文件）
- 验证部署账号权限：如果 CI 使用的 deploy 用户能直接
ssh到生产机并sudo cp，那问题不在 HTML，而在凭证泄露或密钥硬编码
自动化检测建议与限制
可以写一个轻量脚本定期抓取关键页面并做规则匹配，但要注意边界：
- 用正则匹配常见黑帽关键词：
/\b(?:eval|document\.write|atob\(|javascript:|base64,)/i，但别依赖它发现所有变种（比如用["e","v","a","l"].join("")绕过） - 检查响应头中是否缺失
Content-Security-Policy，尤其缺script-src 'self'会让内联恶意脚本更容易生效 - 注意：所有基于内容的扫描都必须配合可信基线。没有基线的“异常检测”，90% 是误报（比如你新上线的埋点 SDK 就会被当成黑产 JS）
最常被忽略的一点：静态页面被篡改，99% 不是因为 HTML 本身有漏洞，而是部署链路存在薄弱环节——Git 仓库私钥泄露、CI 日志明文打印密码、S3 存储桶 ACL 设置为 public-write。查 HTML 只是第一步，真正的根因永远在它之外。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
