1. 事件背景与发现过程去年参与某三甲医院小程序安全评估时意外发现一个高危越权漏洞。该小程序承载着预约挂号、报告查询、在线问诊等核心功能日均活跃用户超2万。在常规渗透测试中通过修改请求参数成功绕过权限校验实现了越权访问其他患者的电子病历和检验报告。漏洞最初是在测试报告查询功能时发现的。正常流程下用户只能查看自己的检验报告但通过Burp Suite拦截请求后发现接口仅通过前端传递的patientID参数判断权限未在服务端做二次校验。将patientID参数值改为其他患者的ID后服务器竟然返回了完整的检验报告PDF文件。2. 漏洞原理深度分析2.1 垂直越权漏洞形成机制该漏洞属于典型的垂直越权Vertical Privilege Escalation根本原因是服务端接口缺乏有效的身份鉴权机制。具体问题体现在前端信任问题小程序前端使用wx.getStorageSync(patientID)获取当前用户ID但该值可被篡改无会话校验接口未验证请求中的session_key或token是否与patientID匹配参数依赖漏洞业务逻辑完全依赖前端传递的patientID参数// 问题代码示例前端 wx.request({ url: https://api.hospital.com/report, data: { patientID: 123456 // 可被修改为其他患者ID }, success(res) { // 获取检验报告 } })2.2 攻击链还原完整的攻击路径如下攻击者登录自己的账号使用抓包工具拦截/report接口请求修改patientID参数值为目标用户ID重放请求获取敏感数据更危险的是进一步测试发现该模式在医嘱查询、处方详情等接口同样存在形成漏洞矩阵。3. 漏洞验证与影响评估3.1 渗透测试过程记录使用以下方法验证漏洞危害性信息收集通过公开渠道获取医院员工工号规律收集常见患者ID生成规则如住院号格式批量测试import requests for id in range(100000,100100): r requests.get(fhttps://api.hospital.com/report?patientID{id}) if PDF in r.headers[Content-Type]: print(f成功获取患者{id}的报告)数据关联通过多接口信息拼接还原完整病历获取医生账号后可查看全院数据3.2 影响范围统计漏洞影响评估结果数据类型影响条数敏感等级检验报告约18万份高电子病历约9万份极高处方信息约6万条中高4. 修复方案与实施4.1 短期应急措施接口权限重构// 修复后的Java代码示例 GetMapping(/report) public ResponseEntity getReport(RequestHeader(Authorization) String token) { String currentPatient JWTUtil.parseToken(token).get(patientID); if(!currentPatient.equals(request.getParameter(patientID))){ throw new UnauthorizedException(); } // 后续业务逻辑 }WAF规则部署添加患者ID参数格式校验规则设置单IP访问频率限制4.2 长期加固方案权限体系重构引入RBAC权限模型实现属性基访问控制(ABAC)安全审计增强所有敏感操作记录完整日志建立实时异常访问监测开发流程优化增加安全代码评审环节实施自动化API安全测试5. 经验总结与防护建议5.1 典型错误模式前端信任反模式错误认为前端参数不可篡改正确所有权限判断应在服务端完成会话管理缺陷错误仅依赖前端存储的用户标识正确使用签名token并校验有效期5.2 小程序安全开发清单必做项所有接口实施双重鉴权token业务参数校验敏感数据接口增加二次认证短信验证码等实施最小权限原则推荐项定期进行安全渗透测试关键业务接口添加水印追踪建立敏感操作审批流程5.3 监控指标建议建议部署以下监控指标同一token访问不同患者ID的频率异常时间段的数据访问行为高频次报告下载操作这次事件给我们的核心启示是医疗类小程序必须采用零信任安全架构所有请求都应视为不可信在服务端进行完整的权限校验。同时要建立多层防御体系确保单点漏洞不会导致系统性风险。 
长河君 · 2026/10/31 11:21:45 · 阅读 1.2k 医疗小程序垂直越权漏洞分析与防护实践
1. 事件背景与发现过程去年参与某三甲医院小程序安全评估时意外发现一个高危越权漏洞。该小程序承载着预约挂号、报告查询、在线问诊等核心功能日均活跃用户超2万。在常规渗透测试中通过修改请求参数成功绕过权限校验实现了越权访问其他患者的电子病历和检验报告。漏洞最初是在测试报告查询功能时发现的。正常流程下用户只能查看自己的检验报告但通过Burp Suite拦截请求后发现接口仅通过前端传递的patientID参数判断权限未在服务端做二次校验。将patientID参数值改为其他患者的ID后服务器竟然返回了完整的检验报告PDF文件。2. 漏洞原理深度分析2.1 垂直越权漏洞形成机制该漏洞属于典型的垂直越权Vertical Privilege Escalation根本原因是服务端接口缺乏有效的身份鉴权机制。具体问题体现在前端信任问题小程序前端使用wx.getStorageSync(patientID)获取当前用户ID但该值可被篡改无会话校验接口未验证请求中的session_key或token是否与patientID匹配参数依赖漏洞业务逻辑完全依赖前端传递的patientID参数// 问题代码示例前端 wx.request({ url: https://api.hospital.com/report, data: { patientID: 123456 // 可被修改为其他患者ID }, success(res) { // 获取检验报告 } })2.2 攻击链还原完整的攻击路径如下攻击者登录自己的账号使用抓包工具拦截/report接口请求修改patientID参数值为目标用户ID重放请求获取敏感数据更危险的是进一步测试发现该模式在医嘱查询、处方详情等接口同样存在形成漏洞矩阵。3. 漏洞验证与影响评估3.1 渗透测试过程记录使用以下方法验证漏洞危害性信息收集通过公开渠道获取医院员工工号规律收集常见患者ID生成规则如住院号格式批量测试import requests for id in range(100000,100100): r requests.get(fhttps://api.hospital.com/report?patientID{id}) if PDF in r.headers[Content-Type]: print(f成功获取患者{id}的报告)数据关联通过多接口信息拼接还原完整病历获取医生账号后可查看全院数据3.2 影响范围统计漏洞影响评估结果数据类型影响条数敏感等级检验报告约18万份高电子病历约9万份极高处方信息约6万条中高4. 修复方案与实施4.1 短期应急措施接口权限重构// 修复后的Java代码示例 GetMapping(/report) public ResponseEntity getReport(RequestHeader(Authorization) String token) { String currentPatient JWTUtil.parseToken(token).get(patientID); if(!currentPatient.equals(request.getParameter(patientID))){ throw new UnauthorizedException(); } // 后续业务逻辑 }WAF规则部署添加患者ID参数格式校验规则设置单IP访问频率限制4.2 长期加固方案权限体系重构引入RBAC权限模型实现属性基访问控制(ABAC)安全审计增强所有敏感操作记录完整日志建立实时异常访问监测开发流程优化增加安全代码评审环节实施自动化API安全测试5. 经验总结与防护建议5.1 典型错误模式前端信任反模式错误认为前端参数不可篡改正确所有权限判断应在服务端完成会话管理缺陷错误仅依赖前端存储的用户标识正确使用签名token并校验有效期5.2 小程序安全开发清单必做项所有接口实施双重鉴权token业务参数校验敏感数据接口增加二次认证短信验证码等实施最小权限原则推荐项定期进行安全渗透测试关键业务接口添加水印追踪建立敏感操作审批流程5.3 监控指标建议建议部署以下监控指标同一token访问不同患者ID的频率异常时间段的数据访问行为高频次报告下载操作这次事件给我们的核心启示是医疗类小程序必须采用零信任安全架构所有请求都应视为不可信在服务端进行完整的权限校验。同时要建立多层防御体系确保单点漏洞不会导致系统性风险。