今年年初我开始把一部分精力从常规Web漏洞挖掘转到物联网和低代码平台的交叉场景原因很简单主流Web端的目标越来越难出结果。厂商的安全建设早就跟上来了众测平台上热门目标撞车率极高你上午刚提交一个接口越权下午就有人报告同一条路由。相比之下物联网设备侧和低代码平台侧的漏洞挖掘目前还处于“会做的人少、资产多、覆盖不足”的阶段一次完整授权测试跑下来往往能梳理出别人没看到的三四个高危点报告评分天然占优势。这篇文章就围绕这个方向展开——为什么它算蓝海、设备侧怎么挖、平台侧怎么挖、以及怎么把一条完整链路写成高分报告。适合两类人刚入门SRC想找差异化路线的选手和企业里负责安全建设、想补自家物联网资产评估盲区的同学。我先说结论这个方向值得投入但如果只会扫端口、跑工具那和Web端没有任何区别。真正有价值的是搞清楚设备侧、平台侧以及两者之间数据链路各自有哪些脆弱点然后想办法把它们串起来。1. 蓝海判断为什么物联网低代码比Web端更容易出高分1.1 三道门槛把大部分挖掘者挡在门外先说结论这个方向竞争少不是因为没价值而是因为存在三道天然门槛。第一道是资产定位门槛。Web端的目标可以靠域名一搜一大把物联网设备却常常散落在私有网段、客户局域网和运营商APN后面即使暴露到公网很多也不走标准80/443端口而是用8080、1883、5683或者干脆封装一个自定义端口光“发现它”这一步就劝退了很多人。第二道门槛是技术栈错位。懂Web安全的人多但对串口调试、固件结构、MQTT这类协议不熟懂嵌入式的人往往又不关心HTTP层的鉴权逻辑。低代码平台更尴尬它本质是Web项目但把大量底层细节隐藏在可视化引擎和代码生成器后面很多开发者自己都不清楚最终生成的权限模型长什么样。你按传统Web审计的思路进去往往会扑空。第三道门槛是环境搭建。Web漏洞环境一个Docker镜像就能起来物联网环境却要凑网关、传感器、云端账号没有一套固定的练习靶场。大多数人在这一步就放弃了而恰恰是这种放弃给愿意花时间的人留下了空间。1.2 SRC评分红利与技能竞赛带来的合法练手机会门槛筛掉人之后剩下的就是红利。我观察过多个SRC平台的评分规则同一个“未授权访问”放在Web后台是普通高危放在物联网设备管理接口上常常能到严重。原因是它影响的不是一台服务器而是这批设备对应的整个租户、整个区域甚至所有在用产品的全量配置。这类漏洞在资产规模量化上非常直观报告写好评分自然就高。教育类SRC的案例思路也值得参考。教育行业资产量大、系统迭代快、安全建设滞后从某个物联网网关入口一路打通到业务系统的情况并不少见很多人习惯按Web逻辑去测忽略了网关这个入口最后只能报一个中低危信息泄露而把链路补全的人直接拿高危。另外现在不少高校技能竞赛里都有物联网安全方向的赛项官方会搭建靶场这种环境既是合法练手的好地方也能帮你积累对真实协议栈的感知。别只盯着刷题实操设备链路的经验在SRC里更容易转换成分数。1.3 什么样的人适合直接上手如果你Web方向的基础还不够建议先把HTTP、鉴权、最常见的越权和SSRF这类漏洞搞清楚再来啃这个方向。如果这些概念你已经熟练并且愿意花一下午折腾一个开源物联网平台做本地部署那这个方向完全可以上手。底层知识需求大概是能看懂网络抓包会看JS和简单后端代码知道什么是固件解包。剩下的大部分问题都可以在复现过程中现学现用。我对这个方向的定位一直是“Web安全方法论在垂直场景里的延伸”不是重新学一门学科。2. 设备侧挖掘从网关暴露面到固件配置漏洞的完整路径2.1 一张暴露面清单物联网网关里到底有哪些可测对象以常见的物联网网关为例很多基于FreeRTOS、STM32这类嵌入式平台它的暴露面远不止一个Web管理页面。我习惯把暴露面分成六类暴露面常见端口/入口典型风险Web管理接口80/443/8080认证绕过、默认口令、配置泄露本地调试服务Telnet/SSH/串口调试后门、弱凭据OTA固件升级HTTP/TFTP/FTP固件明文传输、签名缺失通信协议MQTT/CoAP/Modbus未加密、未鉴权云平台对接API443/自定义端口设备注册伪造、凭据泄露老旧服务SNMP/UPnP默认团体名、反射放大这张表不要求你每个都测但要在目标资产地图里全部标注出来。我遇到最多的情况是厂商在网关里同时开了Web管理、MQTT和SNMP安全测试却只盯着Web。SNMP的默认团体名在设备文档里一查就有很多设备出厂沿用public/private这属于典型配置性漏洞但扫到的挖掘者并不多。2.2 从端口到配置泄露一个完整的排查链路我在设备侧用的是一套固定流程可以复现。第一步是资产识别。拿到一台授权测试范围内的网关开机后接入测试网络先抓包看它主动向外连了哪些地址。很多设备一开机就向云端注册域名、端口、协议全在流量里这就是最快的资产测绘方式。连端口扫描都可以省掉一半。第二步是Web管理接口识别。登录页通常会暴露框架类型、版本号和前端静态资源路径根据这些信息判断后续测试方向。这里不要只测登录口管理后台里的配置备份、导出、恢复出厂这类功能往往更值得看。第三步是重点找“配置相关功能”。设备管理后台通常有配置备份、导出、恢复出厂之类的操作这类接口最容易出现未授权读取。曾经有一台网关导出配置的接口连登录态都不校验直接返回了整份XML。第四步是验证敏感信息。把导出的配置丢进本地编辑器搜username、password、token、secret、api_key这些词。很多厂商为了方便会把云平台凭据一起写进设备配置文件。这个习惯非常普遍基本不是个别现象。第五步是评估影响面。这个口令是全局通用还是单机随机能不能用它在云端平台查到更大范围的设备列表能不能通过它访问固件升级接口拿到新版本这一步直接决定漏洞是普通信息泄露还是高危凭据泄露也决定报告最终拿什么评级。2.3 硬编码凭据和调试后门嵌入式设备里最容易被忽略的雷在FreeRTOS/STM32这类物联网网关上我见过两种特别典型的配置问题。第一种是硬编码调试口令。厂商为了品控和维护方便会把一组admin级别的调试账号写进固件标准出厂镜像里全部相同。这就像很多人把WiFi密码写在路由器背面——运维方便但设备一旦部署到客户现场等于每天把钥匙挂在门上。测试时如果拿到一台设备的口令不要默认它是单台的多试几台同型号设备验证是不是通用。第二种是调试接口不区分内外网。不少网关在局域网侧提供串口或Telnet调试但路由规则没做隔离结果公网也能访问。如果你在做资产测绘时发现一个非标准端口返回了Welcome to console这类字符串大概率就是调试后门。这类问题在老旧设备里比例相当高。物联网设备侧的逻辑其实不复杂攻击面集中在通信层和配置面。很多做Web安全的人一听到“嵌入式”三个字就退缩实际上绝大多数网关的代码量和功能面远小于一个中型Web系统只是入口形态不同而已。3. 平台侧挖掘低代码应用里藏着的三类高危漏洞3.1 低代码平台与传统Web应用的真正区别低代码平台的本质是把后端逻辑可视化页面设计、数据模型、事件处理都通过拖拽配置完成再由代码生成器产出运行代码。你平时测传统Web逻辑写在后端代码里审计重点是对参数和权限的硬编码校验。低代码平台不一样业务逻辑常常散落在前端配置和运行时引擎里。开发者在拖拽时根本不会考虑“这个按钮对应的接口有没有做资源级校验”结果就是大量接口只做了登录校验没做对象级权限控制。vue低代码平台这些年越来越多前端组件化程度越来越高但权限边界反而更难看清。另一个核心差异是数据源连接器。平台要对接数据库、第三方API、消息队列这些连接器配置是平台提供的公共能力。任何一个表单只要允许用户输入URL或回调地址就可能变成服务端请求的入口这是SSRF的天然土壤。传统Web应用你还要找一个会主动发外部请求的参数点低代码平台把整个功能内置了。3.2 数据源绑定与SSRF一条经常被当成“功能”的漏洞我在低代码平台里看到SSRF的概率比传统Web应用高很多原因就是平台的架构把“外部请求”当成常规能力。举个例子管理员在后台创建一个数据源字段叫接口地址填URL就能拉取数据。如果这个字段没有过滤内网地址平台运行时就会向任意地址发起请求。测试思路很简单。在授权测试环境中准备一个自己能观察到的HTTP服务把数据源地址指向它如果后台产生了请求说明至少存在一次服务端回调。接下来再判断是否能访问内网IP、探活内部服务或读取云平台元数据地址。这个过程中不要直接套用现成的攻击payload先观察平台本身的请求逻辑。还有不少低代码平台会把运行日志开放给调试者一旦请求失败日志里会直接打印目标内网地址和响应内容。这意味着有些人眼里“只是日志”的功能实际已经在泄露内网拓扑。写报告时把这条链路点出来评分会明显提升。3.3 资源级越权拖拽生成应用的通病传统Web应用的越权要翻代码找接口低代码应用的越权几乎可以直接点出来。我总结了一个通用测试流程登录低权限账号在浏览器开发者工具里打开网络面板随便操作一个业务对象比如查看一条设备记录拿到对应的API路由和对象ID再把ID替换成高权限账号下创建的对象ID如果返回数据完整就是对象级越权。这类问题的根源是低代码平台的权限模型基本停留在“页面级”你能看到这个页面不代表你能操作里面所有的数据。很多平台默认所有登录用户共享同一个数据表查询接口区分度只靠前端隐藏按钮实现。前端的隐藏不是权限控制这个点一定要在报告里写清楚否则评分人员可能认为只是前端显示问题。低代码应用还有一个特点功能上线速度快。业务部门拖个页面第二天就让开发发布根本没有安全评审阶段。所以这类应用的接口往往能翻出历史版本、测试数据、废弃的调试路由这些在传统Web项目里要么被流程拦住了要么被代码审查筛掉了。3.4 vue低代码平台的前端调用层还原接口地图的高效路径现在不少低代码平台的前端基于vue这类框架。vue项目构建后的JS bundle体积大、结构稳定而且往往保留了完整的API路由表。拿到一个低代码应用后我习惯先在浏览器开发者工具里看Sources搜索几个固定关键词api、router、token、export。运气好的话能直接还原出整个后端调用图哪些接口需要鉴权、哪些接口暴露在登录页之前、哪些导出功能会把内部字段一起带出来。这比盲目扫目录高效得多。还有一种常见情况前端代码注释里留着“临时调试接口未接入权限”之类的提示顺着注释找接口验证发现确实未做任何鉴权。这种问题在低代码应用里经常出现因为代码由生成器产出开发者手动加的调试代码往往不会走正式发布流程但构建时又忘了删。前端审计的另一个价值点是token处理。很多低代码平台把token存放在localStorage或URL参数里如果前端代码里出现token拼接逻辑、第三方回调地址、iframe嵌入配置这些都可能成为后续链路攻击的跳板。4. 链式测试设备、网关、平台、低代码应用四层如何串起来4.1 为什么单独的设备漏洞很难拿高分链路漏洞却能漏洞挖掘做过一段时间后你会发现SRC评分并不完全看漏洞类型更看影响面。设备侧一个未授权接口可能只能读取单台设备的序列号和网络配置算下来也就是中危被收走但如果同一个设备能给出云平台入口和登录凭据海量业务数据全部暴露评级会立刻翻上几个台阶。这就是链路的价值前一个漏洞为后一个漏洞提供凭证或入口影响面从一台设备扩展到整个业务平台。物联网和低代码这两个词碰到一起链路几乎是天然存在的设备接入网关网关注册到云平台云平台的管理后台用低代码应用搭建数据一路从传感器流向页面。任何一环失守都会沿着数据通道传导而低代码应用恰好是这条通道上最大的暴露面。物联网网关与传感器的IP关系、设备序列号、租户信息在链路里都是现成的串联素材。4.2 两类测试路径的选型比较我在项目里常用两种路径各有适用场景测试路径适用场景前置成本产出特点端到云设备/网关入手向平台渗透手头有实体设备、固件或模拟器需要设备或固件样本容易拿到真实凭据影响面验证扎实云到端低代码平台入口入手反查设备平台公开可用但没有实体设备只需要一个普通账号覆盖资产范围广设备侧验证受限端到云路径的优势在于真实。从设备flash里提取配置、从抓包里还原云平台API这些操作拿到的凭据直接反映了厂商真实的安全水位。缺点是门槛高你可能需要花时间搞一台设备或者搭固件模拟环境。云到端路径则更适合手头只有账号的情况。你从低代码应用的前端接口地图开始找到设备管理模块通过未授权或越权接口拉取设备列表再根据设备信息反查网关配置。虽然设备侧验证有限但覆盖面广也能发现通用性问题。4.3 一条脱敏的通关链路示例我描述一条脱敏的授权测试链路厂商和型号都不公开但每个环节的思路可以完整复现。第一步测试环境里有一台物联网网关Web端口暴露了一份API文档文档附带了所有接口的明文示例。其中设备注册接口使用token认证token直接写在文档里标注用于“快速接入”。第二步用这个token调用设备列表接口返回了在线网关的序列号、型号和IP地址。到这里已经能确认接入层的权限可以看到设备地图并且物联网网关与传感器的IP对应关系也一并泄露。第三步从设备信息里找到一个低代码平台入口域名平台允许普通注册账号登录。在只使用普通注册账号的情况下发现租户列表接口返回了其他租户的基础配置影响面从单台设备扩大到了平台租户层。第四步后台数据源管理页面展示了一条数据库连接信息服务端指向内网地址请求记录里可见内网拓扑。到这里链路已经从设备信息泄露走到了内网数据访问的层面。最终报告把整条链路由设备侧的信息泄露提升为核心管理数据可访问评级直接顶格。这个例子里没有复杂漏洞没有0day全部是配置缺陷和权限缺陷的组合。发现入口只是开始真正决定分数的是沿着数据流把影响面走通。5. 报告与避坑影响面描述、授权边界和我踩过的坑5.1 报告怎么写才能撑住评分高分报告首先要有清晰的影响面三要素资产规模、数据类型、可达性。资产规模要写清楚受影响的是单台设备还是整批次产品、涉及多少租户数据类型要写明泄露的是配置信息、业务数据还是凭据可达性则要说明这个漏洞是从公网可触达还是需要处在同一网段。三条信息越具体评分人员越容易理解危害。复现步骤一定要带证据链请求包、返回包、时间戳、设备序列号、平台租户ID一个都不能少。不要只贴一张截图截图太容易被质疑是伪造或过时的。把原始请求和响应完整贴出来评分人员可以直接验证。还有一个容易被忽略的点修复建议要写具体。“对数据源URL做内网地址过滤并禁止协议白名单之外的请求”比“加强鉴权”要好得多。好的修复建议能帮助厂商快速处置也会提升报告在平台侧的专业度评分。5.2 三个我踩过的坑希望你绕开第一个坑是授权边界没确认就动了生产设备。有一次我拿到了一个设备的管理口令顺手点了恢复出厂设置结果整个传感器链路断了几小时。做设备侧测试前先跟厂商确认清楚哪些参数不能改、哪些设备不能重启、哪些接口不能做写操作。宁可少测也不要留事故记录。第二个坑是证据链不完整。早期我报过一个未授权接口只附了一张响应截图没带请求包结果被要求补充复现白白浪费了一周。之后我养成了习惯任何测试操作前先开代理记录日志所有请求和响应自动落盘。这个习惯在后续写报告时帮我节省了大量时间。第三个坑是不懂协议就误判风险。物联网里很多私有协议本身看着像漏洞比如明文传输、无鉴权订阅但可能是厂商刻意简化且影响有限的设计。遇到这类情况先读设备文档再判断是否真的构成安全问题。误报多了平台对你的报告信任度会明显下降。5.3 后续还能怎么深挖固件、协议与大模型辅助这个方向想继续深入有几条路径值得关注。第一是固件分析。通过官方下载渠道或升级包抓包拿到固件样本用binwalk这类公开工具解包重点看启动脚本、配置文件、密钥明文。固件里的信息量远大于设备Web界面很多厂商的云平台凭据和证书私钥就躺在文件系统里。第二是协议审计。MQTT、CoAP、Modbus这些协议在物联网里大量使用授权测试环境里可以验证订阅权限和通信加密情况。很多设备互相通信默认不鉴权一旦网关暴露传感器数据基本就是裸奔。第三是大模型辅助。现在可以用AI工具做审计辅助比如让大模型总结抓包日志里的异常模式、分析JS bundle里的接口调用关系、帮忙整理漏洞报告的描述模板。SSRF和XSS这类常见漏洞的检测思路也可以先用大模型跑一遍代码级初筛。注意AI辅助是提效工具不要直接让它对生产环境执行未经验证的扫描你自己要对结果负责。最后说一点个人体会。我做这个方向的顺序一般是这样先从最不值钱的设备入手拿拓扑和凭据再从最值钱的平台入口反查数据流两头同时发力等它们在中间某一点汇合时高分报告的基本素材就已经齐了。这个方向说“蓝海”不是说闭眼就能捡漏而是说只要你愿意花时间去熟悉设备协议和低代码架构竞争者天然比你少一个数量级。把我上面这些思路跑一遍你会发现物联网与低代码平台的交叉地带还有太多被忽略的资产等着被好好评估。