网站恶意代码检测_怎样记录改动前后的基线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9cb462b76509.html
📄
网站恶意代码检测_怎样记录改动前后的基线
记录改动前后的基线，核心是留下可对比的证据：在每次改动前保存页面原始文件与关键指纹，改动后再采集同一组数据，逐项比对差异。基线不是一次性的截图，而是一套可重复执行的快照流程，让“哪里被改了、改了什么、是否属于恶意注入”有据可查。
先确定基线要保存哪些内容
网站恶意代码检测中，基线记录的对象应覆盖最容易被注入的位置。建议保存以下四类内容：
- 页面源码：首页、栏目页、文章页各取若干样本，保存为纯文本文件。
- 文件指纹：对核心脚本、模板、配置文件计算哈希值，例如用
sha256sum index.php记录。 - 结构清单：目录下新增或删除的文件列表，特别是上传目录、缓存目录。
- 外部引用：页面中引用的第三方脚本地址、内联脚本片段。
保存时按日期建立目录，例如 baseline/2025-06-01/，避免新旧文件混在一起。每一项都要写清楚采集时间与采集范围，否则后续比对时无法判断差异来自改动还是来自采集口径变化。
改动前如何采集第一份基线
采集动作要固定命令、固定范围，保证下次能用同样方式复现。
- 查什么：页面源码。怎么查：用命令行抓取并保存，例如
curl -s https://example.com/ > before.html。结果说明什么：得到改动前的完整HTML，作为后续逐行比对的基准。 - 查什么：文件哈希。怎么查：对模板与入口文件批量计算，例如
find ./templates -type f -exec sha256sum {} \; > before-hash.txt。结果说明什么：任何字节级改动都会让哈希变化，能快速定位被篡改文件。 - 查什么：目录文件清单。怎么查：
find . -type f -newer before-hash.txt或直接导出完整列表。结果说明什么：发现改动后新增的可疑文件，如伪装成图片的脚本。 - 查什么：外部引用。怎么查：从保存的HTML中提取
src与href指向的外部地址。结果说明什么：识别是否被插入了陌生的第三方脚本域名。
如果时间和人手有限，优先做第1项和第2项：页面源码加核心文件哈希，这两项成本最低，覆盖最常见的注入位置。
改动后如何做差异比对
改动完成后，用与采集基线完全相同的命令再采集一次，保存为 after.html 和 after-hash.txt，然后逐项比对。
- 源码比对：
diff before.html after.html。输出中新增的行若包含<script>、iframe、eval、编码后的字符串，需要重点核查。 - 哈希比对：
diff before-hash.txt after-hash.txt。只关注哈希值变化的文件，未变化的文件不必逐一打开。 - 清单比对：对比两次文件列表，找出新增文件。新增的可执行文件若出现在上传目录，属于高风险信号。
- 引用比对：对比两次提取出的外部地址，新增的陌生域名应直接列为待查项。
比对结果分三种情况处理：差异与本次改动预期一致，记录归档即可；差异超出预期但内容可读，人工确认是否为模板或插件更新；差异包含混淆代码、陌生外链或新增可执行文件，按疑似恶意代码处理，先隔离再分析。
判断差异是否属于恶意注入
并非所有差异都是恶意代码。以下特征组合出现时，恶意可能性显著上升：
- 代码被压缩、编码或使用
eval、base64_decode等动态执行方式。 - 注入位置集中在页面底部、
<body>开头或所有页面共用的模板文件。 - 新增外部脚本域名与站点业务无关，且无法在代码仓库中找到对应提交记录。
- 文件修改时间与已知的部署、更新记录不吻合。
反过来，如果差异能在版本控制记录、插件更新日志或运维操作记录中找到对应来源，就可以排除恶意注入。因此基线记录最好与代码提交记录、部署记录放在同一时间线上对照。
让基线可长期复用的执行要点
基线只有能重复使用才有价值。建议固定三件事：采集命令写成脚本，避免每次手工输入导致口径不一致；采集范围明确列出目录和页面清单，不随意增减；每次改动都保留前后两份基线，不覆盖历史文件。对于时间有限的团队，可以只对核心模板、入口文件和首页做基线，但一旦发生疑似注入，必须扩大到全站文件哈希比对。第三方估算流量、搜索引擎报告与站内统计口径不同，都不能替代文件层面的基线证据，诊断恶意代码应以源码和文件指纹的直接比对为准。
下一步：选定三个最关键的页面和两个核心模板目录，今天就采集第一份基线，并把采集命令保存为可重复执行的脚本。
