3. CoAP安全威胁分析
CoAP 协议设计之初，主要考虑的是低功耗和轻量级。安全嘛，说实话，当时想得没那么周全。我在做物联网网关项目时，第一次用 CoAP 就被现实狠狠教育了一顿。今天我把最常见的五种攻击手法拆开揉碎讲给你听。你想想看，一个传感器节点可能只有几 KB 内存，跑不了 TLS，那攻击者会怎么搞它？
核心观点：CoAP 的 UDP 底座 + 无加密载荷 + 弱身份验证，构成了攻击面的“黄金三角”。这五种攻击不是理论推演，是真实战场上每天都在发生的事。
3.1 嗅探攻击：你的数据在裸奔
CoAP 默认跑在 UDP 上，消息是明文传输的。这意味着什么？只要攻击者能接入同一个局域网，或者在你的网关和节点之间某个位置搭个监听点，所有 CoAP 消息就跟没穿衣服一样。
我记得有一次做智能楼宇项目，客户说他们的温度传感器数据“很敏感”。我抓了个包给他看——温度值、湿度值、设备 ID、甚至固件版本号，全在报文里明文写着。他当场就沉默了。
我的建议：只要你的 CoAP 消息里包含任何你不希望路人甲看到的内容——传感器读数、控制指令、设备标识——就必须上加密。别信“内网安全”这种鬼话。我在多个项目里见过，内网被攻破往往就是从一台不起眼的摄像头开始的。
嗅探攻击能拿到什么？
- 载荷数据：温度、湿度、电压、开关状态等传感器读数
- 控制指令：PUT/POST 里的目标值，比如“设定温度 25°C”或“打开阀门”
- 元数据：Token、Message ID、URI-Path，这些可以用来辅助其他攻击
- 设备指纹：通过 Option 字段推断设备类型、固件版本
你可能会问：“那我不传敏感数据不就行了？”嗯，问题是很多场景下你根本不知道什么算敏感。一个智能电表的读数，结合时间戳，就能分析出家里有没有人。我在安全审计时见过太多这种案例了。
3.2 重放攻击：同一个消息，打你两次
重放攻击的原理很简单：攻击者把嗅探到的 CoAP 请求原封不动地再发一次。CoAP 本身没有内置防重放机制——它依赖的是 Token 和 Message ID，但这些字段太容易被预测了。
我亲身经历过一个智能门锁项目。门锁收到 CoAP PUT 请求“/lock/state = unlock”就会开锁。攻击者只要在门口蹲点，等合法用户用 App 开锁时抓一次包，然后自己重放这个请求——门就开了。你说吓不吓人？
避坑指南：我曾经在一个项目中看到团队用 Message ID 做防重放。他们以为 ID 递增就能防重放。结果呢？攻击者只要把 ID 改大一点，消息照样被接受。Message ID 是用于去重和匹配响应的，不是安全机制。别搞混了。
防重放的标准做法：
| 方案 | 原理 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 时间戳 + 窗口 | 消息携带时间戳，接收方只接受窗口内的消息 | 时钟同步良好的设备 | 低功耗设备时钟漂移严重，窗口设太大又失去意义 |
| Nonce + 序列号 | 每条消息携带唯一 Nonce，接收方记录已用 Nonce | 有状态设备 | Nonce 表会膨胀，内存小的设备扛不住 |
| 挑战-响应 | 先交换随机数，再基于随机数计算 MAC | 高安全场景 | 握手开销大，不适合频繁通信 |
3.3 中间人攻击：你在跟谁说话？
CoAP 基于 UDP，没有 TLS 握手那样的身份验证过程。攻击者只要能在通信路径上插入自己，就能扮演服务器欺骗客户端，或者扮演客户端欺骗服务器。
我参与过一个智慧农业项目，网关和传感器之间用 CoAP 通信。攻击者伪造了一个假网关，传感器把土壤湿度数据发给了假网关，假网关回了一个“灌溉指令”——结果大棚里的作物被淹了半亩。嗯，那次事故的直接损失不大，但暴露的问题很严重：传感器完全无法验证它收到的响应是不是来自真网关。
中间人攻击的典型手法：
- ARP 欺骗：在局域网内伪造 MAC 地址，劫持 CoAP 流量
- DNS 劫持：让 coap://sensor.example.com 解析到攻击者的 IP
- 路由劫持：在 6LoWPAN 网络中伪造路由公告
- 代理注入：在 CoAP 代理节点上做手脚
关键认知：没有传输层安全（DTLS/TLS），CoAP 的中间人攻击几乎无法防御。你可以在应用层加签名，但密钥分发又成了新问题。我个人建议：只要设备算力允许，优先上 DTLS。实在跑不动 DTLS 的设备，至少用 OSCORE 做端到端保护。
3.4 资源耗尽攻击：让物联网设备“累死”
物联网设备资源极其有限。一个典型的传感器节点可能只有 64KB RAM、几百 MHz 的 MCU、靠电池供电。攻击者不需要搞什么高深漏洞，只要发一堆精心构造的 CoAP 请求，就能让设备累趴下。
我见过最典型的案例：攻击者对一台 CoAP 服务器持续发送 Observe 注册请求，每次都用不同的 Token。服务器要为每个 Token 维护观察关系表，内存很快就爆了。设备重启后，攻击者再来一轮——循环往复，设备永远无法正常工作。
资源耗尽攻击的常见变种：
| 攻击类型 | 手法 | 影响 | 我见过的真实案例 |
|---|---|---|---|
| 放大攻击 | 伪造源 IP，发送小请求触发大响应 | 网络带宽耗尽 | 某厂商的 CoAP 代理被用作 DDoS 放大器 |
| 观察者洪泛 | 大量 Observe 注册请求 | 内存耗尽 | 智能路灯控制器频繁重启 |
| 分片耗尽 | 发送不完整的分片报文，占用重组缓冲区 | 无法处理合法请求 | 6LoWPAN 网络中的经典攻击 |
| 计算密集型请求 | 请求复杂的资源查询或计算 | CPU 满载、电池快速耗尽 | 某温控器被攻击后电池寿命从2年降到3天 |
避坑指南：我曾经在一个项目中看到团队只做了速率限制，没做资源配额。攻击者用不同的源端口绕过速率限制，照样把设备打挂了。记住：速率限制要结合源 IP、Token、URI 做多维度的配额。另外，对 Observe 注册一定要设上限，我一般建议不超过 32 个观察者。
3.5 URI 欺骗：指东打西
CoAP 的 URI 是资源标识的核心。攻击者可以通过篡改 URI 来诱导客户端访问错误资源，或者让服务器处理非预期的请求。
URI 欺骗的手法很多样：
- 路径遍历：用
../跳出资源目录，访问敏感文件 - URI 混淆：用
//、./、URL 编码绕过访问控制 - 代理 URI 重写：CoAP 代理修改请求的 URI，指向恶意资源
- 资源名称猜测：通过枚举 URI 发现隐藏资源
我审计过一个智能家居系统。它的 CoAP 服务器用 URI 路径做权限判断：/admin/ 开头的需要管理员权限，/user/ 开头的普通用户可访问。结果呢？攻击者用 /./admin/config 绕过了检查——因为服务器在解析 URI 时没做规范化。就这么一个小疏忽，整个系统的配置信息全暴露了。
我的建议：URI 解析一定要做规范化。把 ..、.、// 全部解析成标准路径后再做权限判断。另外，不要在 URI 里暴露敏感信息——比如设备密钥、会话 ID。我在代码审查时经常看到有人把 Token 直接放在 URI 里，这是大忌。
3.6 小结：这五种攻击，你防得住吗？
说实话，看完这五种攻击，你可能会觉得 CoAP 浑身都是漏洞。但别慌——这些攻击都有成熟的防御手段。嗅探靠加密、重放靠 Nonce 和时间戳、中间人靠 DTLS/OSCORE、资源耗尽靠配额和限流、URI 欺骗靠规范化。
关键是要在项目设计阶段就把安全考虑进去。我见过太多团队先把功能做出来，上线后再补安全——结果发现架构不支持，只能推倒重来。嗯，那滋味可不好受。