1. 为什么HR系统成了组合漏洞的靶子搞了这么多年安全测试我越来越觉得HR系统是块硬骨头也是块肥肉。你可能觉得它不就是管管考勤、工资条、请假审批嘛能有什么含金量这么想的同行大概率是还没真正啃过这类系统。实际上HR系统恰好是组合漏洞挖掘最理想的目标之一因为它天然具备复杂权限模型、大量敏感数据流和跨系统协作逻辑这三样组合在一起几乎是为漏洞链准备的温床。先说权限模型。HR系统的角色划分往往极其细致常见的有员工自助账号、部门HR专员、HR经理、HR总监、薪酬专员、校招面试官、系统管理员等等而且不同公司对角色边界的定义千差万别。有些系统干脆把权限控制逻辑写死在各个功能模块里前端菜单隐藏一下就算隔离了后端接口完全不校验。这种情况下只要有一个接口的越权没堵住纵向横向都能打穿。再说数据价值。HR系统里的数据敏感程度不亚于核心业务库身份证号、银行卡号、社保公积金基数、工资条、绩效评分、家庭住址、紧急联系人甚至体检报告和背景调查记录。这些数据如果用普通业务系统的眼光去审视很多测试人员压根意识不到它们的价值密度有多高。攻击者一旦拿到这些数据做精准社工、身份伪造、金融欺诈都绰绰有余。最后说跨系统联动。现在稍微大点的公司HR系统很少单独存在基本都要对接企业号、OA审批流、单点登录中心、财务系统、考勤机设备平台。每一次对接都意味着信任传递而信任传递过程中最容易出现逻辑断层。比如一个系统的会话令牌能不能直接请求另一个系统的接口另一个系统对令牌的解析方式是否严格这些都是组合漏洞的高发区。所以我说HR系统是组合漏洞挖掘的最佳训练场地不是因为它的代码写得烂而是因为它的业务逻辑足够复杂复杂就意味着状态多、关联多、意外多。单点漏洞可能在半天里就挖完了但组合漏洞能让你在一套系统里反复深耕几周甚至几个月每一次把看似无关的功能点串联起来的时候那种感觉就像在解一道精心设计的谜题非常上头。1.1 单点漏洞与组合漏洞的分水岭很多刚入行的朋友喜欢盯着SQL注入、文件上传、命令执行这些东西不放觉得挖到个RCE才叫技术。但实际在真实业务系统里单点漏洞的挖掘随机性很强你遇到的系统可能整体安全水平并不低常规漏洞基本都补得差不多了。这个时候组合漏洞的威力就体现出来了——它不依赖某个高危点单独存在而是把多个中低危缺陷通过业务逻辑串联起来最终形成一个严重影响链条。举个例子文件上传点可以任意上传文件但上传目录是隔离的、不允许脚本执行这个单点问题顶多算个中危。但如果配合一个信息泄露接口能读取服务器配置或者目录结构再配合一个弱随机数生成的临时文件名那上传文件有可能被定位到精确URL并直接访问到甚至通过某种解析配置拿下一定的执行能力。这就是组合的威力。组合漏洞的核心价值在于它能绕过单点修复。你修掉一个上传校验如果组合链里的另一个信息泄露点没修攻击者仍然可以利用泄露的路径把上传的文件以某种缓存或静态资源的方式访问出来。我在实际测试中见过太多团队逐个修漏洞修得很认真但因为没有从链路视角去看问题修完这个反而暴露出那个按下葫芦浮起瓢。所以组合漏洞挖掘和单点漏洞挖掘的分水岭不在于某个漏洞的等级高低而在于你是否建立了系统性的链路思维。没有链路思维你看到的都是孤岛有了链路思维孤岛之间就出现了桥。1.2 组合漏洞挖掘需要什么样的基本功想挖好组合漏洞光会跑扫描器是不够的。你得不跳步地把下面这些基本功打扎实才能顺利往下走。第一HTTP协议理解和接口调试能力。组合漏洞里每一步动作几乎都是通过构造特定HTTP请求完成的你得能熟练分析请求头、响应头、Cookie机制、重定向逻辑、状态码含义能判断一次请求带不带鉴权标识、鉴权标识绑不绑定具体会话和权限。Burp Suite的Repeater和Decoder是天天要用的东西别不好意思承认做这一行没有谁不用顺手的工具。第二前端代码分析能力。现在大量权限判断在前端完成按钮隐藏、菜单过滤、路由守卫前端JS文件里的信息量极大。很多隐藏接口、测试接口、内部注释都暴露在JS代码里。把几个关键JS文件翻完往往比盲目目录扫描高效得多。而且前端代码能直接反映业务模块之间的关联和跳转逻辑对理解组合链路帮助很大。第三业务逻辑理解能力。你要能看懂一个业务流程画出来是什么样子申请、审批、抄送、会签、驳回、撤回这些状态流转之间存在哪些分支和前置条件。状态里的任何一个分支没有校验服务端状态来源就可能在某个环节进行非预期的状态跳跃。第四脚本编写能力。不需要多精通但至少能用脚本快速发批量请求、处理响应、比对数据变化。很多越权和遍历类漏洞手工会做到怀疑人生脚本可以帮你几分钟内确认影响范围。这些基本功每一样都不是花架子缺一块组合链就可能卡在某一环上。我在带人的时候常说组合漏洞挖不出来不是目标系统太安全而是你和系统之间隔着一层窗户纸没捅破。2. 选定靶标信息收集决定了你能走多远组合漏洞挖掘有一个特点就是前期的信息收集质量直接决定了后面的道路宽度。你挖单点漏洞时可能只需要找到一个入口就行但挖组合漏洞时你需要对系统的功能模块、架构边界、信任域划分、第三方组件、历史遗留接口都有比较全面的了解才能找到串联不同缺陷的桥梁。所以这一部分我会很细致地讲一讲我当时是怎么做信息收集的。我在拿到授权之后一般不会立刻开扫描器乱扫一通那只会制造大量噪音掩盖真正有价值的线索。我倾向于先用2到3天的时间做被动信息收集和点到为止的主动探测把所有线索整理成一张关系图。这张图不需要画得很精致但一定要把系统部署架构、登录接入方式、关键进出口子域名/路径、核心业务模块划分、企业号或办公平台对接情况都标注清楚。HR系统往往挂载在办公网的核心区域和其他系统共用一套单点登录体系这是很重要的一个前提。我在信息收集阶段会重点梳理单点登录体系的接入方式是CAS、OAuth2还是自定义票据协议各个子系统之间的票据校验是集中式还是分散式有没有从某个子系统的登录态直接替换成另一个系统登录态的可能。这些细节在后续利用阶段经常是突破口。另外不可忽视的是信息泄露类线索。GitHub上有没有员工的代码仓库、内部的说明文档、API文档、测试用例网上能直接搜到的公开信息整理一遍往往有意想不到的收获。有很多团队习惯把接口文档传到在线文档访问权限设置成只要知道链接就能看而搜索引擎或网盘搜索引擎经常能收录这类链接。我自己就遇到过通过公开搜索找到内部API字典、测试桶地址和第三方服务密钥的情况这些看起来没什么直接利用价值的信息在拼组合链时可能正好是缺的那一块拼图。前端资产也是信息收集的富矿。HR系统的招聘门户、校招官网、员工自助平台常会嵌入很多第三方服务比如简历解析服务、身份认证服务、在线测评服务、电子签约服务。每引入一个第三方服务就多了一个信任传递的节点。我会特别留意这些服务是不是同域部署、接口协议是否统一、第三方回调地址是否可以篡改因为在组合漏洞里第三方服务回调参数污染是屡试不爽的手法。2.1 信息收集阶段的关键产出物信息收集做完我不急着往下走一定要先把产出物整理清楚。至少要有下面这样几份东西。第一份资产与账号权限清单。哪个地址对应什么系统该系统需要什么账号角色才能访问我手上有哪些测试账号、什么权限级别没有哪些。HR系统里角色边界复杂不同子公司、不同部门可能数据隔离所以清单越细越好。第二份鉴权机制说明。包括登录方式、令牌头名称、时效策略、刷新机制、单点登录绑定关系。我习惯把每个接口的鉴权方式记录下来因为越权和鉴权问题往往隐藏在这些细节差异里。第三份功能模块与业务流程图。把系统中主要功能模块和子模块之间的调用关系标注清楚尤其是离职、转正、调薪、审批等跨角色流程这些流程通常横跨多个权限域是最容易出现逻辑错乱的地方。第四份可疑点清单。把所有在信息收集阶段发现的反常现象记录下来比如某个接口的返回字段比其他接口多、某个目录路径后缀奇怪、某份JS里有调试后门相关的代码、某个后台管理地址没有出现在任何菜单里。这些可疑点不需要在信息收集阶段马上验证但它们是你后续组合漏洞挖掘的候选入口。当然我也遇到过信息收集阶段什么都没发现的情况看起来一切都很正常。这个时候不用着急把系统用起来像我这样用测试账号从头到尾把主要流程走一遍留意每个操作对应的后台请求和参数变化很多问题在正常使用的过程中会自己露出马脚。2.2 容易被忽略的HR系统特有资产HR系统相比其他系统有一些特有的资产类型这些地方往往在常规信息收集里容易被忽略但恰恰是组合漏洞的高发区。我单独拿出来讲一下。第一简历库和简历解析服务。招聘模块通常会上传大量PDF、Word简历然后调用简历解析服务提取候选人信息。上传功能本身可能限制扩展名和大小但解析服务在后台如何存储和返回结果却经常存在二次漏洞的隐患。比如简历文件名、简历内容里某个字段的值会被直接拼进后续请求或页面输出中形成存储型问题。简历里包含的超链接和自定义字段也可能被解析器当作富文本渲染时触发意料之外的行为。第二批量导入和导出功能。HR系统动辄要支持Excel批量的薪资导入、组织架构导入、员工花名册导出。这些功能背后往往有专门的处理模块可能在处理异常数据时输出详细报错、在导出模板时包含隐藏字段、在权限校验时只校验了导出入口而没校验具体数据范围。批量导入导出是数据越权和信息泄露的重灾区而且因为涉及文件处理经常和上传、解析、下载这类功能组合在一起形成复杂链路。第三薪酬和绩效模块。这个模块默认是全系统权限级别最高的模块之一但有些系统只在入口处做了控制内部各个子页面和接口的权限判断却非常混乱。我见过一个系统薪酬模块的查询接口和员工自助的工资条接口共用同一个后端服务只是传入的参数不一样结果自助接口就能遍历其他人的薪资数据。这就是典型的前端菜单隔离、后端服务共用导致的逻辑漏洞。第四审批流和消息通知。HR系统的审批流会和邮件、短信、企业号消息打通通知消息里一般会带详情链接或者动态令牌。如果令牌生成规则简单、有效期过长、链接未绑定具体接收人就可能被伪造或重放。审批类接口需要特别关注加签、转办、撤回这些非主流程操作因为开发最容易在这些分支操作上忘记校验操作人身份和单据归属。2.3 网络搜索在信息收集中的分量再看一下网络搜索这个信息收集手段的价值很多人低估了它。在网络空间搜索引擎、代码搜索平台、在线文档平台、网盘搜索引擎这些地方你可以用HR系统的常见特征做关键字画像比如系统登录页的标题、版权信息、JS文件名特征、错误页面的报错特征等。只要找到一条暴露的代码片段或者配置模板往往能反查出一批同源系统。我在一次授权项目中就是通过搜索某HR厂商默认Logo文件名找到了目标公司在测试环境部署的一套完整系统而测试环境竟然使用了默认口令和公开的教程初始化配置。这套测试环境虽然没有正式域名也没有挂载到单点登录体系里但它的数据集是生产的全量备份数据价值非常高。这个发现后面直接改变了整个项目的测试走向。搜索还有一个用途是找历史漏洞公开记录。目标HR系统如果使用了某个开源框架、某个版本号的第三方组件你可以搜索该组件历史上公开过的漏洞详情、利用方式和受影响条件。组合漏洞挖掘经常是已知漏洞利用链的二次组合——不一定非要从零发现新的漏洞点把几个已知的缺陷组合到一个新场景里一样能达到很严重的效果。不过网络搜索收集信息必须控制深度和边界所有动作必须限定在授权范围内不要因为搜索太顺利就放松警惕不该碰的数据坚决不碰这是底线问题。3. 组合链路的搭建普通越权如何变成完整攻击链当我完成了前期的信息收集把所有可疑点装进了脑子里之后下一步就是真正进入组合漏洞挖掘的核心阶段把散落的低危中危线索串成一条完整的攻击链。这个过程没有什么固定的脚本可以套但思考路径是有迹可循的下面我用一个我自己做过的HR系统授权测试项目来做一次复盘。说明一下为了安全起见下面的系统名称、接口路径、参数名都是改动过的但漏洞形态和组合逻辑完全保留了真实情况。这个项目是在充分授权、明确测试范围边界和操作红线的条件下进行的所有验证步骤都以能证明影响为限没有做任何多余的数据抓取和破坏性行为。先交代一下背景。目标系统是某公司自研的HR管理平台接入了公司统一单点登录体系。我拿到的是一个普通员工自助账号和一个HR助理账号没有管理端权限。目标非常简单验证普通员工是否能越权读取他人敏感信息、是否能获得超出自身权限级别的系统能力。一开始我用普通员工账号进行了一轮相当细致的功能遍历把能点的按钮、能开的页面全部记录了下来。这个过程比较枯燥但非常有价值因为每一个功能点相关的接口请求和参数变化都是后面组合分析的基础素材。我在遍历过程中发现了下面几个值得注意的可疑点第一员工自助的“个人信息修改”功能提交修改时会请求一个更新接口接口里面带有员工编号字段。我尝试把员工编号改成其他同事的编号接口返回成功。但当我重新查询时发现数据其实没有变这个接口大约是做了后台二次校验的。这一条单独看没有什么价值但它给了我一个信号——这个系统里可能存在员工编号作为操作主键的接口设计模式。第二HR助理账号在“员工花名册”页面可以查看在职员工的基础信息包括姓名、部门、职位、入职日期等但不含薪酬和身份证号。这个页面对应的请求中同样出现了员工编号字段。我尝试修改员工编号遍历其他员工发现可以返回正常数据这说明列表接口与详情接口之间可能没有做严格的数据范围校验。这已经是一个典型越权漏洞了不算组合单点已经可以定为中危。第三在某个前端JS文件里我看到了一个隐藏的管理端接口路径路径名中包含“salary”和“export”两个关键词。用普通HR助理账号直接访问这个接口返回了401未经授权说明该接口还有独立的鉴权机制。到这一步三条线索看起来彼此孤立一个没有实际效果的修改接口、一个能越权读取的花名册接口、一个401的隐藏导出接口。如果在这里停下那这轮测试充其量就是发现了一个普通越权漏洞交差完事。但我决定顺着花名册越权这条线继续往下挖看能不能利用已经拿到的数据来撬动后面那个401接口。3.1 从越权读取到身份伪造的第一跳拿下花名册越权接口之后我开始大量遍历返回数据重点关注几个以前没注意过的字段直属领导、HRBP、入职登记表附件链接、内部邮箱、手机号等信息。在当时那个系统中我发现了一条重要线索每个员工的入职登记表附件链接中都带有一个临时访问令牌。这个令牌在正常情况下应该是有时间限制和权限绑定的但我用越权接口拉出来的令牌尝试直接访问附件时居然成功了而且有效期长达整整三天三天内可以反复下载。这就完成了第一跳一个普通HR助理账号通过越权接口批量拉取所有员工的附件链接和临时令牌再使用令牌下载附件。附件是入职登记表里面包含了员工的身份证复印件、银行卡复印件、紧急联系人信息、住址信息等极高敏感度的数据。单点看来还是越权问题但影响面已经从基础信息扩大到了身份证、银行卡这种支付级别的高敏感数据漏洞等级已经可以往上走了。到这一步整个链路还停留在读取层面。我给自己定的目标不只是验证读取效果我更想看看能不能沿着这条权限提升路径进一步摸到那个401的薪酬导出接口。3.2 从泄露令牌到跨接口身份切换的第二跳拿到大量临时令牌后我仔细分析了令牌的格式和生成规律发现它是明文Base64编码的解码后内容是员工编号加一串时间戳的拼接签名算法非常简单。这就意味着我可以伪造任意员工编号、任意签发时间的有效令牌。到这里前面那个401接口就成了我下一个目标。我在我的技术笔记中记下这样一句话当你手里有了全公司的身份伪造能力任何一个业务隔离的接口都可能是突破口。我把伪造出来的管理员工号令牌放进那个薪酬导出接口请求里结果直接通过了鉴权。返回的数据包是一个很大的Excel导出文件包含薪酬明细、绩效等级、社保基数等数据。这一步整条攻击链就从越权读取升级成了写好伪造任意身份的高权限数据导出影响范围覆盖全员。这个链路的形成思路是花名册越权 → 获得敏感附件链接和令牌 → 分析令牌规律 → 伪造任意身份 → 绕过薪酬导出接口鉴权。每一步单独拿出来你可能最多定个中危有些步骤甚至只能算低危信息泄露。但把它们串联起来整体风险已经到了非常严重的地步。这就是组合漏洞最典型的魅力也是防御者最容易忽视的死角。3.3 组合链路的通用拼装方法复盘完上面那条链路我把组合链路搭建时的通用拼装方法做了个总结。不能说放之四海而皆准但在我自己的实践里非常有效。第一从数据流视角找信任传递节点。明确系统里哪些数据是可信的、哪些信号被用来做权限判断。比如用户身份有时候靠Cookie/Session有时候靠请求头里的某个自定义字段有时候靠URL里携带的ID。你把这些信任节点找出来交叉组合时就有基准了。第二优先寻找“可伪造的信任凭证”和“未隔离的管理入口”这两类目标的交集。可伪造的信任凭证能让你在身份维度获得更大的自由度未隔离的管理入口能让你把自由度转化成实际权限。这两者的交集就是组合漏洞的高产区。第三利用越权读取到的信息去做下一步的密码喷洒、口令复用或令牌绕过。越权读取不仅仅是用来扒数据它还是一个信息饲料的供给站。攻击者往往从一次不起眼的越权里拿到一批用户名、手机号、内部ID然后把这些信息当跳板去撞其他系统的接口或尝试登录后台形成更深一层的突破。第四不要忽略低频、非主流程的功能点。低频功能点像离职办理、转正审批、证书作废、社保减员、劳动合同到期提醒往往开发量小、测试覆盖少、权限判断规则粗糙。这些功能点经常就是组合链里最合适的那块落脚的石头。4. 常见问题与排查技巧记录后面我陆续做了不少类似系统的测试也带过团队一起挖过HR系统踩过的坑、绕过的弯路都不少。这里把一些共性的问题和排查技巧整理出来给后来的人一份参考。不敢说全部正确但在多数场景下确实是这么回事。最先要说的就是组合链突然断掉的问题。你辛辛苦苦串了好几步在最后一步发现目标接口做了额外的参数校验或者IP白名单限制整条链废掉。经验是避免一条道走到黑。你在组合链条的时候就要学会并行推进同时保留两三个可能的跳板路径A路径不通立刻换B路径不要在一个卡点上死磕太久。第二个常踩的坑是响应差异被忽略。很多越权接口你修改参数后返回的是同一个模板但某些字段会有细微差异比如时间戳不同、某个状态码不同、某人名字被打码了。这些细微差异往往说明了校验逻辑的存在或缺失是判断越权成功与否的重要依据。不要只看HTTP状态码是不是200要实实在在分析响应体里的每一个字段。第三个问题是工具依赖过重导致误判。扫描器和工具脚本跑出来的结果如果不经过手工确认很容易出现把登录页当漏洞、把静态资源响应当信息泄露这类情况。尤其是HR系统有大量静态页面和通用组件工具报告里充满噪音。经验是工具只做初步过滤关键节点必须用Burp Suite手工走一遍亲眼看请求和响应的全过程才下结论。手工的过程还能顺便发现参数变化帮助丰富组合链这是工具替代不了的。第四个容易被忽略的点是请求顺序和状态依赖。组合漏洞经常要求以特定顺序执行多个请求比如先触发某个状态更新再访问另一个接口才能生效。有些接口设计依赖前置请求在服务端产生的状态如果你在Repeater里直接单独发包就可能显示失败。这不是校验没过而是时序不对。处理方式是完整录制整个业务流程的请求序列逐条回放对比找出真正的依赖关系。再说一个经验性的技巧就是善用响应时间判断逻辑分支。有些后端在条件分支里执行的操作不同导致响应时间的差异很明显。比如某个接口在参数有效时执行了完整的数据库查询参数无效时直接返回报错相差几百毫秒。这种时间差异可以帮你判断接口内部的逻辑走向对于黑盒情况下推断业务逻辑特别有帮助。遇到拿不准的漏洞组合我建议用草稿纸把链路图画出来连箭头标注每一步依赖的信息、借用到的凭证、影响的资产和达成的权限。画图的过程会强迫你把逻辑理顺很多时候画着画着你就会发现链路里的逻辑漏洞或者冗余环节进而优化出更简练的攻击路径。正式的测试报告里也可以附上这样的链路图沟通效率会高很多。4.1 从攻击链反推的加固建议测试做完不能一走了之还要把防御思路写清楚。组合漏洞最有效的修复方式就是按攻击链的每一环去做拆解和加固。只修最后一环或只修第一环都不能真正阻断整条链。这里我给出我平时最常用的加固建议层次。第一层修复权限校验缺失。所有涉及员工编号、部门编号、单据ID之类的业务参数必须在后端做归属校验确认当前操作者对所操作对象有权限。前端菜单隐藏和按钮disable只是体验上的处理绝对安全边界后端校验才是核心。第二层修复令牌和凭证管控缺陷。临时附件的访问令牌要短时效、绑定IP或设备、绑定具体员工编号不能使用可预测的编码规则。所有令牌的生成算法要有足够的随机性和密钥保护服务端每次都要验证签名、过期时间、签发者身份同时建立吊销机制。第三层隔离高敏感接口的信任域。薪酬、导出、批量操作这类高权限接口不能只依赖单一身份凭证建议叠加二次认证、独立审计和操作审批流程。即便身份凭证被伪造高敏感接口仍然需要独立的校验因子才能放行。第四层日志和告警的完善。对异常访问模式建立告警规则比如单个账号批量拉取附件或导出数据、非工作时间大量下载、令牌重复使用等场景。组合漏洞攻击链通常伴随着大量试探性请求如果日志系统能识别到规律并产生告警即使没拦住前置步骤也有机会在攻击者拿到最终结果前触发切断。防御是一个系统的问题不是修掉一个函数就能高枕无忧的。每次攻击链复盘都应把每一跳的加固动作写清楚再评估一下哪一环修复成本最低、效果最好。有时一环的加固就能打断整条链这时优先做它比全面铺开更高效。5. 写在最后的一点个人体会做HR系统组合漏洞挖掘这个专项让我对安全测试的理解上了一个台阶。回头看组合漏洞挖掘的成就感不在于你发现了一个多么新颖的0Day而在于你能把一个系统的业务逻辑逆向得足够深、代入感足够真实把自己放到一个普通员工或者低权限HR的视角去思考如果我是坏人我会怎么利用这套系统里的每个功能。想通了这个问题组合链自然就浮现出来了。我在带新人做这类项目的时候最常听他们问的一句话是“接下来扫哪里”。我通常反问他们“你希望扫出来什么”。这个问题的区别其实就是经验和思考深度之间的差异。扫描器能告诉你哪里有洞但只有你的脑子能告诉你这些洞如何被串联起来。工具是帮你省时间的不是帮你思考的这一点在组合漏洞挖掘上体现得尤为彻底。还有一点想强调随便什么样的测试一定要把授权边界和操作规范放在最高优先级。没有授权、没有明确测试范围、没有事先约定操作红线的测试不管你出发点是什么都不会有任何正面意义。真正有价值的安全能力建立在合规、专业和克制的基础上这也是一个安全从业者最基本的职业素养。这套组合漏洞挖掘的思路不只适用于HR系统凡是功能模块复杂、权限层次多、数据跨度大的企业应用比如财务系统、采购系统、项目管理系统都可以借鉴同一套方法论。框架是一样的变的只是具体的功能和数据模型。如果你正打算深入某个企业应用做授权测试不妨先花点时间把这套思路过一遍再开始动手。我打赌你能少走不少弯路。