EMQX LwM2M 网关安全修复:REGISTER/UPDATE 报告中敏感查询字段的过滤机制
后端物联网消息队列通信【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址https://gitcode.com/gh_mirrors/em/emqx点击查看免费下载本篇技术指南围绕 EMQX 开源仓库中的一个安全修复项展开LwM2M 网关在把设备的 CoAP REGISTER/UPDATE 请求翻译为 MQTT 消息时曾可能将 URI 查询参数中携带的password、secret、private_key、access_token等敏感字段一并写入上报到 MQTT 的消息体造成凭据泄露。读完本文你将理解 LwM2M 网关注册/更新上报的完整数据链路、敏感字段过滤的具体实现位置与判定规则、对应的回归测试用例以及如何在实际部署中规避同类风险。修复项背景本修复记录于 changes/ee/fix-17888.en.md原文如下Fixed an issue where the LwM2M gateway could include sensitive REGISTER query fields such aspassword,secret,private_key, andaccess_tokenin registration/update MQTT reports.即修复了 LwM2M 网关可能将 REGISTER 查询字段如password、secret、private_key、access_token包含在注册/更新 MQTT 报告中的问题。这是典型的信息泄露sensitive data exposure类缺陷——敏感凭据本应用于网关侧的身份校验却因数据透传被意外转发到了 MQTT 消息里。LwM2M 网关与 REGISTER/UPDATE 上报链路EMQX 的 LwM2M 网关位于 apps/emqx_gateway_lwm2m其职责是接收 LwM2M 客户端基于 UDP/DTLS 传输当前实现仅支持 v1.0.2详见 README.md并将设备的事件与消息翻译成 MQTT Publish 消息。设备上线时会在 CoAP 的/rd资源上发起 REGISTER 请求之后可通过 UPDATE 请求刷新注册信息这两类请求的 URI 查询参数中通常携带标准字段ep端点名称Endpoint Name设备唯一标识lt生命周期Lifetimelwm2m协议版本imei、device_id扩展字段非标准协议字段源码中已标注FIXME注释b、t等其他厂商扩展参数。从源码看网关解析这些查询参数的入口位于 emqx_lwm2m_channel.erl 的enrich_conninfo/2与enrich_clientinfo/2第 508-558 行enrich_conninfo提取ep、lt等用于连接信息enrich_clientinfo则额外提取imei作为用户名、password用于网关侧认证其中password属于“非标准协议字段”的扩展用法。设备完成注册后网关会将会话注册信息打包成#{msgType register, data RegInfo}结构发布到 MQTT对应register_init/2见 emqx_lwm2m_session.erl 第 465-478 行UPDATE 请求则走update/5流程第 416-463 行同样以update为msgType发布。上报的 MQTT 主题由translators.register/translators.update配置决定见 emqx_lwm2m_schema.erl 第 155-167 行 与uplink_topic/1的读取逻辑。问题就出在RegInfo的构造上如果直接沿用解析出的完整查询参数 Map那么设备在 REGISTER/UPDATE 请求里携带的任何键值包括敏感凭据都会被原样写进data字段并发布到 MQTT——订阅了注册/更新主题的任何 MQTT 客户端都能看到这些敏感信息。修复实现drop_sensitive_reg_info 敏感字段过滤本次修复的核心实现在 emqx_lwm2m_session.erl 中新增的drop_sensitive_reg_info/1函数drop_sensitive_reg_info(RegInfo) - maps:filter( fun(Key, _Value) - not emqx_utils_redact:is_sensitive_key(Key) end, RegInfo ).该函数遍历注册信息 Map凡是被emqx_utils_redact:is_sensitive_key/1判定为敏感键的键值对一律剔除。它在两条路径上被调用首次 REGISTER 路径append_object_list/2第 311-319 行在合并 URI 查询参数与 payload 中的对象列表之后、进行lt类型修正之前先调用drop_sensitive_reg_info(append_object_list2(Query, Payload))完成过滤确保register_init/2中发布的RegInfo不含敏感字段UPDATE 路径update/5第 425 行在将新查询参数与旧注册信息合并后同样执行drop_sensitive_reg_info(maps:merge(OldRegInfo, RegInfo))既过滤了本次 UPDATE 请求新带来的敏感字段也兜底清除了历史注册信息中残留的敏感数据。两条路径都经过统一过滤因此 REGISTER 与 UPDATE 两种上报消息以及由reregister/3触发的重注册均不再携带敏感字段。敏感键判定规则emqx_utils_redact:is_sensitive_key/1过滤所依赖的判定函数位于 apps/emqx_utils/src/emqx_utils_redact.erl。is_sensitive_key/1是一个覆盖多种数据形态原子、字符串、二进制的敏感键白名单与本次修复直接相关的条目包括键名匹配形态passwordpassword/password/passwordsecretsecret/secret/secretprivate_keyprivate_key/private_key/private_keyaccess_tokenaccess_token/access_token/access_token该模块同时覆盖了access_key_id、access_key_secret、api_key、api_secret、jwt、token等大量常见凭据键名见 第 34-102 行。这意味着 LwM2M 网关的过滤机制不只是针对修复说明中列举的四个字段——凡是查询参数中出现的、命中该敏感键表的键无论以字符串还是二进制形式传入都会被drop_sensitive_reg_info/1一并剔除为上报链路提供了较为全面的防护。值得说明的是过滤仅作用于上报到 MQTT 的注册信息RegInfo。password等字段在网关内部依然会被enrich_clientinfo/2读取并用于连接认证见 emqx_lwm2m_channel.erl 第 540-548 行即敏感信息仍可在“网关内部消费”只是不再被转发到 MQTT 主题上。回归测试验证修复配套了完整的回归测试位于 apps/emqx_gateway_lwm2m/test/emqx_lwm2m_SUITE.erl 的case02_update_deregister/1用例第 821-944 行。该用例构造的 REGISTER 请求故意携带了全部四类敏感参数coap://127.0.0.1:~b/rd?ep~tslt345lwm2m1 passwordpublicsecrettopprivate_keyprivaccess_tokentoken随后网关应返回{ok, created}同时上报的 MQTT 报告主题为lwm2m/endpoint/up/resp中data字段应只包含标准字段alternatePath、ep、lt、lwm2m、objectList并断言不存在任何敏感字段assert_no_secret_register_fields(#{data : Data}) - ?assertEqual( #{}, maps:with( [ password, secret, private_key, access_token ], Data ) ).maps:with/2会提取data中命中的键组成新 Map断言其等于空#{}即上述四个键一个都不允许出现见 第 6300-6312 行。同一用例随后发起 UPDATE 请求并再次调用assert_no_secret_register_fields(Update)断言 UPDATE 报告同样干净与源码中update/5的过滤逻辑一一对应形成了 REGISTER 与 UPDATE 双向的回归保障。配置参考与安全实践结合修复后的行为在生产环境使用 LwM2M 网关时可以从以下几点入手规避敏感信息风险避免在 REGISTER/UPDATE 查询参数中携带凭据。从源码看标准 LwM2M 注册协议并不要求这些字段emqx_lwm2m_channel.erl中已将imei/password等标注为“不属于标准协议”的 FIXME 扩展。即便本次修复保证了它们不会被转发到 MQTT凭据出现在 CoAP 查询参数中本身也会增加被记录、被截获的风险。若确有认证需求应优先使用网关的认证链emqx_gateway_ctx:authenticate/2配合正式机制处理。确认上报主题不被无关订阅者监听。REGISTER/UPDATE 报告发布到translators.register/translators.update配置的主题默认示例见 README.md 中的up/resp、up/update应结合 EMQX 的 ACL 规则限制这些主题的订阅权限。按需控制 UPDATE 上报频率。网关提供update_msg_publish_condition配置默认always可设为contains_object_list使仅当 UPDATE 携带对象列表时才发布见 emqx_lwm2m_schema.erl 与 emqx_lwm2m_session.erl 第 451-463 行 的should_publish_update/1判定逻辑。合理配置可减少不必要的数据落盘与转发面。升级并关注日志中的脱敏行为。本次修复与仓库既有的emqx_utils_redact脱敏体系一致网关在记录错误日志时也会调用emqx_utils:redact/1对查询参数脱敏见 emqx_lwm2m_channel.erl 第 553-555 行。建议使用包含该修复的版本确保注册/更新上报与日志两条路径都不再泄露敏感查询字段。小结本次安全修复通过在 LwM2M 会话层的 REGISTER 与 UPDATE 两条数据链路上统一引入drop_sensitive_reg_info/1借助emqx_utils_redact:is_sensitive_key/1的敏感键表过滤确保password、secret、private_key、access_token等凭据不会进入上报到 MQTT 的data字段配套的case02_update_deregister回归用例对两类报告做了断言兜底。对于自行基于 EMQX 网关协议栈做二次开发的场景本文所述的“内部消费、外部过滤”模式同样值得参考敏感字段可以在网关内用于认证但在跨协议转发时必须显式剥离。赞分享后端物联网消息队列通信【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址https://gitcode.com/gh_mirrors/em/emqx点击查看免费下载相关推荐FastJSON字段过滤PropertyPreFilters实现敏感信息脱敏FastJSON字段过滤PropertyPreFilters实现敏感信息脱敏 引言敏感信息泄露的隐形风险 在API接口开发中用户数据JSON序列化常面临两序列化后端KeystoneJS 关系Relationships完全指南字段、过滤器、定义与反向查询KeystoneJS 关系Relationships完全指南字段、过滤器、定义与反向查询 本指南以 KeystoneJS 官方文档 docs/docume后端VCR项目中的敏感数据过滤机制详解VCR项目中的敏感数据过滤机制详解 引言测试数据安全的挑战 在现代软件开发中HTTP接口测试是不可或缺的一环。然而测试过程中经常需要处理敏感数据如API测试开发工具上一篇5个简单步骤用Reset Windows Update Tool彻底解决Windows更新故障下一篇Windows更新卡住怎么办5分钟终极修复指南Reset Windows Update Tool完整解析创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考