HTTP和MQTT概述

一、HTTP和MQTT的基本介绍

（一）HTTP（超文本传输协议）

1. 基本特性

• 通信模式：基于请求-响应模型，客户端（设备）主动发起请求，服务器（云端）返回响应。
• 协议层：应用层协议，基于TCP，默认端口80（HTTP）或443（HTTPS）。
• 数据格式：通常使用RESTful API，数据以JSON/XML格式传输。
• 状态管理：无状态协议，每次请求需携带完整信息（如身份认证）。

2. 优点

• 通用性强：几乎所有云平台和编程语言都支持，适合与Web服务集成。
• 安全性成熟：通过HTTPS（SSL/TLS）加密，支持OAuth、JWT等认证机制。
• 灵活性：适合传输复杂数据（如文件上传、图像处理）。

3. 缺点

• 高开销：请求头信息较大（如Cookie、Header），占用更多带宽。
• 实时性差：客户端必须主动轮询（Polling）才能获取新数据，导致延迟和资源浪费。
• 资源消耗：频繁的TCP连接建立/关闭对低功耗设备不友好。

4. 典型场景

• 设备定期上报数据（如每天上报一次的环境传感器）。
• 需要与现有Web服务集成（如调用云平台的REST API）。
• 传输非实时的大数据块（如固件升级、日志上传）。

（二）MQTT（消息队列遥测传输）

1. 基本特性

• 通信模式：基于发布-订阅模型，设备（发布者）向主题（Topic）发送消息，云端（订阅者）监听主题。
• 协议层：应用层协议，基于TCP，默认端口1883（MQTT）或8883（MQTTS）。
• 数据格式：轻量级二进制协议，消息体小（最小仅2字节头部）。
• 状态管理：支持会话保持（Session），断线后自动重连并恢复消息。

2. 核心功能

• QoS等级：提供三种消息可靠性保障：
  • QoS 0：最多一次（可能丢失）。
  • QoS 1：至少一次（可能重复）。
  • QoS 2：精确一次（可靠但延迟高）。
• 遗嘱消息（LWT）：设备异常离线时，代理自动发布预设消息。
• 保留消息（Retained Message）：新订阅者能立即获取主题最新状态。

3. 优点

• 低功耗：协议开销极小，适合电池供电设备。
• 高实时性：支持双向通信，云端可主动推送消息到设备。
• 高扩展性：通过主题分层（如 sensor/temperature/room1）轻松管理海量设备。

4. 缺点

• 依赖代理服务器：需部署MQTT Broker（如Mosquitto、EMQX、阿里云IoT平台）。
• 复杂性：需设计合理的主题结构和QoS策略。

5. 典型场景

• 物联网实时监控（如智能家居设备状态同步）。
• 低带宽环境（如NB-IoT、LoRa网络）。
• 一对多广播（如同时控制多个设备）。

二、HTTP和MQTT安全的通信过程

（一）安全的 HTTP 通信过程

1. 协议配置

• 强制使用 HTTPS：
  • 禁用 HTTP 明文传输，所有请求通过 TLS 1.2+ 加密。
  • 使用权威 CA 颁发的证书，避免自签名证书导致中间人攻击。

2. 身份认证

• 安全的认证机制：
  • OAuth 2.0：设备通过授权服务器获取访问令牌（Access Token），令牌需设置短有效期（如 1 小时）。
  • JWT（JSON Web Token）：签名算法使用 HMAC-SHA256 或 RSA，避免使用弱算法（如 HS256 密钥需足够复杂）。
  • API Key：结合 IP 白名单限制请求来源，避免 Key 泄露后被滥用。

3. 权限控制

• RBAC（基于角色的访问控制）：
  • 按设备角色分配权限（如 device:read 仅允许查询数据，device:write 仅允许上报数据）。
  • 服务端验证请求路径和方法的权限（如 GET /api/sensor 需 sensor:read 权限）。

4. 请求与响应防护

• 防重放攻击：
  • 请求头中附加时间戳（Timestamp）和随机数（Nonce），服务端校验时间窗口（如 ±5 分钟）和 Nonce 唯一性。
• 防 CSRF：
  • 为关键操作（如设备控制）添加 CSRF Token，或设置 Cookie 的 SameSite=Strict 属性。

示例流程：

1. 设备发起 HTTPS 请求 →

   GET /api/temperature HTTP/1.1

   Authorization: Bearer <JWT Token>

   Timestamp: 1620000000

   Nonce: abc123

2. 服务端验证 →

   - 检查 TLS 证书有效性

   - 校验 JWT 签名和有效期

   - 验证 Timestamp 和 Nonce 是否合法

   - 检查 RBAC 权限（是否允许读取温度数据）

3. 返回响应 →

   HTTP/1.1 200 OK

   {"temperature": 25}

（二）安全的 MQTT 通信过程

1. 协议配置

• 强制使用 MQTTS：
  • 启用 TLS 加密（端口 8883），禁用明文 MQTT（端口 1883）。
  • Broker 配置强密码套件（如 TLS_AES_256_GCM_SHA384）。

2. 身份认证

• 客户端证书双向认证：
  • 设备和服务端（Broker）均使用 X.509 证书，验证双向身份。
  • 证书需绑定设备唯一标识（如序列号）。
• 用户名/密码增强：
  • 密码哈希存储（如 bcrypt 或 Argon2），避免明文存储。
  • 限制失败登录尝试次数，防止暴力破解。

3. 权限控制

• ACL（访问控制列表）：
  • Broker 按 Topic 层级限制设备的发布/订阅权限（如 device/{id}/data 仅允许对应 ID 的设备发布）。
  • 禁用通配符 # 和 + 的全局订阅（避免敏感 Topic 泄露）。

4. 消息安全

• QoS 等级选择：
  • 关键指令使用 QoS 2（确保精确一次投递），常规数据使用 QoS 1（平衡可靠性与性能）。
• 遗嘱消息（LWT）保护：
  • 设置私密 Topic（如 device/{id}/status），避免 LWT 泄露设备离线状态。

示例流程：

1. 设备连接 Broker →

   - 客户端证书验证（双向 TLS）

   - 提交用户名/密码（加密传输）

2. Broker 鉴权 →

   - 检查证书合法性

   - 查询 ACL 规则（是否允许发布到 `sensor/123/temperature`）

3. 设备发布消息 →

   Topic: sensor/123/temperature

   Payload: {"value": 25, "timestamp": 1620000000}

   QoS: 1

4. Broker 转发消息 →

   - 仅允许订阅了 `sensor/123/#` 的云端服务接收

   - 记录消息投递状态（QoS 1 需确认 ACK）

三、HTTP和MQTT可能出现安全隐患的环节

（一）HTTP协议安全隐患环节

1. 传输层安全缺失

• 问题：未强制使用 HTTPS，明文传输敏感数据（如密码、API Key）。
• 风险：中间人攻击（MITM）、数据窃听、篡改。
• 场景：
  • 攻击者通过公共 Wi-Fi 抓包获取设备发送的明文凭证。
  • 篡改 HTTP 响应，注入恶意代码（如固件升级包）。

2. 认证与授权缺陷

• 问题：
  • 弱认证机制（如 Basic Auth 明文传输密码）。
  • 未验证 Token 权限范围（如 JWT 未绑定设备角色）。
• 风险：身份伪造、越权访问。
• 场景：
  • 攻击者截获 Basic Auth 的 Base64 编码密码，解码后冒充设备。
  • 设备 A 使用 JWT 访问设备 B 的数据（水平越权）。

3. 会话管理漏洞

• 问题：
  • 使用长有效期 Token 或 Cookie，缺乏刷新机制。
  • 未启用 CSRF 防护。
• 风险：Token 泄露导致持久化攻击、CSRF 恶意操作。
• 场景：
  • 攻击者窃取长期有效的 API Key，持续访问云端数据。
  • 恶意网站诱导用户浏览器发送已认证的请求（如删除设备配置）。

4. 输入验证不足

• 问题：
  • URL 路径或参数未校验合法性（如 /api/device/{id} 的 id 可遍历）。
  • 未过滤恶意负载（如 SQL 注入、XSS）。
• 风险：数据泄露、服务端漏洞利用。
• 场景：
  • 通过修改 id 参数越权访问其他设备信息（如 id=100 → id=101）。
  • 上传恶意脚本文件触发服务端漏洞。

5. 日志与监控缺失

• 问题：未记录设备请求日志或忽略异常行为告警。
• 风险：无法追溯攻击来源，隐蔽性攻击长期存在。
• 场景：
  • 攻击者通过低频扫描 API 端点，长期未被发现。

（二）MQTT协议安全隐患环节

1. Broker 配置不当

• 问题：
  • 允许匿名连接（默认配置未禁用）。
  • 未启用 MQTTS（TLS 加密）。
• 风险：未授权访问、敏感数据泄露。
• 场景：
  • 攻击者直接连接 MQTT Broker，订阅所有 Topic 获取设备数据。

2. Topic 权限滥用

• 问题：
  • ACL 配置宽松（如允许订阅通配符 #）。
  • 未隔离不同设备的 Topic 层级（如 device/{id}/data）。
• 风险：数据泄露、恶意指令注入。
• 场景：
  • 攻击者订阅 sensor/# 获取所有传感器数据。
  • 向 device/+/control 发布关机指令，导致大规模设备下线。

3. 认证机制薄弱

• 问题：
  • 使用弱密码或默认凭证（如 admin:admin）。
  • 未启用客户端证书双向认证。
• 风险：密码爆破、设备冒充。
• 场景：
  • 攻击者通过字典攻击破解 MQTT 密码，获取 Broker 控制权。
  • 伪造合法客户端 ID 发布虚假数据。

4. 消息安全缺失

• 问题：
  • 未合理使用 QoS（如关键指令使用 QoS 0）。
  • 遗嘱消息（LWT）泄露敏感状态（如 device/offline）。
• 风险：消息丢失、设备状态暴露。
• 场景：
  • QoS 0 导致设备未收到关键配置更新。
  • 监听 LWT Topic 得知设备离线，发起 DDoS 攻击。

5. 资源耗尽攻击

• 问题：
  • Broker 未限制客户端连接数或消息频率。
  • 未防御大消息负载（如 10MB+ 消息）。
• 风险：服务拒绝（DoS）、系统崩溃。
• 场景：
  • 攻击者发起海量连接耗尽 Broker 资源。
  • 发送超大消息导致 Broker 内存溢出。

四、漏洞调研

（一）HTTP协议相关漏洞

1. CVE-2021-44228（Log4j2 远程代码执行）

• 漏洞类型：远程代码执行（RCE）
• CVSS 评分：10.0（最高危）
• 漏洞原理：
  Apache Log4j2 日志库在处理用户输入时，未对 ${jndi:ldap://...} 这类 JNDI 注入 表达式进行过滤。攻击者可通过 HTTP 请求头（如 User-Agent、X-Forwarded-For）插入恶意 payload，触发远程加载并执行恶意代码。
• 影响范围：
  Log4j2 2.0-beta9 至 2.14.1 版本，波及几乎所有基于 Java 的 Web 应用（如 ElasticSearch、Apache Solr）。
• 修复建议：
  1. 升级至 Log4j2 2.17.0+ 版本。
  2. 禁用 JNDI 功能（设置 log4j2.formatMsgNoLookups=true）。
• 参考：NVD CVE-2021-44228

2. CVE-2017-5638（Apache Struts2 RCE）

• 漏洞类型：远程代码执行（RCE）
• CVSS 评分：10.0
• 漏洞原理：
  Apache Struts2 框架的 Jakarta Multipart 解析器在处理文件上传请求时，未正确校验 Content-Type 头中的恶意表达式（OGNL 表达式），导致攻击者可构造恶意 HTTP 请求执行任意命令。
• 影响范围：
  Struts 2.3.5 至 2.3.31、2.5 至 2.5.10 版本。
• 修复建议：
  1. 升级至 Struts 2.3.32 或 2.5.10.1+ 版本。
  2. 删除 Content-Type 头中的非法字符。
• 参考：Apache Struts2 公告

3. CVE-2022-22963（Spring Cloud Function SPEL 注入）

• 漏洞类型：远程代码执行（RCE）
• CVSS 评分：9.8
• 漏洞原理：
  Spring Cloud Function 在处理 HTTP 请求的路由参数（spring.cloud.function.routing-expression）时，未对 SPEL 表达式进行过滤，攻击者可注入恶意表达式执行系统命令。
• 影响范围：
  Spring Cloud Function 3.1.6、3.2.2 及更早版本。
• 修复建议：
  1. 升级至 3.1.7 或 3.2.3+ 版本。
  2. 禁用动态路由功能（spring.cloud.function.routing.enabled=false）。
• 参考：Spring Security 公告

4. CVE-2021-41773（Apache HTTP Server 路径穿越）

• 漏洞类型：路径穿越与信息泄露
• CVSS 评分：7.5 → 9.8（后续更新）
• 漏洞原理：
  Apache HTTP Server 2.4.49 版本在 URL 规范化处理中存在缺陷，攻击者可通过构造包含 ../ 的 HTTP 请求（如 GET /cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd），绕过路径限制，读取服务器上的敏感文件（如 /etc/passwd）。
• 影响范围：
  Apache HTTP Server 2.4.49 版本。
• 修复建议：
  升级至 2.4.50+ 版本。
• 参考：Apache HTTP Server 公告

5. CVE-2019-19781（Citrix ADC 目录遍历）

• 漏洞类型：目录遍历与 RCE
• CVSS 评分：9.8
• 漏洞原理：
  Citrix Application Delivery Controller（ADC）的未授权 HTTP 接口（/vpn/../vpns/）存在目录遍历漏洞，攻击者可上传恶意 XML 文件，触发模板注入执行任意代码。
• 影响范围：
  Citrix ADC 10.5、11.1、12.0、12.1、13.0 版本。
• 修复建议：
  1. 安装 Citrix 官方补丁。
  2. 禁用未授权接口，限制访问来源 IP。
• 参考：Citrix 安全公告

6. CVE-2020-5902（F5 BIG-IP RCE）

• 漏洞类型：远程代码执行（RCE）
• CVSS 评分：9.8
• 漏洞原理：
  F5 BIG-IP 的 TMUI（Traffic Management User Interface）组件未对 HTTP 请求的 solr 参数进行过滤，攻击者可构造恶意请求执行系统命令。
• 影响范围：
  BIG-IP 11.6.x、12.1.x、13.1.x、14.1.x、15.0.x、15.1.x。
• 修复建议：
  1. 升级至 11.6.5.2+、12.1.5.2+、13.1.3.4+、14.1.2.6+、15.1.0.4+。
  2. 限制 TMUI 接口的访问权限。
• 参考：F5 安全公告

7. CVE-2018-11776（Apache Struts2 命名空间RCE）

• 漏洞类型：远程代码执行（RCE）
• CVSS 评分：9.8
• 漏洞原理：
  Apache Struts2 在处理未正确配置命名空间的 Action 时，攻击者可构造恶意 HTTP 请求，通过 redirect: 或 redirectAction: 前缀触发 OGNL 表达式注入。
• 影响范围：
  Struts 2.3 至 2.3.34、2.5 至 2.5.16 版本。
• 修复建议：
  升级至 Struts 2.3.35 或 2.5.17+ 版本。
• 参考：Apache Struts2 公告

（二）MQTT协议相关漏洞

1. 认证与授权漏洞

• 漏洞原理：MQTT Broker 默认允许匿名访问或使用弱密码（如默认 admin:admin），攻击者可订阅敏感 Topic 或发布恶意指令。
• 案例：CVE-2022-35611（MQTTRoute 因缺乏 CSRF 令牌导致未授权操作仪表盘）。
• 修复建议：禁用匿名访问，启用客户端证书双向认证，配置细粒度 ACL（如限制 Topic 订阅权限）。

2. 传输层漏洞（CVE-2020-13821）

• 漏洞原理：HiveMQ 4.3.2 版本因未过滤客户端 ID 中的恶意负载，导致存储型 XSS（如通过 <img> 标签触发弹窗）。
• 修复建议：对客户端输入进行编码校验，限制特殊字符。

3. 资源耗尽攻击（CVE-2021-33176）

• 漏洞原理：VerneMQ Broker 因处理异常输入时内存消耗失控，导致拒绝服务（DoS）。
• 修复建议：升级至 1.12.0+ 版本，配置消息速率限制和负载大小控制。

4. 协议实现漏洞（CVE-2016-3088）

• 漏洞原理：Apache ActiveMQ 的 Fileserver 接口允许通过 HTTP PUT 和 MOVE 请求写入任意文件（如 Webshell 或 Cron 任务），进而控制服务器。
• 影响：影响 ActiveMQ 5.0.0–5.13.2。

修复建议：升级至 5.14.0+ 版本，禁用 Fileserver 功能。