企业官网建设流程全解析

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系统，凡是功能模块复杂、权限层次多、数据跨度大的企业应用，比如财务系统、采购系统、项目管理系统，都可以借鉴同一套方法论。框架是一样的，变的只是具体的功能和数据模型。如果你正打算深入某个企业应用做授权测试，不妨先花点时间把这套思路过一遍，再开始动手。我打赌你能少走不少弯路。