波仔
🛡️ 第二章 针对网络的攻击
📄 一句话概括

篡改不是"把数据删掉"，而是"让数据还是那副样子，但内容已经不是原来那个了"——它攻击的是完整性，而完整性最难的地方在于：你不比对，就看不出来。

📝 本节和前面几节的关系

上一节（数据的偷窥）讲的是看（机密性）。这一节讲的是改（完整性）——攻击者从旁听席走到操作台前。

按第一章的三要素排，两节的顺序恰好对应它们的发现难度（见 信息安全的三要素）：可用性出事你立刻知道，完整性出事你能查，机密性出事你这边一切正常。这一节正好落在中间那一档——它有痕迹，但需要你主动去比。

一、"可靠"在这里是什么意思

教材用的词是"可靠性"，但落到实处，它说的是完整性的两层含义：

  1. 内容没被动过——你看到的就是原来那个；
  2. 来源没被换过——确实是那个人给的，不是别人冒充的。

这两层里，第一层是"数据完整性"，第二层其实已经跨到了"真实性"（2-3 会专门讲）。所以这一节的重点是第一层：数据在存储、传输、处理的过程中，是否被非法改动。

要注意一个区别：

攻击方式 破坏的是什么 典型表现
删除／加密勒索 可用性 文件打不开、打不开了
篡改 完整性 一切看起来正常，内容是假的

篡改比删除更危险，因为删除是"明显的故障"，篡改是"安静的谎话"。

二、篡改会发生在哪些环节

数据的一生有四个阶段，每个阶段都能被改：

  1. 传输中——数据在链路上被截下来改掉再放回去（中间人正好便于做这件事）。
  2. 存储中——直接改数据库、改文件、改日志。
  3. 处理中——代码或配置被改，于是计算结果是错的，但每一步都"正常执行"。这是最隐蔽的一种。
  4. 展示中——前端页面被改，后台数据其实是对的。这在网站被篡改（俗称"挂黑页"）里最常见。

第四种最容易被低估：很多单位只查数据库，不查网页文件。但对外面的人来说，你网站上显示什么，你就是什么。

三、几种典型手法

四、怎么防：三个层次

把防篡改的手段按"能证明什么"排，从弱到强：

  1. 权限控制——不让不该改的人有权限改。属于第一道门（对应第一章的"最小权限原则"）。
  2. 完整性校验（校验和／散列）——给数据算一个"指纹"，需要时重算一遍比对。指纹变了就说明动过，但注意：它只能发现改动，不能阻止改动，也不能防止"改了之后把指纹一起改掉"。
  3. 数字签名——用私钥签名。这一层同时解决三件事：完整性（内容改了签名就不对）、真实性（确实是持私钥的人签的）、不可抵赖性（事后不能否认）。这就是第一章里说的"数字签名一次覆盖三项"。

对要长期保存、要经得起质疑的数据，第三层才是终局。前两层是日常。

五、动手 Demo：文件完整性监控怎么发现网页被改

下面这段脚本给一个网站做"体检"：先记下一份基线（每个文件的摘要），再和当前状态比对，找出所有变化。

# 基线：网站发布时的文件与摘要
baseline = {
    "index.html":     "a1b2c3d4",
    "about.html":     "77e0f19a",
    "product.html":   "3c9d52be",
    "contact.html":   "b81f6a07",
    "media/logo.png": "5e2ac114",
    "media/promo.jpg":"9f4d7b62",
    "js/app.js":      "d0c3e881",
    "js/vendor.js":   "6a7f0d29",
}
# 当前：逐项比对，找出 内容改动 / 新增 / 删除 三类变化

实跑输出：

  文件                        基线摘要        当前摘要        判定
  ------------------------------------------------------------------
  index.html                a1b2c3d4      ff0012ab      内容已改动
  about.html                77e0f19a      77e0f19a      一致
  product.html              3c9d52be      3c9d52be      一致
  contact.html              b81f6a07      b81f6a07      一致
  media/logo.png            5e2ac114      5e2ac114      一致
  media/promo.jpg           9f4d7b62      9f4d7b62      一致
  js/app.js                 d0c3e881      d0c3e881      一致
  js/vendor.js              6a7f0d29      48c1ba90      内容已改动
  shell.php                 ——            e3b0c442      新增（基线里没有）

  结果：一致 6 ｜ 已改动 2 ｜ 新增 1 ｜ 删除 0

  ① 最该看的不只是【被改的】，还有【多出来的】——
     一个本该只放静态页面的站，多出一个 shell.php，
     说明攻击者已经能往服务器上写文件了。
  ② js/vendor.js 这类第三方脚本文件被改，往往是从上游组件带进来的——
     这是 2026 年最典型的一类篡改，改的不是你的代码，是你引用的代码。
  ③ 文件完整性监控的作用不是阻止篡改，而是【让篡改被看见】。
     没有基线，改了也不知道；有基线，改动本身就是证据。

读这个输出：注意两处。第一处是 shell.php 那行——它是新增，不是改动。这意味着攻击者已经拿到了往服务器写文件的能力，比首页被换掉严重得多。第二处是 js/vendor.js——它是个第三方脚本，被改往往不是有人直接动了你的服务器，而是上游的包被投毒了。这两种"被改"的处置方式完全不同，所以分类比发现更重要。

六、⚠️ 2026 现状

30 秒实验

做一次最简单的完整性检查：

  1. 选一个文件（比如一份重要合同的扫描件），给它算一个摘要值。Windows 可以在 PowerShell 里用 Get-FileHash 路径；Linux／macOS 用 shasum -a 256 路径。
  2. 把结果抄在纸上或另存到别处（不要存在同一个文件夹里）。
  3. 改一个字符再保存，重算一次摘要，看两个值是不是完全不同——你会发现哪怕只改一个标点，摘要也会面目全非。

这一节要带走的一句是：篡改不需要让你看见它——所以你必须提前留一个"原样"的凭据，不然你连"变了"都不知道。

常见误区

  1. 错误：文件加了权限，别人改不了，所以不会有事。——纠正：权限控制的是合法路径。攻击者一旦拿到了高权限账号（或被攻破的应用进程），你设的权限就形同虚设。能改而没改和改不了是两回事，需要靠"有没有被改"的证据来判断。

  2. 错误：算了校验和就够了，不用签名。——纠正：校验和只能证明"现在的内容和摘要对得上"。如果改动者连摘要一起改，校验就通过了。要对抗这一点，摘要本身必须被保护起来（存到攻击者碰不到的地方，或者用私钥签名）。校验和的强度取决于摘要存放在哪里。

  3. 错误：网站被篡改，恢复一下文件就行。——纠正：篡改是入侵成功的信号，不是孤立事件。要按入侵事件处置：查入侵路径、清恶意文件、修漏洞、重置凭据、持续观察。只恢复页面，等于把门开着把报警器关掉。

  4. 错误：第三方的组件改了不关我的事。——纠正：只要你的系统在用它，后果就是你的。对供应链的处置是：锁定依赖的确切版本、留一份依赖清单、对关键更新先验证再上。"我没改"和"没被改"不是同一个意思。

自测三问（点开对答案） 1. 为什么说篡改比删除"更危险"？ —— 因为**可见性不同**。删除造成的是明显故障，用户立刻知道；篡改让数据保持原来的形态，**内容却是假的**，可以长期不被发现。而且假数据往往会被**当作事实使用**——用于决策、对外发布、进入报表，**污染扩散出去之后收不回来**。 2. 校验和与数字签名，各自能证明什么？差在哪里？ —— 校验和只能证明**内容与摘要一致**（完整性），但摘要本身可以被一起改掉。数字签名在完整性之外还提供**真实性**（确认是谁签的）和**不可抵赖性**（事后不能否认），并且**签名无法被伪造**。所以校验和适合日常快速比对，数字签名适合需要长期、可对外证明的场景。 3. 为什么发现网页被篡改后，不能"把页面改回来就完事"？ —— 因为篡改说明**攻击者已经具备未授权访问的能力**。他今天改页面，明天可能读数据、装后门、改配置。正确处置是把它当**入侵事件**：查明入侵路径、清除恶意文件、修补被利用的漏洞、重置相关凭据、并持续观察是否还有残留。**只修表面症状，等于把已确认的门锁漏洞留着不动。**

相关笔记