文章总结： 京东实践了白盒静态分析引擎结合大语言模型自动化检测操作类越权漏洞方案通过识别增删改操作方法构建用户身份数据流图并利用LLM辅助识别鉴权特征及是否符合预期落地效果显示AI识别无风险场景准确率90%有风险场景70%建议应用于SDL安全评估并规划黑白盒工具关联和自动修复
综合评分： 86
文章分类： 漏洞分析,代码审计,AI安全,应用安全,安全建设

白盒+LLM：京东操作类越权自动化检测实践

不止Security

2025年7月30日 21:41
贵州

编者荐语：

越权自动化检测实践，市场对安全人员的素质要求正在不断提高

以下文章来源于京东安全应急响应中心
，作者京东安全

京东安全应急响应中心
.

京东安全应急响应中心（JSRC）官方

白盒+LLM：京东操作类越权自动化检测实践

一

前言

越权漏洞是各个厂商做漏洞治理难以绕过的话题，针对权限类漏洞风险，业界实践方案主要分为两类，一是加固类方案，如xxx票据、token化等，此类方案涉及业务改造成本相对高，在具备安全属性的（如金融）业务上有落地实践，其他业务场景通用性稍差。二是检修类方案，主流是通过黑白盒工具，扫代码或打POC发现越权风险，但也存在白盒误报高、黑盒不敢打等问题。结合外部实践和京东漏洞治理经验，我们最终选择的是LLM+白盒的检修式方案，本文重点介绍京东在操作类越权场景的落地实践方案。

京东白盒简介

LLM大家都不陌生，这里介绍下京东白盒。京东白盒静态分析引擎是内部自研，不过技术原理上大家都基本类似：将源代码通过词法/语法分析转换为AST，通过在AST节点不断travel（很多叫walk，不过还是觉得travel比较有意境）生成不同的图，比如函数调用图(S)CG，控制流图CFG，数据流图DFG，或者合在一起的代码属性图CPG，再通过图搜索算法找出source点（一般为程序对外API的入口点）到检测规则定义的sink点（与漏洞类型有关，比如SQL注入关注DAO层方法，SSRF关注HTTP请求方法等）之间的传播链路，通过判断外部可控参数是否可达sink点及链路中是否存在清洗函数来综合判断是否存在漏洞。因为语义分析引擎是自研，所以在一些参数追踪、打标、数据流构建上会更加灵活，为检出越权奠定了前置基础。

二

漏洞分析

如下表所示，区别于常见的通用漏洞，逻辑类漏洞在检测特征上依赖业务场景、登录方式等，特征多样且相对灵活。而传统的黑白盒漏洞检测方案，适用于检测固定的pattern和behavior漏洞类型，直接套用通用漏洞的检测方案容易出现误报高的问题。

三

难点分析

3.1

如何判断API是否需要鉴权

京东业务属性就决定天然存在大量公开接口：如查看商品、快递小哥手机号、医生手机号等，确定该接口是否需要鉴权是检测类方案首要回答的问题。

• 区分查询和操作（增/删/改）类接口：上述公开信息的误报主要集中在查询类接口中，区分好数据操作类型能有效缓解误报，这也是本文重点针对操作类越权的主要原因。治理查询类越权，我们主要通过黑盒+LLM技术方案，核心点是解决黑盒不敢打生产、API资产建设、敏感数据和公开数据识别、测试账号维护等问题，本方案不再赘述。
• 操作类接口是否都要鉴权？答案是“需要”。实际运营中也发现有少数操作场景不需要鉴权，比如活动报名、评论等，占比较低可根据实际情况采取忽略或加白等措施。

3.2

如何判断API是否存在鉴权

基于不同的业务场景和技术选型，进行接口鉴权形式多样，为避免误报，检测器需要对不同的鉴权方式进行适配。常见的鉴权方式举例：

1. 函数/代码逻辑鉴权：服务端业务层校验主体标识与资源标识的从属关系。

String pin = LoginContext.getPin(); String resourceId = request.getParameter("resourceId");if (!checkPermission(pin, resourceId)){  throw new Exception("当前用户无权限访问"）；}return queryResourceInfo(resourceId);

2.注解鉴权：服务端通过注解+代理方法校验主体标识与资源标识的从属关系。

@AuthValidate(name = "deptList",type = AuthType.ID,uri = AuthUri.dept)@RequestMapping(value = "/edit.do", method = RequestMethod.POST)public Response edit(@RequestParam("wbIds") String wbIdsStr,String[] deptList) {  ......}

3.SQL鉴权：服务端数据访问层同时对资源和主体进行限制访问。

select * from resource where resource_id = #{resourceld} and pin = #{pin}

4.签名校验：服务端对主体标识和资源标识进行hash计算，将hash值返回给用户。用户需要同时提交资源标识、主体标识以及hash值，服务端验证通过后才能进行后续的资源访问操作。（本质是网络防篡改的防御手段，本文不做分析）

5.管理员/白名单鉴权：服务端在接口层面判断主体标识是否在配置对白名单用户列表中，只有白名单用户才能进行后续的资源访问操作。

3.3

如何判断API鉴权实现是否符合预期

如果仅判断是否有鉴权函数，可能会导致漏报，以下为常见的鉴权绕过漏洞场景，看似有鉴权，实则没有作用或部分起作用。

1.多资源参数操作，只对某个参数做校验。

&nbsp;//权限控制Result<Boolean> deptRes = permissionServiceProxy.hasDept(operateUser, pickupOrderDto.getDeptNo());if&nbsp;(!deptRes.getData()) {&nbsp; &nbsp;&nbsp;return&nbsp;Result.exceptionResult("无操作权限");}Long&nbsp;deptId = pickupOrderDto.getDeptId();if&nbsp;(null&nbsp;== deptId) {&nbsp; &nbsp;&nbsp;return&nbsp;Result.validateFailedResult("事业部ID为空");}// 实际操作使用 deptIdApiResponse apiResponse = sellerOrientedService.saveRetakeGoods(deptId);

2.调用统一JSF进行权限校验，但针对鉴权接口返回值判断不严谨。

// 错误封装：未判断 resp.getData()public&nbsp;Result&nbsp;hasDeptById(String&nbsp;pin,&nbsp;String&nbsp;deptId) {&nbsp; &nbsp;&nbsp;Response<Boolean> resp = permissionService.hasDeptById(...);&nbsp; &nbsp;&nbsp;if&nbsp;(resp.getCode() ==&nbsp;200) {&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;return&nbsp;Result.successResult(true);&nbsp;// // 不论 data 是 true 还是 false，统一返回 true&nbsp; &nbsp; }&nbsp; &nbsp;&nbsp;return&nbsp;Result.successResult(false);}// 调用方：使用了被污染的返回结果Result<Boolean> res = proxy.hasDeptById(pin, deptId);if&nbsp;(res.getData()) {&nbsp; &nbsp;&nbsp;// 实际用户可能无权限，data 可能是 false，但判断通过，造成权限绕过}

四

京东白盒+LLM方案

4.1

识别操作方法

安全的本质是风险管理，风险的载体是资产。我们把域名、API、IP、镜像、代码仓库等资产归为基础资产，基于要治理的漏洞风险，划定不同的风险资产范围。在操作类越权场景中，公网活跃（正在使用的）、涉及到增/删/改方法的代码API，属于高优治理的风险资产，需要鉴权。

基于此，一是需要识别代码API是否活跃、是否被公网访问（包括直出和网关间接转发），这块属于资产关联范畴，理清楚基础资产关联关系是黑白盒关联提升主动检测能力和精细化运营的关键，细节不再此文中赘述。二是识别增/删/改。增/删/改是数据操作行为（如图1红色划线部分），关键是识别API执行过程中的数据操作方法，不同的场景有不同的处理策略：

• Mybatis/MybatisPlus场景：如图1所示，白盒静态分析引擎通过将DAO层与mapping XML文件中的SQL id关联，实现源码中java代码与xml配置文件内SQL的参数数据流不中断，通过XML中/select/insert/update/delete准确定位API数据操作类型。当然，这一步的JAVA与XML关联，除了可以精准识别数据操作方法外，对识别清洗函数也是关键点。

• 其他ORM组件等场景：调用三方组件或业务原生java直接执行SQL操作，比如jdbcTemplate、springTemplate等，这里可通过SQL注入规则识别，规则内需要准确定义操作SQL执行方法的包名、类名、方法名，甚至参数类型和位置，这里各家都会有自己的规则积累，需要排除掉规则中涉及查询的方法。

图1：源码角度识别API数据操作类型

除了上述处理策略外，为了保证识别数据操作方法的准召，还需要关注下列问题：

• 跨应用场景关联。如JSF（JavaServer Faces）、MQ消息队列、HTTP调用等均会出现API执行时跨项目中断，导致识别遗漏的问题。我们重点解决了跨JSF的调用链路（如图1中IACG边所示），通过解析JAVA代码中的静态配置和注解，形成了集团级JSF函数调用关系图谱，MQ和HTTP正在逐步支持中，不过MQ和HTTP在要求响应速度近乎苛刻的公网场景中，占比也相对较小。
• 非MYSQL。京东主流是通过Mysql进行数据存储，但也不乏MongoDB/ES/Redis等数据库，这里可以通过丰富规则补充识别。
• 多种操作类型并存。API执行过程中同时存在多个数据操作很常见，比如先查再插，先删再插等，我们会标记该API打上多个标签（图1中增删改标签最终均会聚合到API标记），如API执行时只要包含增/删/改，按照需要鉴权处理。
• 断链问题（特指单项目内）。如遇到二/三方包或动态调用等场景，传统静态引擎会出现污点传播中断问题，断链处理的关键在于梳理清楚断链的影响，比如影响识别清洗函数或识别污点，处置方式也不同，属于白盒引擎常见问题这里不再赘述。

4.2

构建PIN数据流图

识别出需要鉴权的操作方法后，接下来需要排查API实现代码中是否有鉴权行为，这是越权检测最关键一步。越权（这里主要关注水平越权）的核心，是后端接口，没有判断当前用户，是否具备查询/操作某类数据/资源的权限。用户（登录者），即主体。被访问的数据或资源，即客体。问题转化为：

“主体”是否具备操作”客体”的权限

而鉴权行为就发生在，主体参数和外部可控客体参数的数据流图中的“交汇点”上，这里的交汇点，可以是一个函数的两个参数，如authCheck(主体,客体)，或是一个表达式，如主体.equals(客体查询出来的数据体中的主体)、客体.equals(主体查询出来的数据体中的客体)，亦或是sql语句的where条件的两个入参，如where user=主体 and id =客体，虽有一定灵活性，但抽象后也可枚举，下文会详细介绍我们如何通过LLM来泛化识别多种鉴权场景。这样，越权问题就转变为识别主客体和交汇点的问题上了。

主体识别

主体即用户，通过PIN来唯一标识用户，PIN的生成方法与账号认证体系相关，各家公司有自己的统一账号体系，需要因地制宜适配，比如：

• 统一网关身份传递：如request.getParameter(“pin”); ，网关解析客户端请求后，将身份信息统一处理传递至后端API接口场景。
• 统一登录体系SDK身份获取方式。如LoginContext.getLogin().getPin(); 。
• 自建登录体系身份特征识别。如LoginUtil.getErp();，这部分需要借助到LLM的泛化能力，当然如果自建登录体系可运营，可通过丰富规则逐步提升识别能力。
• 二方包内调用统一登录SDK。业务对接了统一登录后会封装业务内的SDK，也需要适配。

实际业务对接中，上述为影响主体识别的主流场景，我们通过将类似方法内嵌在静态分析引擎中，实现了识别主体参数识别

客体识别

客体与要访问的数据/资源相关，业务接口一般通过改变sql语句的where条件来查询客体，被外部输入经历层层传播的where条件参数即可控客体参数。为解决识别客体参数问题，可通过反向追溯where条件参数的污点传播流，找到API入口的外部可控传参。值得注意的是，可控客体参数识别技术方案我们并未在越权漏洞识别场景上运用（已在其他逻辑类漏洞检测上落地），具体原因将在下文中说明。

PIN流图构建过程

图2：pin参数流图构建过程

落地初期，我们采取的是白盒传统污点分析构造数据流图，即外部可控入参流向数据操作类方法（类似于SQL注入检测逻辑），如图2左侧所示，红线部分表示构建的关键路径，但很快就发现，部分场景交汇点存在函数E内，并不在关键路径上。为了解决此问题，如图2中间图示，我们对数据流构建过程优化改造，单独追踪PIN参数的传播流，这样不仅能保证图中函数/函数片段包含交汇点，也明显降低了关键路径上函数的数量（这与鉴权的特点有关，一般发生在函数执行的前置阶段），有效缓解了LLM token限制问题。这里可能会有疑问，为什么单独追主体参数数据流图，客体呢？鉴权交汇点，一定存在于PIN参数流图或资源参数流图中，只需要保留一个即可，我们选择保留的是PIN参数流图。至此，我们就建立了一条用户身份传播流图，包含主体身份传播时经历的函数节点、实现源码等关键信息。

4.3

LLM辅助识别鉴权特征

首先说明，我们并没有基于集团代码训练自己的小模型，而是选用通用大模型。为什么不微调一个“小”模型而采用“大模型”？首先大模型大迭代速度快，我们微调的“小”模型在模型快速发展的今天，相比较优势不明显，其次现在大模型超长的上下文和代码理解能力，已经可以满足当前需求。

模型整体流程

图3：LLM整体流程

如上图所述，我们采取的是Multi-Agent协同完成复杂任务，Agent每次执行的时候都需要有合适的上下文，为了能让AI输出我们需要的信息，我们要做的就是优化在 LLM 上下文中提供的信息，尽可能的提供全部已知的信息。比如：

1. 完整的Pin流图。包含所涉及的代码片段。
2. 关联流量API（通过流量解析出来的API，包含完整的请求信息，区别于源码API）。提供外部可控的资源参数、可遍历的资源参数。是否可遍历主要用来判断越权利用的门槛，可根据各自场景选择。
3. 身份主体标识可信获取方式以及是否可信。上文中主体识别部分已展开。
4. 已知的可信鉴权注解知识库及说明。主要解决统一权管或业务封装的鉴权注解。
5. “复杂”业务场景的漏洞判断规则。这个与业务线相关，可酌情选择。

LLM如何识别鉴权

为了减少因上下文过长导致的“幻觉”问题，我们拆分为多个Agent用来识别不同场景下的鉴权逻辑。以函数鉴权举例，在识别时会将可信身份标识、外部可控的资源参数、调用链等作为上下文传递给模型，模型会根据函数鉴权的定义，识别出鉴权函数的全限定名以及置信度。图4是一个输出案例。

图4：LLM识别鉴权函数示例

LLM如何识别鉴权是否符合预期

虽然代码调用链中存在鉴权逻辑，但也会有鉴权不完善或者鉴权函数使用错误的场景。这里我们依靠SDL代码审计、外部SRC、以及安全专家经验等方式，抽象出10多种不同业务场景下的检测规则，通过对prompt 微调以及Few-shot prompting，不断改进大语言模型输出，图5是识别鉴权失效的样例：

图5：LLM识别鉴权失效示例

五

落地效果

在京东某业务线落地中，通过与人工评估数据交叉验证，AI识别无风险场景（即存在清洗函数场景）准确率可达90%+。AI识别有风险场景（即不存在清洗函数场景）准确率70+%。如图6所示，我们也已将此能力落地应用到SDL安全评估工作中，通过自动检出、人工反馈、模型调优等方式逐步优化检测结果，扩大覆盖范围。

图6：检测能力辅助SDL安全评估

六

后续规划

1. 黑+白+LLM。将黑白盒工具实现关联是我们一直追求的目标。在更多漏洞类型场景上真正做到白盒检、黑盒验，精准识别高风险漏洞再去推修，业务发展不被安全束缚，又能投入最少成本追求更高的安全水平。值得注意的是，工具关联的基础是精准的资产关联，比如基于流量中采集的API和源码中定义的API精准匹配。
2. 越权漏洞自动修复。除了检出之外，我们在修复上也在不断探索，目前业务修复越权漏洞时间数倍于通用漏洞，我们希望通过模型学习不同数据源的鉴权方法，在不同业务操作同一数据源时给出个性化修复建议，修复这块还属于起步阶段，大家如果有好的方案可以一起交流。

最近在学习业界大佬分享时看到一句话：Each program is its own universe, and hacking is about exploring, documenting and exploiting its rules.  代码本身是一个巨大的宝藏，不断理清逻辑、归纳规律、发现风险是一个极其有趣的过程，希望此文能给大家一些启发，共同促进企业安全水位不断上升。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：不止Security 《白盒+LLM：京东操作类越权自动化检测实践》